Bounce rate. A 4% hard bounce rate kills your sending domain in about two weeks.

01What bounce rate is

A bounce is an email that fails to deliver. The recipient's mail server rejects it for some reason and returns a non-delivery notification (an NDR, or bounceback) to the sender. Bounce rate is just the percentage: bounces divided by total sends.

The reason bounce rate matters so much isn't the bounces themselves — those are just unsent emails. It's what bounces signal to ISPs about the sender. A high bounce rate is, in ISP machine-learning terms, the single strongest indicator that the sender did not verify their list before sending. And unverified lists are, statistically, the lists used by spammers, scrapers, and low-effort cold prospectors. The ISP doesn't need to read your message content to flag you — your bounce rate alone is enough.

This is why bounce rate has outsized impact relative to its volume. A 5% bounce rate is only 50 bad emails per 1,000 sent — small in absolute terms, catastrophic in reputation terms. ISPs treat the bounce signal as nearly diagnostic: a healthy outbound program sending to verified lists has bounce rates under 2% essentially by construction; a 5%+ bounce rate almost always means the sender skipped verification.

02The four kinds of bounce

"Bounce" is an umbrella term covering four distinct failure modes. ISP reputation systems treat each one very differently. Knowing the difference is essential to interpreting your bounce report:

The critical operational distinction: hard bounces affect list quality reputation; block bounces affect sender reputation. They look similar in bounce reports but require completely different responses. Most ESPs lump them together as "bounce rate," which obscures the diagnostic. A serious outbound program tracks the four types separately and investigates spikes in each independently.

03SMTP reply codes you should know

SMTP returns a three-digit code with every delivery attempt. The first digit tells you the outcome category. Most outbound operators never look at the codes; the ones who do diagnose problems hours instead of weeks. Quick reference for the codes that matter:

Two practical uses for this reference. First, when triaging a bounce spike, sort the bounces by code and look at the dominant pattern: lots of 5.1.1 = list quality; lots of 550 5.7.1 = reputation; lots of 421 = throttling. The fix differs for each. Second, when a single ISP starts blocking you, the code their server returns usually tells you which reputation system flagged you (Spamhaus, SpamCop, Microsoft SmartScreen, etc.) — which determines where to file the delisting request.

04The thresholds that matter

Where the bounce-rate lines are. These are the bands every outbound ops team should treat as governing constraints, not aspirational targets:

Two nuances most teams miss:

The 2% line is a hard bounce threshold, not a total bounce threshold. Soft bounces matter less because they're often transient. A 4% total bounce rate with 1% hard / 3% soft is mostly fine. A 2% total bounce rate with 2% hard / 0% soft is alarming. Track them separately.

The thresholds are per-campaign, not per-quarter. A single campaign with 6% bounce rate damages reputation more than four campaigns at 1.5% averaging the same. ISPs react to per-batch behavior; the average over time is largely meaningless. The implication: never run a single high-bounce campaign "just to test," even if your overall average is fine. Each campaign is judged on its own.

05Day-by-day domain death timeline

What actually happens to a sending domain that sustains a 4% hard bounce rate, day by day. This is reconstructed from postmortems of real domain-burn incidents:

Two things to internalize from this timeline. The early signs are invisible — through day 3, nothing obvious is wrong from the operator's view; the team is debugging copy when the actual problem is data quality. By the time blocks become visible (day 5-7), the damage is mostly done. The recovery is months, not weeks — the asymmetric cost of bounces is why prevention is so disproportionately valuable. A single bad batch costs more in lost pipeline than years of verification fees combined.

06The pre-send verification stack

The three-layer verification stack that catches roughly 95% of bounces before any email leaves your sending infrastructure. Layer them; each catches a different failure mode:

The economics are decisive. A 5,000-contact list verified at $4/1,000 = $20. The same list sent without verification with ~5% hard bounce rate puts your sending domain at risk; the expected cost of a domain burn (lost pipeline + 6-12 weeks recovery) is conservatively in the $50K-200K range for any team doing serious outbound. Verification ROI is measured in domain-life-saved. The teams that skip this step are gambling with their entire outbound program for $20 savings.

What good verification actually looks like

Run verification at three moments:

• At ingestion. Whenever a new contact enters your database — from a list buy, a scrape, a webhook, a manual import — verify it. Reject anything below 90% confidence.
• At send time. Re-verify any contact you haven't emailed in 90+ days. Mailboxes go stale; employees leave; what was valid 6 months ago may not be now.
• After bounces. When a hard bounce occurs, immediately verify the rest of the same batch. Hard bounces cluster by source — one bad one means others are likely in the same upload.

07The recovery playbook

If your bounce rate spike has already happened and reputation is degrading, here's the recovery sequence:

1. Stop all sending from the affected domain immediately. Counter-intuitive but essential. Every additional send compounds the damage. Pause, don't continue at lower volume.
2. Identify the bad data source. Sort recent bounces by source/upload/list-name. Almost always one bad batch is responsible for >80% of bounces. Find it.
3. Suppress every contact from the bad source. Not just the ones that already bounced — the whole batch. The ones that haven't been sent to yet are mostly bad too; sending to them continues the bleed.
4. Verify everything you intend to keep sending to. Run your remaining list through Layer 3 SMTP verification. Suppress anything that fails or returns risky/catchall results.
5. Check blocklists. Query MXToolbox or similar for your sending domain + IP across the major blocklists (Spamhaus, SpamCop, Barracuda). File delisting requests for any matches — most are honored within 24-72 hours if you've actually fixed the problem.
6. Restart sending at 20% of prior volume. Resume slowly. Send only to your highest-engagement segment first. Build engagement signals back up before reintroducing colder prospects. 2-3 weeks at reduced volume.
7. Set a hard pre-send verification rule and enforce it. The cause was upstream; the prevention has to be upstream. Make verification a non-skippable step in your data pipeline, with a default-deny on any new source that hasn't been audited.

Most teams running this playbook recover meaningfully within 4-6 weeks. Teams that skip step 1 (continued sending at reduced volume) almost never recover — the ISPs interpret continued bad-list sends as a sender who knows about the problem and is choosing to keep doing it, which is the worst reputation signal a domain can emit.

08Common mistakes

09Related terms

Bounce rate is the leading indicator of nearly every other deliverability problem. To go deeper: