Enhanced Status Codes (RFC 3463, 5248, 7372)

A basic SMTP reply tells you the verdict in one digit (2/4/5). An enhanced status code tells you why, in three numbers like 5.1.1 or 4.2.2. You see them embedded in modern replies right after the basic code:

550 5.1.1 <nobody@example.com>: Recipient address rejected: User unknown
452 4.2.2 The email account that you tried to reach is over quota

The basic code (550, 452) drives retry behavior; the enhanced code (5.1.1, 4.2.2) drives diagnosis and, downstream, bounce classification. This page covers the structure from RFC 3463 (Enhanced Mail System Status Codes, January 2003) and the registry that keeps it extensible, RFC 5248 (June 2008, BCP 138).

For the basic codes these ride on top of, see Reading SMTP replies. For how they show up inside a bounce message, see Bounces and DSN parsing.

The 60-second version

• An enhanced code is class.subject.detail - three dot-separated numbers, e.g. 5.7.1.
• Class mirrors the basic first digit: 2 success, 4 persistent transient failure, 5 permanent failure. Only 2, 4, 5 are valid.
• Subject says where the problem is: addressing (X.1.x), mailbox (X.2.x), mail system (X.3.x), network/routing (X.4.x), protocol (X.5.x), content/media (X.6.x), security/policy (X.7.x).
• Detail is the precise condition within that subject.
• No leading zeros, no whitespace inside the code. 5.1.1, never 5.01.01.
• The set is extensible: RFC 3463 defined the base, RFC 5248 created the IANA registry so new codes can be added without a new core spec.

The structure: class.subject.detail

RFC 3463 §2 defines the syntax exactly:

status-code = class "." subject "." detail
class       = "2" / "4" / "5"
subject     = 1*3digit
detail      = 1*3digit

Two formatting rules from the same section that parsers must respect: “White-space characters and comments are NOT allowed within a status-code,” and “Each numeric sub-code within the status-code MUST be expressed without leading zero digits.”

The roles of the three fields: “The first sub-code indicates whether the delivery attempt was successful. The second sub-code indicates the probable source of any delivery anomalies, and the third sub-code indicates a precise error condition.”

Class - the same verdict as the basic code

Class	Name	Meaning (RFC 3463 §2)
2.X.X	Success	”The DSN is reporting a positive delivery action.”
4.X.X	Persistent Transient Failure	”The message as sent is valid, but persistence of some temporary condition has caused abandonment or delay… sending in the future may be successful.”
5.X.X	Permanent Failure	”Not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful delivery.”

This is the same transient-vs-permanent split as the basic 4xx/5xx. The enhanced class should agree with the basic first digit; when a provider’s text and codes disagree, the class digit is the reliable signal.

Subject - where the problem lives

Subject	Name	Meaning (RFC 3463 §2)
X.0.X	Other / Undefined	”No additional subject information available.”
X.1.X	Addressing	The originator or destination address - syntax or validity. “Can generally be corrected by the sender and retried.”
X.2.X	Mailbox	”Something having to do with the mailbox… assumed to be under the general control of the recipient.”
X.3.X	Mail System	”Something having to do with the destination system… under the general control of the destination system administrator.”
X.4.X	Network and Routing	”Status about the delivery system itself,” including DNS and routing infrastructure.
X.5.X	Mail Delivery Protocol	”Failures involving the message delivery protocol,” including implementation errors or an unreliable connection.
X.6.X	Message Content or Media	”Failures involving the content of the message” - translation, transcoding, unsupported media.
X.7.X	Security or Policy	”Failures involving policies such as per-recipient or per-host filtering and cryptographic operations.”

For a sender, the subject digit is the most useful field: X.1.x says fix the address, X.2.x says it is the recipient’s mailbox, X.7.x says you tripped a policy or filter.

The codes senders actually see

