/ TL;DR
Every bounce has two numbers and a sentence. The basic reply code (like 550) tells your server what to do — 4xx means retry, 5xx means stop. The enhanced status code (like 5.7.26) says where the failure lives: the middle digit is 1 for an address problem and 7 for a policy or authentication problem.
That middle digit is the key. A 5.1.1 means the address is bad — suppress it. A 5.7.x means you're blocked by policy or failed authentication — the address is usually fine, and the fix is on your side, so suppressing it would be a mistake. Providers use different codes for the same failure, so trust the structure and read the human-readable text.
4xx codes (421, 450, 452) retry automatically over about 72 hours — leave them alone unless they persist or come from provider enforcement. 5xx codes are permanent for that message: suppress bad addresses, fix authentication and reputation for policy blocks.
/ 01
Anatomy of a bounce
A bounce looks cryptic until you see it's three parts stacked, each adding detail. A typical rejection reads something like 550 5.7.26 Unauthenticated email is not accepted, and each piece answers a different question.
The first part, 550, is the basic reply code from the core SMTP standard — three digits meant for the sending machine to act on automatically. The second, 5.7.26, is the enhanced status code from a later standard, a dotted triple that adds diagnostic precision. The third, the sentence after it, is the human-readable text — the part most people skip and shouldn't, since different receivers word the same failure differently, and that wording is frequently where the actual reason and fix live.
One more distinction shapes how you'll encounter these. A bounce can be synchronous, rejected live during the SMTP conversation so your server sees the code immediately, or asynchronous, where the receiver accepts the message and only later returns a non-delivery report — an actual email, also called a DSN or bounce message, carrying the same codes plus the diagnostic text inside it. Asynchronous bounces are harder to parse because the detail is buried in that report, which is where a header and message analyzer helps. Our email header analyzer pulls the codes and routing out of a bounce message for you.
/ 02
The first digit: retry or stop
The single most useful thing a bounce tells you is in its first digit, which is a routing instruction for your sending server. A 4 means try again: the failure is transient, the message itself is valid, and a temporary condition merely delayed it. A 5 means stop: the failure is permanent for the message as sent, and repeating the exact same attempt will only reproduce it. (A 2 means success; a 3 means the server wants more input.)
This maps onto the familiar soft-versus-hard bounce distinction. A 4xx is a soft bounce — your server queues the message and retries on its own, so normally you do nothing at all. A 5xx is a hard bounce — retrying without changing anything is pointless, and hammering a receiver that has permanently rejected your mail damages your reputation with each attempt.
The enhanced status code repeats this verdict in its class, the first number: class 4 is a persistent transient failure, class 2 is success, and class 5 is a permanent failure. The two should agree — a well-formed bounce won't pair a 5xx reply code with a 4.x.x enhanced code. When triaging a report full of codes, sorting by that first digit is the fastest cut: everything starting with 4 resolves itself or times out; everything with 5 needs a decision.
/ 03
The middle digit: where it failed
If the first digit tells you whether to stop, the middle digit of the enhanced status code — the subject — tells you where the failure lives, and it's the number that prevents the most expensive mistake in bounce handling. It classifies the failure: a subject of 1 is an address problem, 2 is a mailbox problem, 3 is the mail system, 4 is network or routing, and 7 is security or policy.
The two that matter most in daily life are 1 and 7, and confusing them is costly. A 5.1.x — most often 5.1.1, the address doesn't exist — is genuinely the recipient's problem: the mailbox is gone or was never real, so you suppress it and move on. A 5.7.x is a different animal: a security or policy rejection, meaning the receiver looked at your authentication, reputation, or content and refused the message — the recipient address is very often perfectly valid.
That difference is the whole game. When a 5.7.x bounce arrives, suppressing the address is the wrong move — you'd be deleting a good contact to punish yourself for a problem on your sending side. The correct response is to fix what the receiver objected to: repair SPF, DKIM, or DMARC, clear a blocklisting, or improve reputation. Read the middle digit before you touch the list.
/ 04
Common 4xx codes
The transient codes are a short, well-understood set; the right action is almost always to let your queue do its job. 421 is a temporary refusal — the receiver is rate-limiting you, under load, or deliberately deferring — frequently paired with a 4.7.0. 450 and 451 signal a mailbox temporarily unavailable or a local processing error, and a 452 4.2.2 is a full mailbox.
A common source of 4xx codes is greylisting, a spam-fighting tactic where the receiver deliberately rejects a first delivery attempt with a temporary error, expecting a legitimate server to retry a few minutes later while most spam engines won't bother. It's designed to be invisible: your queue retries, the second attempt succeeds, and the only cost is a short delay. Greylisting retries shouldn't count toward any soft-bounce threshold, since they're normal behavior rather than a problem.
Two 4xx situations do call for action. The first is a transient failure caused by something you can fix — an oversized attachment, an expired credential — where the right move is to correct it and let the next retry carry the fixed message. The second is provider enforcement: some receivers, Gmail notably, now issue transient 4.7.x warnings that escalate to permanent 5xx rejections if you don't fix the underlying authentication or compliance problem in time. A 4xx that keeps repeating with the same code, or that names an auth issue, is a warning to act on rather than wait out.
/ 05
Common 5xx codes
The permanent codes are where the reading really pays off, because 550 alone tells you almost nothing — it's the reply code for a permanent rejection, and the enhanced code after it carries the actual meaning. A 550 5.1.1 is the classic bad address, the recipient doesn't exist, and it should come straight off your list. A 550 5.2.x points at the mailbox — disabled or, if paired with a size condition, over quota permanently.
The 550 5.7.x family is the authentication and policy set, and it's grown as providers tightened their rules. A generic 5.7.1 is a catch-all policy block — spam, reputation, or a general refusal. A 5.7.26 means unauthenticated mail, a DMARC or SPF or DKIM failure. A 5.7.515-style code from the Microsoft side means a bulk sender hasn't met the required authentication level. Every one of these is fixed by repairing authentication, covered in our authentication guide — not by editing your list.
The remaining permanent codes round out the set. 551 concerns a non-local user or disabled forwarding, 552 is a message over the size limit — providers commonly cap around 20 to 25 MB, so host large files and link to them — and 553 and 554 are broad rejections tied to policy, content, or a blocklisting, sometimes with a bracketed reference or URL. When the text mentions a blocklist, confirm it with our blacklist lookup and start the delisting process. One caution: a 541 isn't a standard SMTP code — it's a vendor anti-spam appliance's own rejection, so read its text rather than the number.
/ 06
Quick reference
The most common codes at a glance. The enhanced code and the human text override the basic number when they disagree, and provider wording varies — treat this as a starting diagnosis, not the last word.
| Code | Meaning | Type | Action |
|---|---|---|---|
| 421 4.7.0 | Temporary deferral — rate limit, load, or greylisting | Transient | Let the queue retry |
| 450 4.7.1 | Mailbox unavailable, often greylisting | Transient | Retry; succeeds on next attempt |
| 451 4.7.1 | Local error or temporary auth hold | Transient | Retry; investigate if persistent |
| 452 4.2.2 | Mailbox full | Transient | Retry; suppress if it persists |
| 550 5.1.1 | Recipient address does not exist | Permanent | Suppress the address now |
| 550 5.2.1 | Mailbox disabled or inactive | Permanent | Suppress the address |
| 550 5.7.1 | Policy block — spam, reputation, or auth | Permanent | Investigate your side; don't suppress |
| 550 5.7.26 | Unauthenticated mail (DMARC/SPF/DKIM) | Permanent | Fix authentication |
| 550 5.7.515 | Bulk-sender auth requirements not met | Permanent | Add SPF, DKIM, DMARC |
| 552 5.3.4 | Message exceeds size limit | Permanent | Reduce size; link large files |
| 553 5.7.1 | Sender rejected — often blocklist or policy | Permanent | Check blocklists; delist |
| 554 5.7.1 | Transaction failed — content or policy | Permanent | Fix the flagged cause |
A closing note on the numbers you'll see from big providers: the same failure wears different codes at different receivers. A DMARC rejection surfaces one way at Gmail, another at Microsoft, another at Yahoo — so match on the structure (a 5.7.x is a policy block wherever it comes from), then read that receiver's own words.
/ 07
How to respond
Reading the code is only useful if it drives the right action, and the actions sort cleanly into three buckets. For a 4xx, do nothing by default — let the queue retry, and step in only if the code keeps repeating or names something you can fix. For a 5.x.x address failure — a 5.1.1 or a disabled mailbox — suppress the recipient immediately; retrying a dead address wastes sends and erodes reputation.
For a 5.7.x policy or authentication failure, resist the urge to touch the list and fix the cause instead. If it names authentication, repair your SPF, DKIM, and DMARC. If it mentions a blocklist, reputation, or abuse, check whether you're listed and pursue delisting while cleaning up what got you there. These are sender-side problems; the addresses are usually fine to keep once the issue is resolved.
Underneath all of it is a number worth watching: keep your hard bounce rate low, generally under a couple of percent, because major providers read a high bounce rate as a sign of a poorly-maintained list and will route you to spam or reject you for it. That makes bounce handling less about reacting to individual codes than about verifying addresses before you send, authenticating so 5.7.x codes never appear, and pruning so 5.1.1s stay rare. Our bounce handling guide covers the workflow that keeps this automatic, and the sender reputation guide covers what those codes are protecting. Keeping that whole loop healthy as you send is the standing operation we run.
/ 08 — FAQ