Bounces vs blocks vs deferrals: what your ESP's error codes actually mean

Every time you hit send, your mail server (the machine your ESP — your email service provider, the platform that does the actual sending — runs to push email out) hands the message to the recipient's mail server. The recipient server reads it, decides whether to take it, and sends back a three-digit status code. That code is the entire signal. Everything your dashboard tells you about deliverability is downstream of those three digits.

The first digit is the only one that matters at first glance.

2xx — success. Mail accepted. Moves on.

4xx — transient failure (a deferral — "try again later"). Recipient server couldn't accept the mail right now but might later. Your server retries automatically, usually for 24–72 hours. No action needed from you.

5xx — permanent failure (a bounce or block). Rejected, don't retry. The subtypes matter: 5.1.x is usually "bad address" (a hard bounce). 5.7.x is usually "policy or reputation" (a block). Same digit family, completely different remediation.

ESPs bucket these into human-readable categories on the dashboard, and the terminology drifts a bit between platforms. The SMTP codes themselves — SMTP being the protocol mail servers use to talk to each other — are standard. If your dashboard shows "bounces" as one number, go dig for the subtype. The fix depends on which one is moving.

A hard bounce means the address itself is the problem. The mailbox doesn't exist, never existed, got disabled, or the domain doesn't resolve. On the wire it shows up as 550 "No such user," 550 "Recipient address rejected: User unknown," 553 "Bad destination mailbox," or one of the various domain-not-found variants. The recipient server is telling you, plainly, there is nothing here.

What to do: suppress permanently — add the address to your never-send list. See rule 1 of the list hygiene policy. One hard bounce means the address is dead; sending again produces another bounce and another hit to your sender reputation (the score mailbox providers keep on whether they trust you). ISPs read a high hard bounce rate as bad list hygiene, which is the same signal spammers produce. The correlation isn't accidental — it's exactly why the metric exists.

The classic spike pattern: a marketing push to an older list, hard bounce rate doubles overnight, panic ensues. The cause is decay. Users delete accounts, change ISPs, leave jobs, abandon Yahoo addresses. A long-unused list surfaces all that decay at once the moment you send to it. The fix is structural, not reactive — segment by last engagement, only send to users active in the last 12 months, sunset or remove anyone older and unengaged. Hygiene is a posture, not a one-off purge.

A soft bounce is a temporary delivery failure. Mailbox full. Recipient server having a bad afternoon. Temporary authentication wobble. Message too large. On the wire it's typically a 4xx deferral that eventually times out, or a specific 5xx like 552 "Requested mail action aborted: exceeded storage allocation." The address works in principle; just not right now.

What to do: retry on next send. Most soft bounces resolve within a send or two as mailboxes clear or servers recover. A single soft bounce is noise. A persistent soft bounce is signal. Rule 2 of the hygiene policy flags three consecutive soft bounces for suppression, because three in a row usually means the mailbox is abandoned and the user is never coming back to clear it.

The bit that confuses people: telling a soft bounce apart from a deferral. They're the same family, slightly different outcome. A deferral is a 4xx response where the retry eventually succeeds — the mail gets through, just late. A soft bounce is the same 4xx where the retries age out and never succeed. Most ESPs distinguish "deferred then delivered" from "deferred then bounced" in reporting. Check yours, because they need different interventions and your dashboard may be hiding the split under a single label.

A block is the one that should ruin your week. The recipient server rejected the mail not because the address is bad, but because of something about you. Bad IP reputation. Content flagged as spam. Authentication failure. Inclusion on the SBL — the Spamhaus Block List, the most-used industry blocklist. On the wire it looks like 550 5.7.1 with various messages: "Rejected due to spam content," "Sender reputation not acceptable," or 554 "Transaction failed" with a specific cause attached.

What to do: investigate urgently. A small number of blocks from one ISP may be transient — a single mailbox provider having a moment. Blocks from multiple major ISPs, or block volume that's climbing day over day, is a reputation or authentication problem. Those don't fix themselves and the longer you keep sending, the deeper the hole.

The full emergency protocol when block rate spikes: stop broadcast sends, limit to users who engaged in the last 30 days, then check Postmaster Tools — the free dashboards Gmail, Yahoo and Microsoft offer senders so you can see your reputation as they see it. After that, check authentication records (SPF, DKIM, DMARC — the three DNS-based standards that prove a message genuinely came from your domain). Then check IP blocklists via MXToolbox or Cisco Talos, and review recent campaigns for spam triggers in subject lines and body copy. Fix the root cause, then resume volume gradually. Recovery of 2–6 weeks is typical, longer if complaint rate is still climbing when you start.

A deferral is a 4xx response asking your server to please retry later. Causes are rarely interesting: temporary server overload at the recipient end, rate limiting, or greylisting (an anti-spam measure where the recipient asks unknown senders to retry before it accepts the message — real senders retry, most spam senders don't bother).

What to do: nothing. Your SMTP retries automatically — typically every 15 minutes for the first hour, exponentially longer after that. Most mail gets through within a few hours. No manual intervention required.

The exception worth flagging: if deferral rate spikes to 20%+ and stays there, you've probably hit an ISP rate limit — your volume into a specific mailbox provider exceeded what they'll accept per hour. Your ESP's delivery team can help investigate and shape the send. Past that one scenario, deferrals usually don't deserve dashboard real estate.

Four numbers, four meanings, four different fixes.

Hard bounce rate: under 2%. Above 5% on broadcasts is a list hygiene problem. Driven by list quality — acquisition source, list age, dormant inclusion.

Soft bounce rate: 2–5% typical on broadcasts. A sustained climb often indicates dormant users whose mailboxes are full or neglected.

Block rate: under 0.5%. Above 1% is a deliverability emergency. Driven by reputation, authentication, content.

Deferral rate: usually not dashboard-worthy. Monitor only when sustained above 20%.

Healthy aggregate bounce rate is under 5% for broadcast programs, under 2% for engaged-user-only sends. Most ESP dashboards roll all four into one "bounce rate" figure. That number is misleading on its own — different root causes, different interventions, no shortcut. Drill in when you're troubleshooting; trust the rolled-up number only when nothing's on fire.

When bounces rise, the diagnostic is short and has a fixed order. Following it in order is the difference between a 30-minute fix and a three-week investigation.

1. Check which type is rising — hard, soft, block, deferral.

2. Hard → list hygiene. Audit recent acquisition, dormant users, import processes.

3. Soft → engagement or infrastructure. Are dormant users over-represented? Is a specific ISP having issues?

4. Block → reputation or authentication. Check Postmaster Tools, IP and domain reputation, SPF/DKIM/DMARC, content for spam triggers, IP blocklists.

5. Deferral → usually transient. Monitor.

Acting on "bounce rate" as one number mixes these signals together, and a mixed signal produces a guess instead of a fix. Acting on the correct subtype produces faster, more accurate remediation. Most incident retrospectives I've sat through trace the lost time back to this step being skipped — someone reacted to the headline number, threw the wrong fix at it, and burned a week before going back to first principles.

The Deliverability Management skillcovers the incident-response playbook for each bounce type — treating each with specific remediation rather than generic "improve deliverability" advice.