SMTP Error Taxonomy and Bounce Classification: What Every Code Means

• November 2022
• Engineering Memo · External Release

SMTP response codes are the language that receiving mail servers use to communicate the outcome of every delivery attempt. Getting the taxonomy right — distinguishing permanent failures from temporary deferrals, understanding what specific codes indicate, and classifying bounces correctly for suppression decisions — is fundamental to operational email infrastructure management. Misclassifying a temporary deferral as a permanent bounce produces unnecessary suppression; misclassifying a permanent failure as a temporary deferral wastes retry resources and accumulates reputation damage from continued attempts to undeliverable addresses.

This note documents the SMTP response code structure, the operational classification framework for each major code category, and the specific codes that appear most frequently in production accounting logs and require correct interpretation for suppression and retry decisions.

The SMTP Response Code Structure

SMTP response codes are three-digit numbers where each digit carries specific meaning. The first digit indicates the category: 2xx means success (the server accepted the action), 4xx means temporary failure (the server cannot accept the action now but may in the future), and 5xx means permanent failure (the server cannot accept the action and the sender should not retry).

The second digit provides additional categorisation: x0x is syntax-related, x1x is informational, x2x is connection-related, x3x is reserved for future use, x4x is storage-related, and x5x is mail system-related. The third digit distinguishes specific responses within each sub-category. The full three-digit code is typically accompanied by a human-readable response text that provides additional context about the specific reason for the response.

Beyond the three-digit code, modern SMTP implementations often include Enhanced Mail System Status Codes (RFC 3463), which provide additional detail in the format X.Y.Z — a hierarchical status code that can be included in the response text alongside the three-digit SMTP code. For example: 550 5.1.1 The email account that you tried to reach does not exist includes both the 550 SMTP code and the 5.1.1 enhanced status code indicating an invalid mailbox. The enhanced status code provides more precise classification than the three-digit code alone.

The 4xx Codes: When to Defer and Retry

421 — Service not available, closing transmission channel. The receiving MTA is temporarily unavailable and has closed the connection. The cause may be: the server is shutting down for maintenance, is overloaded and refusing new connections, or is actively throttling the sender by dropping connections after acceptance. Action: defer the message and retry after 5-10 minutes. A persistent pattern of 421 responses from the same ISP at the same time of day indicates a recurring throttle point that the domain block configuration should be adjusted to avoid.

450 — Requested mail action not taken: mailbox unavailable. The recipient's mailbox is temporarily unavailable — possibly because the mailbox is over its storage quota, the mailbox's server is temporarily unreachable, or the receiving ISP is applying a temporary policy block. Action: defer and retry with exponential backoff. 450 responses that persist for more than 72 hours for the same recipient should be reclassified as soft bounces for list management purposes — a mailbox that has been unavailable for 72 hours is likely abandoned or permanently full.

451 — Requested action aborted: error in processing. The receiving server encountered a processing error and deferred the message. The most common production cause of 451 responses is greylisting: many greylisting implementations use 451 as the response code when an IP-domain-recipient triplet is first seen. The response text distinguishes greylisting from genuine processing errors: greylisting responses typically include text like "Greylisted, please retry" or "Please try again later." Action: retry after the greylisting minimum retry interval (typically 5-15 minutes).

452 — Requested action not taken: insufficient system storage. The receiving server is low on storage and cannot accept the message. This is an ISP infrastructure issue rather than a sender problem. Action: defer and retry with normal backoff. Persistent 452 responses from the same ISP warrant checking whether the ISP is experiencing an infrastructure issue that is affecting all senders.

The 5xx Codes: Permanent Failures and Their Meanings

550 — Requested action not taken: mailbox unavailable. The most common permanent failure code. The 550 code covers a wide range of permanent rejection reasons, differentiated by the response text and enhanced status code. Key 550 sub-categories from the response text: "5.1.1 The email account that you tried to reach does not exist" — the recipient address is invalid; suppress permanently. "5.7.1 Email rejected per our Terms of Service" — the message was rejected for policy reasons (content, sender reputation, or blocklist); investigate the policy reason from the response text before deciding on retry vs suppress. "5.7.26 [DMARC policy violation]" — the message failed DMARC policy enforcement; address the authentication configuration, not the list quality.