These are drawn from the enumerated codes in RFC 3463 §3. The “useful only for permanent / transient” notes are the spec’s own constraints and tell you whether a given detail code should ever appear as a 5.x.x or a 4.x.x.

Addressing - X.1.x (RFC 3463 §3.2)

Code	Name	Note
X.1.0	Other address status
X.1.1	Bad destination mailbox address	”Only useful for permanent failures.” The classic “user unknown.”
X.1.2	Bad destination system address	The domain part is invalid for mail. “Only useful for permanent failures.”
X.1.3	Bad destination mailbox address syntax	”Only useful for permanent failures.”
X.1.4	Destination mailbox address ambiguous	Matches more than one recipient.
X.1.5	Destination address valid	”Used for positive delivery reports.”
X.1.6	Destination mailbox has moved, no forwarding address	”Only useful for permanent failures.”
X.1.7	Bad sender’s mailbox address syntax
X.1.8	Bad sender’s system address

Mailbox - X.2.x (RFC 3463 §3.3)

Code	Name	Note
X.2.0	Other or undefined mailbox status
X.2.1	Mailbox disabled, not accepting messages	”May be permanent… or transient if only temporarily disabled.”
X.2.2	Mailbox full	”Should be used as a persistent transient failure.” (i.e. 4.2.2)
X.2.3	Message length exceeds administrative limit	”Should be used as a permanent failure.”
X.2.4	Mailing list expansion problem	”May represent a permanent failure or a persistent transient failure.”

Mail system - X.3.x (RFC 3463 §3.4)

Code	Name	Note
X.3.0	Other or undefined mail system status
X.3.1	Mail system full	”Useful only as a persistent transient error.”
X.3.2	System not accepting network messages	Shutdown, load, maintenance. “Both permanent and persistent transient.”
X.3.3	System not capable of selected features
X.3.4	Message too big for system	”Useful only as a permanent error.”
X.3.5	System incorrectly configured

Network and routing - X.4.x (RFC 3463 §3.5)

Code	Name	Note
X.4.0	Other or undefined network or routing status
X.4.1	No answer from host	”Useful only as a persistent transient error.”
X.4.2	Bad connection	Time-out or inadequate quality. “Persistent transient.”
X.4.3	Directory server failure	e.g. cannot reach DNS. “Persistent transient.”
X.4.4	Unable to route	”Both permanent and persistent transient.”
X.4.5	Mail system congestion	”Persistent transient.”
X.4.6	Routing loop detected	”Persistent transient.”
X.4.7	Delivery time expired	Message considered too old by the rejecting system.

Protocol - X.5.x (RFC 3463 §3.6)

Code	Name	Note
X.5.0	Other or undefined protocol status
X.5.1	Invalid command	Out of sequence or unsupported. “Only as a permanent error.”
X.5.2	Syntax error	”Only as a permanent error.”
X.5.3	Too many recipients	More recipients than the protocol could deliver.
X.5.4	Invalid command arguments	”Only as a permanent error.”
X.5.5	Wrong protocol version

Security or policy - X.7.x (RFC 3463 §3.8)

Code	Name	Note
X.7.0	Other or undefined security status
X.7.1	Delivery not authorized, message refused	Per-host or per-recipient filtering. “Only as a permanent error.”
X.7.2	Mailing list expansion prohibited	”Only as a permanent error.”
X.7.3	Security conversion required but not possible	”Only as a permanent error.”
X.7.4	Security features not supported	”Only as a permanent error.”
X.7.5	Cryptographic failure	Missing or invalid key.
X.7.6	Cryptographic algorithm not supported
X.7.7	Message integrity failure	Message corrupted or altered.

Message content or media - X.6.x (RFC 3463 §3.7)

