SMTP Enhanced Status Codes (RFC 3463)

RFC 3463 defines the enhanced mail system status codes — the X.Y.Z codes (e.g. 5.1.1, 4.2.2) that appear in SMTP replies and in the Status: field of delivery status notifications. They exist because the basic 3-digit SMTP reply codes (250, 450, 550…) conflate transport results with delivery semantics; enhanced codes give a machine-parsable, transport-independent reason. They are the single most useful input for automated bounce classification.

Structure

status-code = class "." subject "." detail

Each component is numeric, without leading zeros.

Class (first number) — is it permanent?

Class	Meaning	Bounce-handling implication
2.X.X	Success — positive delivery action	Not a bounce
4.X.X	Persistent transient failure — message valid, but a temporary condition caused delay/abandonment	Soft bounce: retry; suppress only after repeated failures
5.X.X	Permanent failure — not likely to be resolved by resending the message in its current form	Hard bounce: do not retry as-is; suppress the address for address-level causes

Subject (second number) — what part of the system failed?

Subject	Category
X.0.X	Other / undefined
X.1.X	Addressing status
X.2.X	Mailbox status
X.3.X	Mail system (destination host) status
X.4.X	Network and routing status
X.5.X	Mail delivery protocol status
X.6.X	Message content or media status
X.7.X	Security or policy status

Complete detail-code table

X.1.X — Addressing

Code	Meaning
X.1.0	Other address status
X.1.1	Bad destination mailbox address
X.1.2	Bad destination system address
X.1.3	Bad destination mailbox address syntax
X.1.4	Destination mailbox address ambiguous
X.1.5	Destination address valid
X.1.6	Destination mailbox has moved, no forwarding address
X.1.7	Bad sender's mailbox address syntax
X.1.8	Bad sender's system address

X.2.X — Mailbox

Code	Meaning
X.2.0	Other or undefined mailbox status
X.2.1	Mailbox disabled, not accepting messages
X.2.2	Mailbox full
X.2.3	Message length exceeds administrative limit
X.2.4	Mailing list expansion problem

X.3.X — Mail system

Code	Meaning
X.3.0	Other or undefined mail system status
X.3.1	Mail system full
X.3.2	System not accepting network messages
X.3.3	System not capable of selected features
X.3.4	Message too big for system
X.3.5	System incorrectly configured

X.4.X — Network and routing

Code	Meaning
X.4.0	Other or undefined network or routing status
X.4.1	No answer from host
X.4.2	Bad connection
X.4.3	Directory server failure
X.4.4	Unable to route
X.4.5	Mail system congestion
X.4.6	Routing loop detected
X.4.7	Delivery time expired

X.5.X — Mail delivery protocol

Code	Meaning
X.5.0	Other or undefined protocol status
X.5.1	Invalid command
X.5.2	Syntax error
X.5.3	Too many recipients
X.5.4	Invalid command arguments
X.5.5	Wrong protocol version

X.6.X — Message content / media

Code	Meaning
X.6.0	Other or undefined media error
X.6.1	Media not supported
X.6.2	Conversion required and prohibited
X.6.3	Conversion required but not supported
X.6.4	Conversion with loss performed
X.6.5	Conversion failed

X.7.X — Security / policy

Code	Meaning
X.7.0	Other or undefined security status
X.7.1	Delivery not authorized, message refused
X.7.2	Mailing list expansion prohibited
X.7.3	Security conversion required but not possible
X.7.4	Security features not supported
X.7.5	Cryptographic failure
X.7.6	Cryptographic algorithm not supported
X.7.7	Message integrity failure

Using the codes for bounce classification

The high-signal combinations for a suppression engine:

Observed status	Interpretation	Typical action
5.1.1, 5.1.2, 5.1.3, 5.1.6	Address does not exist / unroutable / gone	Hard bounce — suppress immediately (repeated 5.1.1s are also how providers detect stale lists)
5.2.1	Mailbox disabled	Suppress; account abandoned or closed
4.2.2	Mailbox full	Soft bounce — retry; suppress after sustained recurrence (often an abandoned account)
5.2.2	Mailbox full, reported permanent	Treat like sustained 4.2.2
4.3.x, 4.4.x	Destination system/network trouble	Retry; not a list-quality signal
4.4.7	Delivery time expired (retries exhausted)	The sending side gave up; investigate what underlying condition persisted
5.3.4 / X.2.3	Message too big / exceeds admin limit	Fix the message, not the list
5.7.1 and other 5.7.x	Policy/security refusal	Reputation or authentication problem, not a bad address — do not suppress the recipient; check blocklists, DMARC/SPF/DKIM, volume/warm-up (see IP Warm-Up)
4.7.x	Transient policy deferral (greylisting, rate limiting, "unusual volume")	Slow down; classic warm-up throttling signal

Caveats:

• The class digit governs retry semantics even when the subject/detail seem contradictory; per RFC 3463's model, the first number's permanence assessment wins for handling.
• Many receivers emit only a generic code (5.0.0) or nonstandard text; robust classifiers combine the enhanced code with the free-text Diagnostic-Code (see Delivery Status Notifications).
• Later RFCs and IANA registrations extend this list (e.g. RFC 7372 registers additional 5.7.x codes for SPF/DMARC failures); the codes above are the RFC 3463 base set every implementation shares.