551 — User not local; please try forwarding. The recipient address is valid but the message was rejected because the recipient's account is on a different server than the one contacted. This code includes a forwarding address in the response text. In practice, modern ISPs rarely use 551 — they typically accept the message and forward internally. A 551 response should be treated as permanent and the recipient removed from the list unless the forwarding address provided in the response can be used.

552 — Requested mail action aborted: exceeded storage allocation. The recipient's mailbox is over its storage quota and cannot accept new messages. Unlike 452 (which is a temporary ISP storage issue), 552 is specific to the recipient's mailbox. Action: defer and retry for 72 hours — some recipients will clear their mailbox. If the 552 persists after 72 hours, reclassify as a soft bounce. A recipient whose mailbox is consistently full is a low-engagement contact who should be reviewed for suppression during list quality management.

553 — Requested action not taken: mailbox name not allowed. The recipient address contains invalid characters or formatting. This is typically a data quality issue (the address was malformed at acquisition) rather than a policy response. Action: suppress permanently and review the acquisition source that provided the malformed address.

554 — Transaction failed. A catch-all permanent failure code used when the more specific codes do not apply. The 554 response text contains the actual reason: 554 5.7.1 Message rejected due to reputation of the sending IP indicates an IP blocklist response; 554 Message not deliverable may indicate a content-based rejection; 554 5.7.0 No DMARC record found indicates a DMARC configuration issue. Parse the response text to determine the correct classification and action.

PowerMTA Bounce Classification Configuration

PowerMTA's bounce classification system allows operators to configure regex patterns that match SMTP response text and classify each response as a specific bounce type (hard, soft, bad-mailbox, bad-domain, policy, spam, etc.). The classification determines whether the message is retried (soft), suppressed (hard, bad-mailbox, bad-domain), or escalated for investigation (policy, spam).

The default PowerMTA bounce patterns cover the most common response codes correctly, but ISP-specific response texts may require custom patterns. For example, a specific ISP might use a 451 response for both greylisting and genuine processing errors, with different text in each case. Adding a custom bounce pattern that detects the greylisting text specifically and classifies it as a greylist-deferral (retry aggressively) rather than a general soft-deferral (retry with standard backoff) produces more efficient greylisting clearance.

The bounce classification configuration should be reviewed quarterly against the accounting log's most common response texts to identify any patterns that are being classified generically when they could be classified more specifically. A 554 response that is classified as a generic permanent failure when it actually indicates an IP blocklist response should be reclassified as a policy-block, triggering the IP blocklist investigation protocol rather than simple recipient suppression.

Correct bounce classification is the mechanism that makes the accounting log data actionable: it converts raw SMTP response codes into suppression decisions, retry schedules, and investigation triggers. The investment in maintaining accurate bounce pattern configuration — reviewing quarterly, adding ISP-specific patterns when new response texts appear in the log, and auditing the classification against actual delivery outcomes — ensures that the infrastructure's operational responses to each delivery outcome are appropriate and efficient. Classification errors accumulate operational costs: misconfigured retries waste throughput; misconfigured suppressions remove valid recipients from future sends. Get the classification right, and the infrastructure's operational behaviour is automatically aligned with the correct response to each delivery situation the SMTP conversation produces.

ISP-Specific Response Code Patterns

Gmail (Google): Gmail's 5xx response texts are generally informative and well-structured. Key patterns to recognise: 550 5.7.26 indicates a DMARC policy enforcement rejection — investigate authentication configuration, not list quality. 550 5.7.1 Our system has detected an unusual rate of unsolicited mail indicates a reputation-based block for the sending IP or domain. 452 4.2.2 The email account that you tried to reach is over quota is a 4xx (temporary) from Gmail despite the 452 code and the mailbox-specific language — defer and retry. Gmail's 421 throttle responses typically include the text "Try again in X minutes" which can be parsed to configure an ISP-specific retry interval.

