SMTP Error Taxonomy: Building an Internal Bounce Classification System

• October 2023
• Engineering Memo · External Release

Every SMTP response code is a data point. Treated as noise — something to process, log, and move on from — these codes produce average deliverability outcomes. Treated as diagnostic signals with specific meanings and required responses, they become the primary tool for understanding the health of a sending infrastructure before problems escalate into incidents that affect campaign performance, ISP relationships, and list hygiene.

This note documents the complete taxonomy of SMTP error codes as they function in production high-volume environments — not as an RFC reference, but as an operational guide to what each code class means, what action it demands, and how it interacts with ISP reputation systems in 2025 and 2026. The practical distinctions that determine what an operator should do in the next five minutes versus the next five days are not in the RFC. They come from observing these codes at scale, across thousands of clients and hundreds of ISPs, over years of managed infrastructure operations.

The Three-Digit Structure and What It Actually Tells You

SMTP response codes follow a consistent three-digit structure defined in RFC 5321. The first digit communicates the fundamental category: 2xx means accepted; 3xx means the server needs additional input — rare in practice and not relevant to deliverability operations; 4xx means temporary failure and retry is allowed; 5xx means permanent failure and retry will not help. The second and third digits refine the meaning within that category, providing subject and detail information.

The enhanced status code — a three-part extension formatted like 5.7.26 — adds a second layer of precision beyond the base code. The enhanced code's first element mirrors the base code class: 2 for success, 4 for temporary failure, 5 for permanent failure. The second element categorizes the failure subject: 0 = other or undefined, 1 = addressing, 2 = mailbox, 3 = mail system, 4 = network and routing, 5 = mail delivery protocol, 6 = message content and media, 7 = security and policy. The third element is the specific detail number within that subject category. Enhanced codes are supported by all major ISPs and are considerably more useful than base codes for classifying failures precisely.

Major ISPs have introduced provider-specific enhanced codes that carry operational urgency beyond what the base three-digit code communicates. A 550 5.7.26 from Gmail is not merely "message rejected for policy reasons" — it is specifically a rejection due to unauthenticated email failing Gmail's authentication requirements, and it will affect every message sent to any Gmail address until the authentication problem is resolved. Logging it as a generic 550 without specific investigation is an operational error that will recur for every subsequent campaign.

4xx Codes: The Operational Reality of Temporary Failure

The 4xx class is the most operationally misunderstood in high-volume email. The phrase "temporary failure" implies that waiting will resolve the problem. In most cases this is correct — a receiving server under load, a mailbox temporarily over quota, a brief DNS resolution issue on the recipient side. The MTA's exponential backoff retry logic handles these correctly without operator intervention, and the operator's role is to monitor the trend rather than respond to individual instances.

The dangerous assumption is that all 4xx codes are benign and will self-resolve. Several categories are not. A 421 code returned from Gmail with the enhanced code 4.7.26 does not mean "Gmail's server is busy." It means Gmail has detected that mail from this sending domain is failing authentication requirements and is issuing a warning before escalating to permanent 5xx rejection. The window between the 4.7.26 warning and the 5.7.26 rejection is finite — operators who treat this as a routine deferral and wait for it to clear will find their mail permanently rejected when the grace period expires.

The 421 code specifically merits dedicated discussion because it appears in both genuinely transient contexts (connection limit, temporary server overload) and in enforcement contexts (ISP authentication policy warnings). The distinction requires reading the enhanced status code and the response message text, not just the base three-digit code. A retry logic system that treats all 421 codes identically will handle the transient cases correctly and will fail catastrophically for the enforcement cases.

Greylisting is the 4xx scenario most frequently mishandled by senders new to dedicated infrastructure management. Greylisting is a spam filtering technique in which a receiving server deliberately returns a 4xx response to the first delivery attempt from an unknown or low-reputation sender, then accepts the message on retry. The technique exploits the fact that many spam-sending systems do not implement proper retry logic. A correctly configured MTA handles greylisting transparently — the message is deferred, retried after the configured retry interval, and accepted. From the operator's reporting view, this appears as a minor deferral that resolved without intervention.

The mishandling occurs when a bounce processing system classifies the initial 4xx greylisting response as a soft bounce and begins tracking the recipient address for escalation, even though the message was ultimately delivered successfully on retry. If the bounce processing system reads the initial deferral response but not the subsequent successful delivery confirmation, it accumulates spurious soft bounce counts against valid addresses. After three campaigns, these addresses are escalated and eventually suppressed — removing legitimate contacts from the list based on a processing error, not genuine delivery failure. Monitoring for this pattern requires correlating bounce processing counts against actual accounting log delivery confirmations.

