← RFC Reference

RFC 5248: SMTP Enhanced Status Codes Registry

Why This Exists

Enhanced status codes (RFC 3463) use a three-part class.subject.detail format to precisely describe why a message was accepted, rejected, or delayed. The original RFC defined a fixed set of codes, but new email technologies kept needing new codes:

• DMARC failures needed 5.7.25 and 5.7.26
• Null MX (RFC 7505) needed 5.1.10
• TLS requirements needed codes in the X.7.X security range
• Authentication extensions needed X.7.20 through X.7.27

Without a formal registry, new codes were assigned ad hoc and risked collisions. RFC 5248 establishes the IANA "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes" registry, with clear rules for registration and a requirement that every new code has a defined meaning.

How It Works

The registry organizes codes by their three components. New codes are added through the IETF standards process, and each entry documents:

Registry Entry Format

SMTP Response with Registry-Defined Code

MAIL FROM:<sender@example.com>
250 2.1.0 Originator address accepted

RCPT TO:<user@example.org>
550 5.7.26 This message does not pass DMARC evaluation
     ^^^^^
     Registered in IANA registry, defined by RFC 7372

RCPT TO:<nobody@null-mx.example>
556 5.1.10 Recipient address has null MX
     ^^^^^^
     Registered in IANA registry, defined by RFC 7505

Key Technical Details

Enumerated Status Codes (Class + Subject)

RFC 5248 defines "enumerated status codes" that combine class and subject values. The class remains 2, 4, or 5, and the subject values are:

Codes Added Since RFC 3463

Registration Policy

New codes require "Specification Required" per IANA policy. This means a published specification (typically an RFC) must define the code's semantics. The designated expert reviewer ensures there are no conflicts with existing codes and that the new code fits within the correct subject category.

Common Mistakes

• Hardcoding a fixed set of status codes. The registry is extensible. New codes are added regularly. Build your bounce processor to handle unknown codes gracefully by falling back to the class (2/4/5) and subject category.
• Inventing non-registered codes. Some mail servers return custom enhanced status codes not in the registry. While technically valid as private-use, this harms interoperability. Use registered codes whenever possible.
• Ignoring the class digit when handling new codes. If you encounter 5.7.28 (a hypothetical future code), you may not know its specific meaning, but you know it is a permanent security/policy failure. The class and subject are always meaningful.
• Not distinguishing between class 4 and class 5. 4.2.2 (mailbox full, temporary) and 5.2.1 (mailbox disabled, permanent) share the same subject but require completely different handling. Always check the class first.
• Assuming all servers use enhanced codes. The ENHANCEDSTATUSCODES SMTP extension is widely but not universally deployed. Your bounce parser must handle responses that only contain the basic three-digit code.

Deliverability Impact

• Precise bounce classification. The registry gives you a standardized vocabulary for why messages fail. 5.7.26 means DMARC failure — fix your authentication. 5.1.1 means invalid address — remove it from your list. Without consulting the registry, you are guessing.
• Authentication failure diagnosis. The 5.7.20–5.7.26 range of codes added by RFC 7372 lets you pinpoint exactly which authentication mechanism failed: DKIM, SPF, reverse DNS, or DMARC alignment.
• Future-proof bounce handling. By parsing the class and subject from any code, even unrecognized ones, your system degrades gracefully as new codes are registered. A 5.7.X code you have never seen is still a permanent security rejection.
• Correlating with DSN reports. Enhanced status codes appear in both SMTP responses and DSN reports (RFC 3464). The registry ensures the same code means the same thing in both contexts, enabling consistent bounce processing.

Related RFCs