# SMTP Enhanced Status Codes (RFC 3463)

> The X.Y.Z enhanced mail system status code taxonomy — classes, subjects, and the full detail-code table — and how to use it for bounce classification.

Source: emailmarketing.net — https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes

When a message is refused or bounces, the reply usually carries a code such as `5.1.1` or `4.2.2`. These codes tell you whether the failure is permanent and which part of the mail system failed, which makes them the most useful single input for classifying bounces automatically.

RFC 3463 defines these **enhanced mail system status codes**. The `X.Y.Z` codes appear in SMTP replies and in the `Status:` field of [delivery status notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications). They exist because the basic 3-digit SMTP reply codes (250, 450, 550…) mix up transport results with the meaning of the delivery outcome. Enhanced codes give a reason that machines can parse and that does not depend on the transport.

## 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: a positive delivery action | Not a bounce |
| `4.X.X` | Persistent transient failure: the message is valid, but a temporary condition caused a delay or made the server give up | **Soft bounce**: retry, and suppress only after repeated failures |
| `5.X.X` | Permanent failure: resending the message in its current form is not likely to resolve it | **Hard bounce**: do not retry unchanged, and suppress the address when the cause concerns the address |

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

| Subject | Category |
|---|---|
| `X.0.X` | Other or 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 or 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 or 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

These are the combinations that carry the most information for a suppression engine:

| Observed status | Interpretation | Typical action |
|---|---|---|
| `5.1.1`, `5.1.2`, `5.1.3`, `5.1.6` | The address does not exist, cannot be routed, or has gone | Hard bounce: suppress immediately. Repeated 5.1.1s are also how providers detect stale lists |
| `5.2.1` | Mailbox disabled | Suppress. The account has been abandoned or closed |
| `4.2.2` | Mailbox full | Soft bounce: retry, and suppress if it keeps recurring (often an abandoned account) |
| `5.2.2` | Mailbox full, reported as permanent | Treat like a 4.2.2 that keeps recurring |
| `4.3.x`, `4.4.x` | Trouble with the destination system or network | Retry. Not a sign of list quality |
| `4.4.7` | Delivery time expired (retries exhausted) | The sending side gave up. Investigate which underlying condition persisted |
| `5.3.4` / `X.2.3` | Message too big, or exceeds an administrative limit | Fix the message, not the list |
| `5.7.1` and other `5.7.x` | Refusal for policy or security reasons | **A reputation or authentication problem, not a bad address.** Do not suppress the recipient on a policy refusal; see [Status codes and the M3AAWG removal rule](#status-codes-and-the-m3aawg-removal-rule) for the one-address exception. Check blocklists, [DMARC, SPF and DKIM](https://emailmarketing.net/learn/authentication/dmarc), and volume and warm-up (see [IP Warm-Up](https://emailmarketing.net/learn/ip-management/ip-warm-up)) |
| `4.7.x` | Temporary deferral for policy reasons (greylisting, rate limiting, "unusual volume") | Slow down. This is the classic throttling signal during warm-up |

Caveats:

- The class digit decides how to retry, even when the subject and detail seem to contradict it. In the model of RFC 3463, the first number's judgment of whether the failure is permanent wins.
- Many receivers return only a generic code (`5.0.0`) or nonstandard text. Reliable classifiers combine the enhanced code with the free-text `Diagnostic-Code` (see [Delivery Status Notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications)).
- Later RFCs and IANA registrations extend this list. For example, RFC 7372 registers additional 5.7.x codes for SPF and DMARC failures. The codes above are the base set from RFC 3463 that every implementation shares.

## Status codes and the M3AAWG removal rule

The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) sets the industry baseline for removing addresses that bounce, in its *Sender Best Common Practices* (Version 4.0, August 2026, section 2.2). Its advice has three parts:

- When the receiver says there is no one at that address ("user unknown"), do not retry, and suppress the address from future mailings.
- The numeric codes were not designed to say whether an address should be removed, so senders **must** read the descriptive text to decide how to handle the address. The text can point to a problem with the sender's infrastructure or content, or show that the sender's IP address is on a blocklist. Senders **should** try to diagnose and fix delivery problems for addresses that appear to be valid.
- As a general best practice, remove an address that bounces at least twice in a row, across a span of two weeks or more, whatever the code or text. Each sender chooses the exact number of campaigns and the time span, and the time span allows for server problems at the receiver that can cause a bounce in error.

The table above says not to suppress the recipient on a `5.7.x` policy refusal, with one exception for a single address (case 4 below). The reason is what those codes usually report. A `5.7.x` is a refusal for security or policy reasons: a blocklisting, failed authentication, a reputation block. Those causes belong to the sender, and they usually hit many recipients at the same provider at once. Suppressing every address that received one removes real subscribers because of a problem on your side, and leaves the problem in place.

Apply both rules together:

1. **Failures about the address** (`5.1.1`, `5.1.2`, `5.1.3`, `5.1.6` and `5.2.1`): suppress, as the table says. They are the "user unknown" case in M3AAWG's advice.
2. **Other failures that repeat for one address** (a recurring mailbox full, or a generic `5.0.0` whose text does not name a policy): count one bounce per campaign, not one per retry. Remove the address when the count reaches your threshold and the bounces span at least two weeks. Two campaigns is M3AAWG's minimum; a higher count still follows its rule.
3. **Policy and reputation refusals** (`5.7.x`): investigate instead of suppressing. Read the text, check blocklists and authentication, and fix the cause. Bounces received while you were blocked say nothing about the addresses, so do not count them toward any address's removal count.
4. **A `5.7.x` that repeats for one address only**, over at least two campaigns and two weeks, while other addresses at the same domain accept your mail: this points to the recipient, not to your reputation (for example, a mailbox that refuses your mail by its owner's choice). Treat it like case 2, under the M3AAWG removal rule.

For the suppression mechanics a platform applies, see [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring#suppression-lists-as-a-reputation-defense).