What RFC 3463 defines
RFC 3463 is the specification behind the second number you see in a bounce. When a server answers 550 5.1.1 User unknown, the 550 comes from the SMTP protocol itself and the 5.1.1 comes from this document. Greg Vaudreuil published it as a Standards Track RFC in January 2003, replacing RFC 1893, and its job is narrow: give the mail system a structured, machine readable vocabulary for saying what happened, so that software no longer has to guess by matching text strings against a list of vendor phrasings.
The three digit reply code is too coarse for that. A 550 can mean an unknown recipient, a policy rejection, a blocklist hit or a relay refusal, and each of those calls for a completely different reaction from the sender. The enhanced code splits the answer into three fields that a program can branch on without reading a single word of English.
Reading a code: class, subject, detail
Every enhanced status code has the shape class.subject.detail. The class is the part that decides what you do next, and RFC 3463 allows exactly three values.
| Class | Name | What the specification says | Sender action |
|---|---|---|---|
2 | Success | The report describes a positive delivery action. | Nothing. Only surfaced when success reporting was requested. |
4 | Persistent Transient Failure | The message as sent is valid, but a temporary condition caused delay or abandonment. | Retry on schedule. Never suppress the address. |
5 | Permanent Failure | A condition not likely to be resolved by resending the message in its current form. | Stop. Fix the cause, or suppress if the address itself is the problem. |
The specification calls class 4 a persistent transient failure, not a momentary one. A 4.x.x code means retries are legitimate and the address is good. Treating it as a hard bounce deletes valid recipients, which is the most expensive mistake in this whole taxonomy. See how hard and soft bounces actually map to these classes.
The eight subject sub-codes
The second field says which part of the mail system reported the problem. This is the field that routes a bounce to the right owner: an addressing problem belongs to the list, a network problem belongs to the infrastructure, a security problem belongs to whoever manages authentication and reputation.
| Subject | Name in RFC 3463 | What it covers |
|---|---|---|
X.0.x | Other or Undefined Status | No more precise code applies. |
X.1.x | Addressing Status | The recipient or sender address itself. |
X.2.x | Mailbox Status | The destination mailbox, once the address is known good. |
X.3.x | Mail System Status | The receiving host as a whole, not one mailbox. |
X.4.x | Network and Routing Status | Connectivity, DNS, routing and queue lifetime. |
X.5.x | Mail Delivery Protocol Status | The SMTP conversation itself. |
X.6.x | Message Content or Media Status | Encoding, media types and conversion. |
X.7.x | Security or Policy Status | Authorization, authentication, filtering and crypto. |
Every status code defined by RFC 3463
The document enumerates forty eight detail codes. The titles below are the ones written in the specification, not paraphrases, because bounce parsers and vendor documentation quote them literally and small wording differences make grep patterns fail.
| Code | Title in RFC 3463 |
|---|---|
X.0.0 | Other undefined status |
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 mailbox address valid |
X.1.6 | Mailbox has moved |
X.1.7 | Bad sender’s mailbox address syntax |
X.1.8 | Bad sender’s system address |
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.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.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.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.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.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 |
Why the codes are written with an X
This is the detail that most summaries of RFC 3463 skip, and it is the one that changes how you write bounce handling. The specification never writes 5.2.2. It writes X.2.2, because the subject and detail pair describes the condition while the class describes its persistence, and the two are chosen independently by the reporting server.
The same condition therefore appears in two forms with opposite consequences. X.2.2 is Mailbox full. Reported as 4.2.2, it is a mailbox that is temporarily out of space and the message will be retried. Reported as 5.2.2 by a server that has given up on that mailbox, it is permanent. The three characters after the first dot are identical. Only the leading digit tells you whether the address survives.
Match on the class first and the subject second, never on the full three field string alone. A rule that suppresses on 2.2 without checking the class will delete every recipient whose mailbox was briefly full. This is the failure mode described in bounce categorization beyond hard versus soft, and it is why a suppression list needs the class recorded next to the address.
RFC 3463 is no longer the complete list
Anyone who has read a modern bounce log has met codes that are not in the table above: 5.7.25, 5.7.26, 5.1.10 and others. They are not vendor inventions and they are not violations of the standard. RFC 3463 expected the code space to grow but provided no mechanism for registering new entries, and for five years the space grew informally.
RFC 5248, published in June 2008 by T. Hansen and J. Klensin and designated BCP 138, closed that gap. It created the IANA SMTP Enhanced Status Codes registry, split into three tables for class sub-codes, subject sub-codes and enumerated status codes, and seeded it with the codes from RFC 3463 plus those already established in other standards track documents and in industry practice. New codes are added under a Specification Required policy.
The operational takeaway is simple. RFC 3463 remains the specification for the code model, and the class and subject meanings on this page are still authoritative. It is no longer the authoritative inventory of detail codes. When you meet a code you do not recognize, the IANA registry is where to look it up, not this RFC.
How to parse a code you do not recognize
RFC 3463 anticipated exactly this situation and gives a rule for it. Clients should preserve the extensibility of the code space by reporting the general error described in the subject sub-code when the specific detail is unrecognized.
That is a three step degradation, and it is the correct shape for any bounce parser. Try the full code. If it is unknown, fall back to the class and subject pair and treat it as the generic condition for that subject. If the subject is also unknown, fall back to the class alone, which is never unknown because only three values exist. A parser built this way never crashes on a code registered after it was written, and it never silently misclassifies one either. The DSN parsing guide covers where in a bounce report the Status field actually lives.
Where you meet these codes in practice
Enhanced codes reach you through two channels. The first is the live SMTP conversation, where a server that advertises the ENHANCEDSTATUSCODES extension in its EHLO response prefixes its reply text with the code. The extension is defined in RFC 2034, not in RFC 3463, which is a distinction worth keeping: RFC 3463 says what the codes mean, RFC 2034 says how they travel in an SMTP reply.
The second is the bounce message itself. The DSN format carries a mandatory Status field on every per-recipient block, and that field holds an enhanced code and nothing else. For a sender processing bounces at volume, this is the more useful of the two, because it is structured and because it arrives even for failures that happened after the original connection closed. Individual codes on this site walk through the common cases end to end: 5.1.1 user unknown, 5.7.1 delivery not authorized, 553 5.3.0 rejected and 4.2.0 greylisting among them.
Related standards
- RFC 1893: the predecessor, obsoleted by RFC 3463 in 2003
- RFC 2034: the ENHANCEDSTATUSCODES SMTP extension that carries the codes in replies
- RFC 5248 (BCP 138): the IANA registry that superseded this list
- RFC 3464: the DSN format whose Status field holds the code
- RFC 6522: the multipart/report container that wraps a DSN
- RFC 5321: the SMTP reply codes the enhanced codes sit beside
- RFC 4954: SMTP authentication, updated by RFC 5248 for its 5.7.x codes
- RFC 5965: ARF, the complaint format that does not use these codes
For the wider picture of how these documents fit together, the email RFC directory indexes the full set, and the SMTP error codes reference maps individual codes to their fixes. Security related rejections in the X.7.x range usually trace back to authentication results, which the Authentication-Results header records explicitly.
Frequently asked questions
What is RFC 3463?
RFC 3463 is the January 2003 Standards Track specification that defines enhanced mail system status codes, the three field X.Y.Z numbers that appear alongside SMTP reply codes and inside bounce reports. It defines the code model, the three classes, the eight subject categories and forty eight detail codes.
What is the difference between RFC 3463 and RFC 1893?
RFC 1893 was the original 1996 specification of enhanced status codes. RFC 3463 obsoletes it. The code model is the same, so documentation that cites RFC 1893 is not wrong about the structure, but RFC 3463 is the current reference and RFC 1893 should not be cited as authoritative today.
Are enhanced status codes the same as SMTP reply codes?
No. The SMTP reply code is the three digit number such as 550 or 452, defined in RFC 5321. The enhanced status code is the dotted number such as 5.1.1 or 4.2.2, defined here. They travel together and their first digits agree, but the enhanced code carries far more detail and is standardized across servers, which the free text after it is not.
What does the X mean in codes like X.1.1?
It is a placeholder for the class digit. RFC 3463 writes the codes with an X because the same condition can be reported as temporary or permanent depending on the server. X.1.1 becomes 5.1.1 when the mailbox is permanently unknown. Read the class digit separately from the rest of the code.
Where is the current list of enhanced status codes?
In the IANA SMTP Enhanced Status Codes registry, created by RFC 5248 in 2008 and designated BCP 138. RFC 3463 lists only the codes that existed in 2003. Codes such as 5.7.25 and 5.7.26 are registered there and are perfectly valid despite being absent from RFC 3463.
What should a parser do with a code it does not recognize?
Fall back to the subject sub-code and report the general error for that subject, which is what section 2 of RFC 3463 asks clients to do. If the subject is also unknown, fall back to the class digit, which is always one of 2, 4 or 5. Never discard the code or default to permanent failure.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