Microsoft (Outlook/Hotmail): Microsoft uses a specific set of response codes that carry distinct operational meanings. 550 5.7.511 indicates a listed IP in Microsoft's anti-spam system — requires investigation and submission to Microsoft's delisting portal. 550 5.7.350 indicates the message is being blocked because the sending domain has been identified as a spam source. 450 4.7.230 is a temporary authentication failure — often seen when SPF lookup returns too many DNS lookups (permerror treated as temporary by some Microsoft systems). 421 4.16.55 is Microsoft's rate-limiting response, indicating the connection rate has exceeded what Microsoft accepts from the sending IP.

Yahoo: Yahoo's response codes are less verbose than Gmail or Microsoft. 554 HVU:B1 indicates the sending IP is on Yahoo's proprietary blocklist — requires SNDS review and Yahoo's delisting request process. 421 Resources temporarily unavailable is Yahoo's standard throttle response. 554 SY:B4 indicates spam reputation rejection at Yahoo. Yahoo's response codes often use short alphabetic identifiers (B1, B4, HVU) rather than the X.Y.Z enhanced status code format, requiring ISP-specific pattern matching in PowerMTA's bounce classification.

EU consumer ISPs (GMX, T-Online, Free.fr): EU ISPs frequently use non-standard response texts that require custom PowerMTA bounce patterns. GMX uses 421 Too many concurrent SMTP connections from your IP address for connection throttling. T-Online uses 550 Requested action not taken: mailbox unavailable for both invalid addresses and policy rejections, requiring response text parsing to distinguish the two cases. Free.fr uses greylisting extensively with the 451 code and French-language response text — a custom pattern matching French greylisting text is needed for correct classification.

Building the Bounce Classification Database

The operational database that stores delivery event data should include a bounce_type field derived from the PowerMTA bounce classification. This field, populated by the accounting log ETL pipeline from the PowerMTA accounting log's bounce_class field, enables the per-bounce-type queries that deliverability management requires: how many hard bounces did this campaign generate? What percentage of deferrals are greylisting vs genuine throttle? Which campaigns generate the most policy rejections?

The bounce_type field values from PowerMTA's classification system: hard (permanent rejection of invalid recipient), soft (temporary deferral), bad-mailbox (permanent rejection of the specific mailbox address), bad-domain (permanent rejection indicating the domain is invalid or non-existent), policy (rejection indicating a policy reason — content, sender reputation, authentication), spam (rejection specifically citing spam classification), delayed (message exceeded queue-life without delivering), and greylist (a category for classified greylisting deferrals that should be retried differently from generic soft deferrals).

The suppression logic downstream of the bounce classification database should act on bounce_type values: hard and bad-mailbox trigger immediate permanent suppression; soft and greylist trigger retry (no suppression); bad-domain triggers domain-level review (the entire domain may be invalid); policy triggers investigation rather than suppression (the classification should inform a human review before suppression is applied); spam triggers investigation and possible IP or domain reputation review. The bounce_type field is the bridge between the raw SMTP response and the operational decision — getting the classification right is what makes the downstream automation correctly calibrated.

The Soft-to-Hard Bounce Transition

Not all soft bounces remain temporary. A 450 response from a full mailbox may be temporary (the user clears their inbox) or permanent (the mailbox is abandoned). A 451 greylisting response clears on retry within minutes; a 451 that persists through multiple retry cycles indicates a genuine processing error rather than greylisting. Bounce classification must handle the time dimension: a recipient who generates soft bounces across three consecutive monthly campaigns should be reclassified as a hard bounce for list management purposes, regardless of whether each individual bounce used a 4xx code.

The soft-to-hard transition rule: any recipient address that generates 3 consecutive soft bounces (not delivered to for 90 days due to persistent deferral) should be suppressed from future sends. This rule is implemented in the suppression management application rather than in PowerMTA directly — PowerMTA continues to attempt delivery as long as the message is within queue-life, but the sending application's suppression list is updated based on the pattern of consecutive soft bounces across campaigns.

The specific transition threshold (3 consecutive campaigns, 90 days) is configurable and should reflect the programme's list quality standards and commercial context. High-value B2B contact lists may warrant more patience (5 consecutive misses) before suppression; cold email lists with higher baseline bounce rates may warrant faster suppression (2 consecutive misses) to contain list quality costs. The threshold should be documented and consistently applied rather than left as an undocumented behaviour of the bounce handling system.

