Email bounces explained: hard vs soft and what to do about each

Bounces are the most under-used signal in email. Senders look at the percentage on the ESP dashboard, sigh if it's above 2%, and move on. But the category of the bounce, the specific SMTP reply, and how you process it afterwards decide whether a bad campaign stays a bad campaign — or becomes a two-month reputation hole you have to dig out of.

What a bounce actually is

A bounce is an SMTP response from the receiving mail server telling your sending server that the message couldn't be delivered. The server either refuses to accept the message during the SMTP conversation (a rejection at RCPT TO or DATA), or it accepts the message and later generates a Delivery Status Notification (DSN) — the bounce-back email most senders think of when they hear the word.

The SMTP reply code decides everything. The first digit of the code is the category: 2xx means success, 4xx means temporary failure, 5xx means permanent failure. Your sending system uses the first digit to decide what to do next. The remaining two digits plus the extended DSN code (5.1.1, 4.7.0) give you the reason.

Hard bounces: 5xx and permanent failure

A hard bounce means the receiving server is telling you with certainty that this address will never accept mail. There is no point retrying. The mailbox doesn't exist, the domain doesn't resolve, or the receiving server has decided you're permanently blocked.

Common 5xx codes you'll see in production:

• 550 5.1.1 User unknown — the mailbox doesn't exist. Most common hard bounce. Always suppress immediately.
• 550 5.1.2 Domain not found — the From domain has no MX. Usually a typo (gmail.con, outloook.com).
• 554 5.7.1 Relay access denied or 554 5.7.1 Message refused — policy rejection. Could be content or could be IP-based blocklisting.
• 553 5.1.8 Sender address rejected — your From address is invalid or unauthenticated.
• 521 5.2.1 Domain does not accept mail — a null MX record. The domain has explicitly said "no email here".

Fix: every hard bounce goes into a permanent suppression list. No exceptions. Never re-add a hard-bounced address from a CSV import six months later — the rules haven't changed.

Soft bounces: 4xx and temporary failure

Soft bounces are the receiver saying "not right now, try again later". The mailbox exists but something is getting in the way. Your sending system should retry — but only on a sensible schedule, and only a limited number of times.

Common 4xx codes:

• 421 4.3.2 Service not available — the server is busy, down, or deliberately deferring you. Retry in 15–30 minutes.
• 450 4.2.1 Mailbox temporarily unavailable — account suspended, temporary lock, or maintenance. Retry in a few hours.
• 451 4.7.1 Try again later — greylisting or rate limiting. Retry after 5–15 minutes; greylisting is usually resolved in one retry.
• 452 4.2.2 Mailbox full — literal mailbox quota. Retry over a day or two; if it persists beyond a week, treat as a hard bounce.
• 452 4.5.3 Too many recipients — you sent too many RCPT TO commands in one session. Your sender's problem, not the recipient's.

Fix: retry 3 times over 48 hours (6h, 24h, 48h is a good schedule). If the address still bounces after the third attempt, move it to suppression. Anything more aggressive looks like a retry storm and can itself trigger blocklisting.

Block bounces: when soft is really a red alarm

Some 4xx responses are technically soft but they're really a reputation-level block. Gmail's famous 421-4.7.0 [IP] Our system has detected an unusual rate of unsolicited mail is the classic example. It's a 4xx — retry in theory — but Gmail is telling you your reputation is bad enough that they're refusing this batch entirely.

Other content-based block bounces to recognise:

• 421 4.7.0 Too many unauthenticated commands — you're sending without proper auth.
• 421 4.7.28 Our system has detected suspicious traffic — Google SafeSearch / anti-abuse trigger.
• 451 4.7.500 Server busy, please try again later (Outlook) — often an SNDS-level block disguised as a defer.
• 450 4.7.1 Client host rejected: Access denied — IP on a receiver's internal blocklist.

Fix: do not blindly retry. If you see more than a handful of these per thousand sends, pause the campaign, check Postmaster Tools, check SNDS if you're hitting Outlook, and stop burning reputation. A retry storm on top of a block bounce makes the block harder to lift.

Bounce rate thresholds that matter

The industry-quoted numbers are remarkably consistent across Gmail, Outlook, Yahoo and the bigger ESPs. Memorise these:

• Under 2% — healthy. No action needed.
• 2–5% — warning zone. Start looking at list sources.
• 5–10% — you're going to start seeing throttling. Gmail will defer more of your mail. Outlook's SmartScreen will increase Spam placement.
• Above 10% — active reputation damage. Expect blocklistings and ESPs suspending your account. This is what happens after a bought-list import.

Keep an eye on the trend, not just the absolute number. A steady 1.5% is fine. A jump from 0.8% to 3.1% in one campaign is a red flag even if 3.1% is still "okay".

How to process bounces in practice

The job of your sending system is to translate bounce codes into three decisions: suppress immediately, retry later, or pause the campaign. Here's a safe default policy:

1. Any 5xx → suppress the address permanently. Log the reason for audit, but never send again.
2. 4xx on a fresh address → retry 3 times on a 6h / 24h / 48h curve. After 3 failed attempts → suppress.
3. 4xx that mentions "policy", "blocked", "suspicious", "unusual rate" → pause the whole campaign to that ISP for at least 6 hours. Investigate reputation.
4. Complaint feedback loop (FBL) hit → suppress the address and note the complaint for analytics. Stop sending, don't retry.
5. Mailbox full (452 4.2.2) persisting 7+ days → promote to suppression. It's an abandoned account.

Most ESPs (Mailgun, Postmark, SendGrid, Amazon SES) handle the mechanics for you. If you send through your own MTA (Postfix, Haraka, Halon), you own this logic — and most self-hosted senders get it wrong by retrying 5xx bounces or suppressing on a single 4xx.

Where list validation fits

Bounce handling is reactive. List validation is proactive — you check addresses before you send, not after. Services like NeverBounce, ZeroBounce and Kickbox probe the receiving server with anRCPT TO check (without actually delivering), flagging addresses that would bounce.

Recommended cadence:

• Before the first send to any imported list. Always. No exceptions for "clean" CSVs.
• Every 6 months for warm lists. Email addresses decay at about 22% per year — people change jobs, mailboxes get disabled.
• After any bounce spike, even if you've cleaned the list recently. A spike usually means a batch of stale records slipped in.

Frequently asked questions