Code	Name	Note
X.6.0	Other or undefined media error
X.6.1	Media not supported	The media of the message is not supported by either the delivery protocol or the next system in the path.
X.6.2	Conversion required and prohibited	The content must be converted to be forwarded, but conversion was prohibited.
X.6.3	Conversion required but not supported	The message content must be converted to be delivered, but no converter is available.
X.6.4	Conversion with loss performed	A conversion was required but only with loss; delivered anyway.
X.6.5	Conversion failed	A conversion was required but failed.

Senders see the X.6.x class far less often than the addressing, mailbox, and security classes above.

The IANA registry: how the set stays current (RFC 5248)

RFC 3463 fixed the structure and the initial codes, but new conditions appear over time. RFC 5248 created an IANA registry, “SMTP Enhanced Status Codes,” so codes can be added without rewriting the core spec. The registry has three tables (RFC 5248 §2.1): Class Sub-Codes, Subject Sub-Codes, and Enumerated Status Codes (a specified subject + detail with unspecified class). Each entry records the code, sample text, the associated basic SMTP code(s), a description, reference, submitter, and change controller.

New additions follow the “Specification Required” model (§2.2), “although, in practice, most entries are expected to derive from standards-track documents.” A few codes RFC 5248 itself registered (beyond RFC 3463) show how the class keeps growing:

• X.7.10 - Encryption Needed (basic code 523)
• X.7.13 - User Account Disabled (basic code 525)
• X.7.14 - Trust relationship required (basic codes 535, 554)

The practical takeaway: the X.7.x security/policy class in particular is open-ended, and you will encounter detail numbers beyond the RFC 3463 list. The framework guarantees the shape (class.subject.detail) and the meaning of class and subject; specific high detail numbers should be looked up in the IANA registry, and some that providers emit are vendor extensions not yet (or never) registered there - see Bounces and DSN parsing for the provider-proprietary 421 4.7.x patterns.

Authentication failure codes (RFC 7372)

The single most useful extension to the X.7.x class for a modern bulk sender is RFC 7372 (Email Authentication Status Codes, Standards Track, 2014), which registered codes to say that a message was rejected or deferred specifically because of an authentication failure - SPF, DKIM, or reverse DNS - rather than a generic policy block. Before these, a receiver could only fall back to a vague 5.7.1 or 5.7.0. The six registered codes:

Code	Sample text	Basic code	What it means
X.7.20	No passing DKIM signature found	550	The message carried no DKIM signature that passed verification.
X.7.21	No acceptable DKIM signature found	550	A DKIM signature passed, but none met the receiver’s local requirements.
X.7.22	No valid author-matched DKIM signature found	550	A signature passed but none align with the From: author domain (a special case of X.7.21).
X.7.23	SPF validation failed	550	An SPF check produced a fail contrary to local policy. Used in place of 5.7.1 (RFC 7208 §8.4).
X.7.24	SPF validation error	451 / 550	SPF evaluation hit an error. Used in place of 4.4.3 or 5.5.2 (RFC 7208 §8.6-8.7).
X.7.25	Reverse DNS validation failed	550	The client IP failed a reverse-DNS check, contrary to local policy.
X.7.26	Multiple authentication checks failed	550	More than one authentication method failed; the specific ones are unspecified.

Two operator notes straight from RFC 7372. First, when several checks fail, “the SMTP server SHOULD use the code that indicates multiple methods failed [X.7.26] rather than only reporting the first one that failed.” Second, these codes exist partly for “mailing list software, which processes rejections in order to remove… addresses that are no longer valid” - the point is to “distinguish authentication failures from indications that the recipient address is no longer valid.” That distinction matters for suppression: a 5.7.23 is your authentication problem to fix (see DMARC and alignment), not a dead recipient to suppress.

Note X.7.24 is the one auth code with a dual basic-code mapping (451 or 550): an SPF error can be transient (a DNS timeout, 4xx) or treated as permanent (5xx) depending on the receiver’s policy, so read the basic class to decide whether to retry.

A consolidated view of the X.7.x security and policy class

