Email Bounce Codes Explained: 550, 421, and More

A Bounce Isn't Just "It Failed"

Open a bounce notification and it's easy to skim past the actual message and just note the address as dead. That's a mistake, because every bounce a mail server sends back carries a specific numeric code, and that code is the difference between "this address is permanently gone" and "try again in an hour." Reading the code instead of guessing turns a pile of bounce logs into a clear action list.

These codes follow a standard defined in the SMTP protocol itself (RFC 5321), so the same three-digit structure shows up whether the bounce came from Gmail, Outlook, or a small business mail server.

The First Digit Is the Only One That Really Matters

SMTP reply codes are three digits, and the first digit tells you the category. You can act on almost every bounce correctly just by reading this one number:

• 2xx — Success. The message was accepted. You won't see this in a bounce log; it's what "delivered" looks like under the hood.
• 4xx — Temporary failure (soft bounce). The receiving server couldn't accept the message right now, but the address itself isn't necessarily bad. A full mailbox, a rate limit, or a server that's briefly down all produce a 4xx. Retry later; don't remove the address on a single 4xx.
• 5xx — Permanent failure (hard bounce). The server is telling you, unambiguously, to stop trying with this exact address. The mailbox doesn't exist, the domain is unreachable, or the message was flatly rejected. Remove these.

That single rule — 4 means "wait," 5 means "remove" — resolves the majority of bounce-handling decisions correctly without reading anything else.

Enhanced Status Codes: The Second Layer of Detail

Most modern bounce messages also include an enhanced status code in the format X.Y.Z — for example 5.1.1 — sitting alongside the basic three-digit reply. This extended format, maintained in an IANA registry, narrows the reason down further. 5.1.1 specifically means "bad destination mailbox address" — the account doesn't exist. 5.1.2 means the domain itself couldn't be found. 5.7.1 usually means the message was rejected for a policy reason, like spam filtering, rather than a dead address. When you're triaging bounces at scale, the enhanced code is what tells you whether you have a list-quality problem or a content/reputation problem.

The Bounce Codes You'll Actually See

Code	Meaning	What to do
550 / 5.1.1	Mailbox doesn't exist	Remove immediately
551 / 5.1.6	User no longer at this address (moved/forwarded permanently)	Remove — it's not coming back
552 / 5.2.2	Mailbox full (over quota)	Soft-fail in disguise — but treat repeated 552s over weeks as effectively dead
553 / 5.1.3	Malformed or invalid address syntax	Remove — this should have been caught before sending
421 / 4.7.0	Service temporarily unavailable / rate-limited	Retry with backoff; often your sending pace, not their inbox
450 / 4.2.1	Mailbox temporarily unavailable (often greylisting)	Retry automatically; most mail systems handle this without your input
554 / 5.7.1	Rejected for policy reasons (spam filtering, blocklist)	Investigate sender reputation and content — not a list-hygiene fix

Where a Validator Fits — and Where It Doesn't

Notice that most of the codes worth acting on immediately — 550, 551, 553 — are exactly the failures a mailbox-level validation check surfaces before you send, not after. BounceBuster performs format, DNS/MX, and SMTP-level mailbox checks locally on your machine, which means it's asking the receiving server the same question a real send would ask ("does this mailbox exist?") without actually delivering a message. Catch the 5.1.1s in a pre-send validation pass and you never generate the hard bounce in your ESP's logs at all.

What a validator can't do is fix a 554/5.7.1. That code has nothing to do with whether the address is real — it's the receiving server telling you your content, sending pattern, or domain reputation tripped a filter. That's an authentication and reputation problem, covered in our guides on SPF, DKIM, and DMARC and improving sender reputation. Bounce codes are diagnostic; some point at your list, some point at your sending practices, and knowing which is which saves you from "fixing" the wrong thing.

A Simple Triage Rule

1. See a 5xx? Remove the address. It's permanent.
2. See a 4xx once or twice? Leave it — retry logic in your ESP handles this automatically.
3. See the same 4xx across multiple sends over several weeks? Treat it as effectively dead and remove it, even though technically it's still "soft."
4. See a 554 or other policy rejection across many addresses at once? Stop and check your authentication setup and content — this isn't a list problem.

Most of this triage work disappears if you validate before you send rather than after. BounceBuster runs the same mailbox-existence check locally, for a one-time $19 with no per-email fees, so the 550s and 551s never make it into your ESP's bounce log in the first place. Download it free and validate your first 600 addresses before your next campaign.