5xx Codes: The Permanent Failure Taxonomy and the Critical Exception

A 5xx response is a definitive statement by the receiving server: this message cannot and will not be accepted under current conditions. Unlike the 4xx class, there is no retry timeline that resolves 5xx failures for the same message. The standard response is immediate suppression of the recipient address and cessation of any further delivery attempts. This rule is correct for address-not-found failures (5.1.1, 5.1.2) and most other 5.1.x and 5.2.x codes. It is incorrect for 5.7.x security and policy failures where the rejection is caused by the sender's infrastructure configuration, not the recipient's address validity.

This distinction — between failures that indicate a bad address and failures that indicate a broken sender configuration — is the most consequential classification decision in bounce management. A sender who suppresses all 5.7.26 rejections from Gmail as hard bounces will progressively remove every Gmail address from their active list while the underlying authentication failure continues to affect every subsequent campaign. No amount of list suppression resolves a 5.7.26. The fix requires correcting DKIM and DMARC authentication, not removing recipients.

Gmail Enforcement Codes: The Authentication Escalation Model

Gmail uses a systematic enforcement model built around SMTP code escalation for authentication failures. The model works in two phases: a warning phase where Gmail returns 4xx codes that allow delivery but signal a compliance problem, and a rejection phase where Gmail returns 5xx codes that permanently reject messages until the compliance issue is resolved. The escalation between phases is not immediate — Gmail provides a grace period, the duration of which is not publicly specified but appears to be measured in weeks based on operator reports.

Understanding this escalation model changes how operators should prioritize 4xx investigation. In traditional email operations, 4xx codes are lower urgency than 5xx codes because they resolve automatically. Under Gmail's enforcement model, a 4xx enforcement code is higher urgency than a routine 5xx address-not-found, because the enforcement 4xx is a countdown: fix the compliance issue before the grace period ends or all mail from this domain will be permanently rejected by Gmail. A domain that sends to Gmail addresses and begins receiving 421 4.7.26 responses should treat that as a P1 incident, not a routine deferral event.

Yahoo operates a similar escalation model but uses different code patterns. Yahoo's TS02 codes indicate complaint-rate-based throttling — the sender's complaint rate from Yahoo FBL data has exceeded thresholds and Yahoo is beginning to restrict acceptance. Yahoo's TSS codes indicate a more severe policy block. Neither of these is a simple connection-limit 421 — they require investigation of complaint rate and potential list segment issues before retrying.

Building an Automated Bounce Classification System

The operational goal in a high-volume sending environment is to classify every SMTP response automatically, route it to the correct downstream action, and surface only the edge cases and patterns that require human review. Manual bounce classification at scale is both unreliable and unsustainable. A classification system built on the taxonomy described above handles the vast majority of production bounce codes correctly without human intervention.

In PowerMTA, the accounting log records every SMTP interaction with full response message text in the smtp-response field. The classification system reads this field, applies a prioritized rule set ordered from most specific to most general, and writes the classification to a downstream database. The rule priority order matters: enhanced status codes must be checked before base codes, provider-specific patterns must be checked before generic patterns, and address-specific failures must be distinguished from infrastructure-wide failures before any suppression action is taken.

A minimal production-ready classification covers five disposition categories:

Hard suppress — applied immediately on first occurrence. Triggered by 5.1.1, 5.1.2, 5.4.1, and other address-not-found enhanced codes. The address is invalid and will never deliver. Add to global suppression list before next campaign runs. No exception for recently acquired addresses or apparently valid domains — the ISP's response is authoritative.

Configuration fix required — no address suppression, but sending must pause until the configuration is corrected. Triggered by 5.7.26, 5.7.515, 5.7.9, and DNSBL-related 554 codes. Continuing to send under these conditions creates a backlog of rejected messages and worsens the reputation problem. The correct response is to fix the underlying issue — authentication, DNSBL listing, compliance violation — before resuming.

Soft bounce — increment counter — applied to 4xx codes that are not enforcement warnings. Each occurrence increments the soft bounce counter for the address. When the counter reaches the configured threshold across the configured number of campaigns and time window, the address is promoted to hard bounce status. The threshold configuration (commonly 3 failures over 30-45 days) should be reviewed quarterly against actual list churn rates and adjusted based on observed patterns.

Rate limit — back off — applied to 421 codes that indicate ISP-side rate limiting rather than enforcement warnings. The response is to reduce the connection rate to the affected ISP, not to suppress addresses. PowerMTA's per-ISP domain block configuration handles this automatically if properly configured — but the classification system should flag persistent rate-limit codes as a signal that the current connection configuration is too aggressive for the IP's current reputation level.