Bounce classification, correctly implemented and consistently maintained, is the automated intelligence layer that makes suppression decisions correctly without requiring human review of every individual delivery outcome. The taxonomy in this note provides the classification framework; the PowerMTA bounce pattern configuration provides the automated classification; the operational database stores the classified outcomes; and the suppression application applies the rules that convert classified outcomes into list management decisions. Each component depends on the previous one — the classification taxonomy is the foundation that all subsequent automation builds on. Invest in getting it right, and the operational consequence of every SMTP response code is automatically appropriate throughout the programme's sending lifecycle.

Bounce Rate Benchmarks by Traffic Type

Bounce rates that indicate a list quality problem vary by traffic type and acquisition source. Understanding the benchmarks for each context allows operators to correctly calibrate whether a campaign's bounce rate requires investigation or falls within acceptable range for its specific sending scenario.

Permission-based promotional email to an established, maintained list: hard bounce rate below 0.5% per campaign is normal. A well-curated permission list with regular bounce suppression and annual re-engagement campaigns will typically show 0.1-0.3% hard bounce rates. Rates above 0.5% indicate list age, list quality decay (contacts becoming invalid faster than they are being suppressed), or a recent addition of a lower-quality segment.

Transactional email to recently acquired users: hard bounce rates of 0.3-1.0% are common for newly registered users, because some user-provided registration email addresses contain typos or deliberate false addresses. Real-time validation at acquisition (checking MX record existence and syntax at registration) can reduce this rate significantly. Post-acquisition, transactional email to established users should show near-zero bounce rates (below 0.1%) since the account is active.

Cold email to B2B prospecting lists: hard bounce rates of 3-8% are common for non-validated prospecting lists, because business email addresses change more frequently than consumer addresses (job transitions, company restructuring) and prospecting lists often contain outdated data. List validation before sending reduces this rate, but B2B cold email lists will always have higher baseline bounce rates than permission-based consumer lists. For cold email, the benchmark is relative improvement from list validation rather than an absolute threshold.

Reporting Bounce Classification to Stakeholders

Campaign bounce data presented to marketing and product stakeholders should be classified and explained in terms that are operationally actionable rather than technically detailed. The reporting framework: hard bounces (addresses that cannot receive email permanently — investigation needed if above threshold), soft bounces (temporarily undeliverable addresses — will be retried automatically), and policy rejections (messages rejected for non-address-quality reasons — may indicate infrastructure configuration issues rather than list quality issues).

The distinction between hard bounces (list quality signal, requires suppression) and policy rejections (infrastructure signal, requires configuration investigation) is particularly important for stakeholder communication. A campaign showing 0.8% "bounce rate" may actually be 0.2% hard bounces and 0.6% policy rejections — very different operational implications. The 0.2% hard bounce rate is a list quality concern; the 0.6% policy rejection rate is an infrastructure configuration concern. Reporting them as a combined "bounce rate" obscures both problems and prevents the correct team from addressing each.

Bounce classification reporting enables clear operational ownership: hard bounces are a list management responsibility (marketing or data team); policy rejections are an infrastructure responsibility (email infrastructure team); soft bounces are an automated retry responsibility (handled by PowerMTA without team intervention). Classification-based reporting distributes accountability correctly and prevents the confusion that aggregate bounce reporting produces when multiple bounce types with different causes and owners are combined into a single metric.

SMTP response codes are the infrastructure's operational language. Learning to read them fluently -- knowing what each code means, how to classify the bounce it indicates, and what operational response is correct -- is one of the most valuable skills in email infrastructure management. The taxonomy in this note provides the vocabulary; operational practice with real accounting log data provides the fluency. Together they make every SMTP session outcome interpretable and every operational response appropriate.

The taxonomy is the foundation. The classification is the mechanism. The suppression logic is the output. All three must be correctly configured and consistently maintained for the infrastructure's bounce handling to produce the right operational behaviour automatically -- for every SMTP response code, every delivery attempt, every campaign, indefinitely.