KoltrixSMTP enhanced status codes (RFC 3463), decoded
Enhanced status codes like 5.1.1 and 4.7.0 say why delivery failed. Learn the class.subject.detail structure and the codes you will see most often.
On this page(8 sections)
- Where enhanced codes come from
- The structure: class.subject.detail
- Class
- Subject
- Detail
- Codes you will see most often
- Addressing (X.1.X)
- Mailbox status (X.2.X)
- Mail system and network (X.3.X, X.4.X)
- Content (X.6.X)
- Security and policy (X.7.X)
- Reading codes alongside the text
- Enhanced codes in bounce messages
- Practical rules
- Quick reference
- Key takeaways
A three-digit SMTP reply tells you whether delivery failed. The enhanced status code next to it tells you why.
Once you can read 5.1.1, 4.7.0 and 5.7.26 at a glance, bounce logs stop being noise and start being a diagnosis.
Where enhanced codes come from
The classic SMTP reply codes from RFC 5321, such as 250, 450 and 550, are coarse. RFC 3463 added enhanced mail system status codes, which appear in SMTP replies (when the server supports the ENHANCEDSTATUSCODES extension) and in delivery status notifications.
550 5.1.1 The email account that you tried to reach does not exist.Here 550 is the basic reply code and 5.1.1 is the enhanced status code. The rest is free-form diagnostic text, which differs by server.
The IANA "Enumerated Status Codes" registry tracks codes defined across several RFCs, including ones added after RFC 3463 for authentication and security.
The structure: class.subject.detail
Each enhanced code has three parts.
Class
| Class | Meaning |
|---|---|
| 2 | Success |
| 4 | Persistent transient failure: the message was valid, but delivery failed for now and may succeed later |
| 5 | Permanent failure: delivery will not succeed without some change |
The class should match the first digit of the basic reply code.
Subject
The subject identifies the area of the problem:
| Subject | Area |
|---|---|
| X.0.X | Other or undefined |
| X.1.X | Addressing (the recipient or sender address) |
| X.2.X | Mailbox status |
| X.3.X | Mail system (the receiving system itself) |
| X.4.X | Network and routing |
| X.5.X | Mail delivery protocol |
| X.6.X | Message content or media |
| X.7.X | Security or policy |
Detail
The detail narrows it down within the subject. 5.1.1 and 5.1.2 are both addressing problems, but one says the mailbox does not exist and the other says the domain does not.
Codes you will see most often
Addressing (X.1.X)
| Code | Meaning | Typical action |
|---|---|---|
| 5.1.1 | Bad destination mailbox address: the user does not exist | Suppress the recipient |
| 5.1.2 | Bad destination system address: the domain does not exist or cannot receive mail | Suppress; check for typos |
| 5.1.3 | Bad destination mailbox address syntax | Fix validation at collection |
| 5.1.6 | Destination mailbox has moved, no forwarding address | Suppress |
| 5.1.8 | Bad sender's system address | Check your envelope sender domain |
| 5.1.10 | Recipient address has a null MX (RFC 7505) | Suppress; the domain accepts no mail |
Mailbox status (X.2.X)
| Code | Meaning | Typical action |
|---|---|---|
| 4.2.1 / 5.2.1 | Mailbox disabled, not accepting messages | Retry if 4xx; suppress if persistent |
| 4.2.2 / 5.2.2 | Mailbox full | Retry; suppress only after repeated failures over time |
| 5.2.3 | Message length exceeds administrative limit | Reduce message size |
Mail system and network (X.3.X, X.4.X)
| Code | Meaning | Typical action |
|---|---|---|
| 4.3.1 | Mail system full (the server, not the mailbox) | Retry later |
| 4.3.2 | System not accepting network messages | Retry later |
| 5.3.4 | Message too big for system | Reduce size |
| 4.4.1 | No answer from host | Retry; check MX health |
| 4.4.2 | Bad connection | Retry |
| 5.4.4 | Unable to route | Check the recipient domain's DNS |
| 4.4.7 | Delivery time expired | Your retries ran out; message was not delivered |
Content (X.6.X)
| Code | Meaning | Typical action |
|---|---|---|
| 5.6.0 | Other or undefined media error | Inspect the message structure |
| 5.6.3 | Conversion required but not supported | Pre-encode content (for example, base64 or quoted-printable) |
Security and policy (X.7.X)
This subject matters most for deliverability, because it covers rejections that are about you, not the recipient.
| Code | Meaning | Typical action |
|---|---|---|
| 5.7.0 / 4.7.0 | Other or undefined security status, often used for generic policy blocks | Read the text; investigate reputation |
| 5.7.1 | Delivery not authorized, message refused | Usually policy: blocklist, reputation or content |
| 4.7.1 | Temporary policy refusal, often rate or reputation related | Slow down; retry |
| 5.7.23 | SPF validation failed | Fix SPF for your envelope sender |
| 5.7.25 | Reverse DNS validation failed | Fix the PTR record for your sending IP |
| 5.7.26 | Multiple authentication checks failed | Check SPF, DKIM and DMARC together |
| 5.7.27 | Sender address has null MX | Your sender domain refuses mail; give it a real MX |
Some of these, such as 5.7.23 to 5.7.27, were registered after RFC 3463 by later RFCs on email authentication. Not every server uses them, and large providers often use generic 5.7.1 or 4.7.0 with descriptive text instead. Gmail, for example, has used 5.7.26 and related codes in rejections for unauthenticated mail, but the exact codes and text any provider uses can change.
Reading codes alongside the text
Enhanced codes are not always used consistently. Some servers send 5.0.0 for everything; some use 5.1.1 for policy rejections to avoid revealing which addresses exist. Always read the diagnostic text too:
550 5.7.1 Message rejected due to sender reputation. See https://receiver.example/policy
452 4.2.2 The email account that you tried to reach is over quota.
421 4.7.0 Try again later, closing connection.The first is a policy block, the second a full mailbox, the third a rate limit or temporary reputation issue. Each needs a different response.
Enhanced codes in bounce messages
Not every failure happens during your SMTP session. When a receiving system accepts a message and fails later, for example because an internal relay could not reach the final mailbox, it sends a delivery status notification back to your envelope sender. DSNs use the format in RFC 3464, and the machine-readable part carries the enhanced code in a Status: field, alongside a Diagnostic-Code: field with the remote server's original reply:
Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknownParse the Status: field the same way you parse SMTP replies, so synchronous and asynchronous bounces flow through one classification path. The Action: field also matters: delayed is an interim warning that delivery is still being retried, not a failure, and it should never trigger suppression.
Practical rules
- Suppress on 5.1.1, 5.1.2 and 5.1.10, ideally confirmed by matching text.
- Never suppress on 5.7.x. These are about your mail or your reputation.
- Retry 4.x.x with backoff, and cap repeated failures per recipient across separate messages.
- Treat 4.4.7 as a final failure generated by a sending system after its retry window expired.
- Store the raw code and text for every failure so you can refine your rules.
Quick reference
X.1.X address problem -> check the recipient; 5.1.1/5.1.2 = suppress
X.2.X mailbox problem -> full or disabled; usually retry first
X.3.X receiving system -> retry; size limits need a smaller message
X.4.X network or routing -> retry; check DNS for 5.4.x
X.5.X protocol -> check your SMTP client
X.6.X content -> fix encoding or structure
X.7.X security or policy -> fix authentication or reputation; never suppressKey takeaways
- Enhanced status codes (RFC 3463) use a class.subject.detail structure that says why delivery failed.
- The subject digit is the fastest triage: 1 is addressing, 2 is mailbox, 7 is security or policy.
- 5.1.1, 5.1.2 and 5.1.10 justify suppression; 5.7.x never does.
- Providers apply codes inconsistently, so always read the diagnostic text as well.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