Log only — applied to patterns that resolve without intervention. Greylisting patterns (4xx on first attempt, 250 on retry), transient server unavailability, and similar self-resolving conditions. No list action, no configuration change. The classification system records the occurrence for trend analysis but does not surface it for human review unless the pattern persists beyond the expected resolution window.

The Soft Bounce Promotion Threshold: Calibration for Your Programme

The soft-to-hard-bounce promotion threshold is one of the most programme-specific parameters in bounce management. Set too aggressively, it suppresses addresses that would have eventually delivered — reducing list size without eliminating genuine delivery problems. Set too conservatively, it allows problematic addresses to remain active, consuming sending capacity and accumulating negative reputation signals on campaigns they can never convert.

The default threshold used by many ESPs — three failures across any period — is often too aggressive for programmes with high-value contacts, where the cost of a false-positive suppression is significant. A threshold of three failures across three separate campaigns and thirty days is more appropriate for most production environments. This ensures the address has genuinely failed to accept mail across a meaningful time period, not just encountered a transient server issue on three occasions within a single week.

The threshold also benefits from differentiation by bounce sub-type. A mailbox-full (452/552) soft bounce warrants a more patient threshold than a connection-refused soft bounce. The mailbox may clear as the account holder deletes messages or the storage allocation is increased — this is common for corporate accounts and active personal accounts. A connection-refused bounce typically indicates a more fundamental problem with the address or receiving server. Treating these as identical in the promotion logic is an unnecessary simplification that produces worse outcomes than per-sub-type thresholds.

Review the promotion threshold after every major list hygiene event. When a new list segment is imported or a re-engagement campaign runs, the baseline soft bounce rate may shift significantly. A threshold calibrated for a stable, mature list may be inappropriate for a freshly acquired segment with unknown hygiene characteristics. The threshold is a parameter, not a setting — it should be adjusted as programme conditions change.

Yahoo, Microsoft, and Regional ISP Code Patterns

While Gmail receives the most attention in email deliverability discussions, Yahoo and Microsoft handle a combined 30–40% of consumer email volume in English-speaking markets and have their own distinct code patterns that require specific operational responses.

Yahoo's most common enforcement codes appear as TS codes: TS01 indicates a message was rejected due to Yahoo's spam filter, TS02 indicates throttling due to elevated complaint rates from Yahoo FBL data, and TSS indicates a more severe policy block that typically requires postmaster contact to resolve. Yahoo TS02 throttling begins manifesting as 421 responses with specific message text referencing their complaint threshold. The response to TS02 is not to retry faster — it is to reduce sending volume to Yahoo addresses, investigate the complaint source using FBL data, and allow the complaint rate to decline before resuming normal volume. Retrying at standard rate under TS02 conditions worsens the reputation standing and delays recovery.

Microsoft Outlook and Hotmail use the 550 5.7.350 code for bulk sender requirement violations and 550 5.7.1 for Spamhaus-listed IPs or domains. Microsoft also maintains the Smart Network Data Services (SNDS) portal, which provides per-IP complaint rate and reputation data. Operators who see Microsoft 5xx codes should check SNDS before submitting a postmaster request — SNDS often explains the block cause directly, making the postmaster interaction shorter and more productive.

For European ISPs — GMX, Web.de, T-Online, Orange, Free.fr, and similar regional providers — code patterns are less standardized than the major US providers. These ISPs frequently return generic 550 codes with custom message text that contains the specific rejection reason. Text parsing of the smtp-response field is required for accurate classification. Common patterns include references to their own blacklists, complaint rate thresholds, and authentication requirements that mirror but are not identical to Gmail's. Per-ISP domain block configuration in PowerMTA, with appropriate retry and connection settings for each regional provider, is required for reliable delivery to European consumer addresses at scale.

Practical Implementation: PowerMTA Accounting Log Integration

The PowerMTA accounting log is the canonical data source for SMTP response classification in a managed sending environment. Its default format includes, per delivery event: the sending virtual MTA, the destination domain, the smtp-response field with the full server response, the disposition (delivered, bounced, deferred), the number of retry attempts, the message size, and timing data. This is sufficient to build a complete classification system without additional logging configuration.

The accounting log is written in CSV format to a configurable directory. Most operators parse it through a log processing pipeline — a daemon that reads new accounting log entries as they are written, applies the classification rules, and writes results to a database. This database is then the source of truth for bounce tracking, suppression management, and deliverability monitoring dashboards. The pipeline should process accounting log entries with a latency of under 30 seconds so that suppression actions from hard bounces are available before the next campaign job processes.