When a message can’t be delivered, the receiving server replies with a three-digit SMTP reply code and, increasingly, a more precise enhanced status code. Read them together and you know both the severity and the cause. Two rules cover 90% of cases: the first digit of the reply code sets the class, and the enhanced code pinpoints the reason.
The one rule that decodes everything: the first digit
Per RFC 5321, the leading digit of every SMTP reply is the class:
- 2xx — success. The server accepted the message (e.g.
250). No action needed. - 4xx — transient failure. Temporary. Keep the recipient and let your server retry over the next hours or days. Do not remove the address.
- 5xx — permanent failure. Retrying won’t help. Fix the underlying cause, and suppress or re-verify the address before sending again.
Enhanced status codes from RFC 3463 follow the same convention. They’re written class.subject.detail — for example 5.1.1: class 5 (permanent), subject 1 (address problem), detail 1 (mailbox doesn’t exist). The class digit always matches the reply code’s first digit, so the two never contradict each other.
Permanent codes (5xx) — suppress or fix
| Code | Meaning | What to do |
|---|---|---|
550 5.1.1 | Mailbox doesn’t exist (no such user). The most common hard bounce. | Remove the address immediately. Re-verify — usually a typo or a former employee. |
5.2.1 | Mailbox disabled — suspended, deactivated or blocked at the account level. | Suppress. Don’t keep retrying a closed account. |
552 / 5.2.2 | Mailbox full / over quota. Marked permanent, but often actually temporary. | Retry over a day or two; the mailbox may free up. Suppress only if it keeps failing. |
551 / 553 | User not local / mailbox name not allowed — bad address or a rejected sender. | Fix the address or envelope sender; remove if it can’t be corrected. |
550 5.7.1 | Delivery not authorized — relaying denied, or a policy/reputation block. | If relaying was denied you’re hitting the wrong server. If it’s a policy block, check authentication and reputation. |
554 5.7.1 | Transaction failed — most often a spam, content or blocklist rejection. | Read the diagnostic text. Check SPF/DKIM/DMARC and run a blacklist check. |
550 5.7.26 | Gmail: message failed authentication (bulk-sender enforcement). SPF/DKIM must pass and align. | Sender-side, not a bad address. Align SPF and DKIM with your From domain and publish DMARC. |
550 5.7.515 | Outlook/Office 365: the From domain’s DMARC (or tenant policy) rejected the message. | Confirm DMARC passes with aligned SPF/DKIM. Review your published record. |
Notice the split within the 5xx family: 5.1.x and 5.2.x codes are about the recipient (dead or disabled mailbox — suppress the address), while 5.7.x codes are about policy and authentication (the recipient is fine — fix your setup). Suppressing a recipient over a 5.7.x block is a common and costly mistake.
Transient codes (4xx) — retry, don’t remove
| Code | Meaning | What to do |
|---|---|---|
421 4.7.0 | Temporary deferral — greylisting, throttling, or a reputation-based hold. | Retry after a short delay. Most greylisters accept on the second attempt. |
450 4.x.x | Mailbox temporarily unavailable — often greylisting. | Retry after a delay; usually accepted on a later attempt. |
451 4.3.0 | Local error in processing at the receiving server. | Retry later — it’s the receiver’s problem and normally clears on its own. |
452 4.2.2 | Insufficient storage / mailbox full (temporary), or too many recipients right now. | Retry over a day or two, or send to fewer recipients per message. |
4.7.28 | Rate-limited because of your sending IP’s reputation (Gmail). | Reduce volume, warm up the IP, clean your list, then retry gradually. |
The key discipline with 4xx codes is patience: your mail server retries automatically, and removing an address on its first soft bounce throws away a perfectly reachable recipient. Only suppress a transient failure when it repeats consistently across several days.
Reading a real bounce: where the codes hide
A delivery status notification (RFC 3464) puts the useful codes on specific lines. The Status: field carries the enhanced code, and the Diagnostic-Code: line usually contains both the reply code and the server’s human-readable reason:
Action: failed Status: 5.1.1 Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach does not exist.When both are present, trust the enhanced code — it’s more specific than the three-digit reply. If a code’s severity looks ambiguous (mailbox-full is the classic example), the diagnostic text after the code is your tiebreaker.
Decode your bounce automatically
You don’t have to memorise the table. Paste an entire bounce message into the Bounce Message Analyzer and it extracts the reply and enhanced codes, classifies the failure as permanent or transient, and tells you whether to suppress or retry — all in your browser, nothing sent anywhere. To look up a single code in isolation, use the SMTP Response Code Analyzer. And before you permanently remove an address, confirm it’s genuinely dead with the Email Verifier.
Common failure modes
- Treating every 5xx as a dead address. A
5.7.xcode is an authentication or reputation block — the recipient is fine. See fixing Gmail and Outlook rejections. - Suppressing a 4xx too early. Transient failures resolve themselves. Let the server retry before removing anyone.
- Ignoring the diagnostic text. When a code is ambiguous (like mailbox-full
552), the server’s own words tell you whether it’s temporary. - Never suppressing hard bounces. Repeatedly mailing a
550 5.1.1address wrecks your reputation. Suppress on the first permanent mailbox failure and keep your bounce rate under ~2%.
Sources
SMTP reply codes and the meaning of their first digit are defined in RFC 5321. The enhanced status code structure (class.subject.detail) is specified in RFC 3463, and the delivery status notification format that reports a bounce is RFC 3464. Provider-specific codes like Gmail’s 5.7.26 and Outlook’s 5.7.515 are documented by those providers; the industry’s ~2% bounce-rate warning line is a widely-used benchmark rather than a single published rule.