RFC 3463: Enhanced Mail System Status Codes

Current Standard Delivery Status & Bounce Handling Obsoletes RFC 1893 DSNBounce CodesStatus Codes

ELI5: Basic SMTP gives you a three-digit reply code like “550” that means “something failed.” But why did it fail? Wrong address? Mailbox full? Server overloaded? Enhanced status codes add a more specific three-part code like 5.1.1 (bad destination mailbox) so your software can tell the difference and take the right action.

Why This Exists

SMTP reply codes (RFC 5321) use three-digit numbers: 250 means success, 550 means permanent failure, 421 means temporary problem. But these codes are too coarse for automated processing. A "550" could mean:

The mailbox does not exist
The domain does not exist
The sender is blocked by policy
The message content was rejected

Each of these requires a different response from the sender. Enhanced status codes solve this by adding a structured class.subject.detail code that precisely identifies the problem. These codes appear in SMTP responses (via the ENHANCEDSTATUSCODES extension) and in DSN reports (RFC 3464) in the Status field.

How It Works

Enhanced status codes follow the format X.Y.Z where each component has a defined meaning:

Code Structure

Component	Name	Meaning
`X`	Class	Success (2), temporary failure (4), or permanent failure (5)
`Y`	Subject	Category of the problem (address, mailbox, mail system, network, protocol, content, security)
`Z`	Detail	Specific condition within the category

SMTP Response Example

RCPT TO:<user@example.org>
550 5.1.1 The email account that you tried to reach does not exist
     ^^^^^
     |   |
     |   +-- detail 1 = bad destination mailbox address
     +------ subject 1 = addressing status
     class 5 = permanent failure

In a DSN Report

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown

Key Technical Details

Class Values

Class	Meaning	Sender Action
`2.X.X`	Success	Message was accepted or delivered. No action needed.
`4.X.X`	Persistent Transient Failure	Retry later. The condition may resolve on its own.
`5.X.X`	Permanent Failure	Stop retrying. The message will never be delivered to this address as-is.

Subject Values

Subject	Category	Examples
`X.0.X`	Other / Undefined	Not otherwise classified
`X.1.X`	Addressing	Bad mailbox, bad domain, bad sender
`X.2.X`	Mailbox	Mailbox full, disabled, not accepting messages
`X.3.X`	Mail System	Mail system full, not accepting messages, incapable of selected features
`X.4.X`	Network and Routing	No answer from host, bad connection, routing error
`X.5.X`	Mail Delivery Protocol	Invalid command, protocol syntax error
`X.6.X`	Message Content	Media not supported, conversion failed
`X.7.X`	Security / Policy	Authentication required, sender blocked, encryption needed

Most Common Codes for Email Senders

Code	Meaning	Action
`5.1.1`	Bad destination mailbox address	Remove from list (hard bounce)
`5.1.2`	Bad destination system address (domain)	Remove from list
`5.2.1`	Mailbox disabled, not accepting messages	Remove from list
`4.2.2`	Mailbox full	Retry later; suppress after repeated failures
`5.7.1`	Delivery not authorized, message refused	Check authentication and sender reputation
`4.7.1`	Temporary authentication failure	Retry; check SPF/DKIM/DMARC records
`5.7.26`	DMARC policy violation	Fix DMARC alignment (SPF or DKIM must pass with aligned domain)
`5.7.27`	Sender address has null MX	Add a valid MX or A record for your sending domain
`4.4.1`	Connection timed out	Retry; check DNS and network connectivity
`5.3.4`	Message too big for system	Reduce message size or attachments

Common Mistakes

Only checking the SMTP reply code, ignoring the enhanced code. A "550" tells you it is permanent, but 5.1.1 (user unknown) and 5.7.1 (policy block) require very different responses. Always parse the enhanced code.
Treating all 5.X.X codes as "remove from list." Code 5.7.1 often means a temporary policy block (spam filtering, rate limiting), not an invalid address. Blindly removing addresses on every permanent failure causes unnecessary list shrinkage.
Ignoring the class digit. The first digit is the most important. 4.2.2 (mailbox full, transient) and 5.2.2 (mailbox full, permanent) require different handling. Some providers use 4.X.X for quota issues that resolve, and 5.X.X only after prolonged fullness.
Hardcoding specific codes. The enhanced status code registry (RFC 5248) is extensible. New codes are added over time. Parse the class and subject for routing decisions, and log the full code for diagnostics.
Confusing SMTP reply codes with enhanced status codes. The three-digit SMTP code (550) and the enhanced code (5.1.1) are separate. The enhanced code appears after the SMTP code in the response line, or in the Status field of a DSN.

Deliverability Impact

Bounce classification accuracy. Enhanced status codes are the primary input for automated bounce processing. Correct classification of hard bounces (remove) vs. soft bounces (retry) vs. policy blocks (investigate) directly affects your sender reputation and list quality.
Reputation-aware retry logic. A 4.7.1 response (temporary auth failure) should trigger a check of your SPF/DKIM/DMARC records, not just a blind retry. A 4.2.2 (mailbox full) is a different problem entirely.
Diagnostics and debugging. When deliverability drops, the enhanced status codes in your bounce logs tell you exactly what is happening. A spike in 5.7.1 responses suggests a reputation problem; a spike in 5.1.1 suggests bad list data.
Provider-specific behavior. Gmail, Microsoft, and Yahoo all use enhanced status codes, but may assign slightly different codes to the same condition. Use the codes as guidance and correlate with the Diagnostic-Code text for full context.