Because the security/policy class is where senders meet reputation and authentication, it is worth seeing the registered detail codes in one place - RFC 3463 base, RFC 5248 additions, and RFC 7372 auth codes:

Code	Name	Source
X.7.0	Other or undefined security status	RFC 3463
X.7.1	Delivery not authorized, message refused	RFC 3463
X.7.2	Mailing list expansion prohibited	RFC 3463
X.7.3	Security conversion required but not possible	RFC 3463
X.7.4	Security features not supported	RFC 3463
X.7.5	Cryptographic failure	RFC 3463
X.7.6	Cryptographic algorithm not supported	RFC 3463
X.7.7	Message integrity failure	RFC 3463
X.7.10	Encryption needed	RFC 5248
X.7.13	User account disabled	RFC 5248
X.7.14	Trust relationship required	RFC 5248
X.7.20	No passing DKIM signature found	RFC 7372
X.7.21	No acceptable DKIM signature found	RFC 7372
X.7.22	No valid author-matched DKIM signature found	RFC 7372
X.7.23	SPF validation failed	RFC 7372
X.7.24	SPF validation error	RFC 7372
X.7.25	Reverse DNS validation failed	RFC 7372
X.7.26	Multiple authentication checks failed	RFC 7372

This is not the entire IANA registry - it also holds additional X.7.x codes contributed by other standards-track documents (for example, the SMTP AUTH extension registers its own authentication-credential codes) - but it covers what a deliverability operator routinely encounters. For any code outside this set, the authoritative source is the live IANA SMTP Enhanced Status Codes registry, not a guess from the number.

How basic and enhanced codes line up

RFC 5248 §2.4 publishes the mapping between basic SMTP codes and enhanced codes. A selection:

Enhanced code	Associated basic codes (RFC 5248 §2.4)
X.1.1	451, 550
X.1.3	501
X.1.5	250
X.2.2	552
X.2.4	450, 452
X.3.1	452
X.3.4	552, 554
X.4.1	451
X.4.2	421
X.4.3	451, 550
X.5.3	451
X.7.1	451, 454, 502, 503, 533, 550, 551
X.7.2	550
X.7.4	504
X.7.23 (RFC 7372)	550
X.7.24 (RFC 7372)	451, 550
X.7.26 (RFC 7372)	550

Note that one enhanced code can map to several basic codes and vice versa - the two systems are related but not one-to-one. Read both: the basic class for retry behavior, the enhanced subject/detail for the reason.

Common confusion

• Class must agree with the basic code. A 5.x.x enhanced code on a 4xx basic reply (or the reverse) is contradictory; trust the basic class for retry decisions and treat the message as suspect.
• X is a placeholder, not a literal. “X.2.2 mailbox full” appears in the wild as 4.2.2 (transient) per the spec’s own guidance; the leading digit is filled in by the actual class.
• Higher detail numbers are not “more severe.” Detail is just an index within a subject, not a severity ranking.
• Not every enhanced code is in RFC 3463. The IANA registry (RFC 5248) is the live source; provider-specific detail codes may not be registered at all.

What this means for you, and what Egressif does

Egressif keys bounce handling on the enhanced code when one is present, falling back to the basic class when it is not. The class digit decides retry-vs-suppress (same 4/5 logic as the basic reply), and the subject digit decides what to tell you: an X.1.1/X.1.2 is a dead address we suppress, an X.2.2 is a transient full mailbox we retry, and an X.7.x is a policy or filtering signal that usually points at reputation or authentication rather than the recipient. The RFC 7372 auth codes (X.7.20-X.7.26) are especially actionable: they say “fix SPF/DKIM/DMARC,” not “this recipient is gone,” so we route them to authentication monitoring instead of the suppression list. We look up unfamiliar X.7.x detail codes against the IANA registry (RFC 5248) rather than guessing, and we treat the codes as diagnosis, never as a placement guarantee - no status code, basic or enhanced, can promise the inbox.