Hard bounce vs soft bounce: what actually failed?

What a bounce actually is

Email delivery is a live conversation between two servers over SMTP. Your server announces the sender and the recipient; the receiving server answers each step with a numeric code. A bounce is the receiving server saying no - either permanently (codes starting with 5) or temporarily (codes starting with 4) - and the text after the code usually says why. That text, the rejection string, is the single most under-read piece of data in outbound. Almost every bounce mystery dissolves once someone actually reads it.

The two families, side by side

Greylisting deserves a sentence of its own because it worries people unnecessarily: some receiving servers temporarily refuse the first delivery attempt from an unfamiliar sender on purpose, expecting a legitimate server to retry. Your sequencer's retry handles it; a one-off 450 is not a signal of anything.

The third category: policy blocks dressed as hard bounces

A meaningful share of what gets counted as hard bounces in cold email is not bad data at all. Corporate security gateways such as Mimecast and Proofpoint return a hard 5xx rejection to senders they do not recognise, and in most sequencer reporting that lands in the same bucket as an invalid address. The address is real; the recipient's infrastructure refused you on policy. This is exactly why verified lists still bounce: verification confirms the mailbox exists, and existence was never the question.

The distinction changes what you fix. A genuine invalid-address bounce means your list process needs work. A gateway rejection means your sending posture - domain age, authentication, volume, provider mix - needs work, and no amount of list cleaning will move it. You can see which environment answers for any recipient domain with our mail provider lookup. Some hard bounces come from domains that cannot receive mail by any route - 8.28 percent of the 9,847,723 domains measured in our B2B email infrastructure index.

Bounce rates by recipient email provider, from 327,273 contacted leads

The policy-block argument above predicts that gateway-protected recipients bounce more often, so we checked that prediction on our own campaign book: 327,273 contacted leads across 97 campaigns created between April and September 2026, each classified by the mail environment of the recipient domain (its MX host, security gateways first). The bounce rate differs little between the big two mailbox platforms and a great deal by what sits in front of them. Google Workspace recipients bounced 1.47% of the time and Microsoft 365 recipients 1.65%; inside the same campaigns the difference is not statistically significant (0.96x, 95% CI 0.90-1.03). Recipients behind a security gateway bounced 5.24% overall and 3.51x as often as unprotected Microsoft 365 or Google Workspace recipients in the same campaigns (95% CI 3.27-3.78, 92 campaigns).

Gateways are not interchangeable. Mimecast-protected recipients bounced 15.26% of the time (3,610 contacted), Sophos 10.47% and Barracuda 8.58%, while Proofpoint-protected recipients bounced 1.93% - close to the unprotected tenants. Domains with no MX record at all bounced 28.17% of the time (a small group: 284 contacted leads, interval 23.26%-33.67%): delivery depends on RFC 5321's fallback to the domain's address record (an A or AAAA record, the implicit MX), and more than one in four of these recipients bounced. These gaps line up with the receiving environment, not only with list quality; the platform flag cannot say which bounces were policy blocks and which were bad addresses.

Two limits matter when you read this. The sending platform's bounce flag does not separate hard from soft bounces, so the gateway gap is consistent with the policy rejections described above but does not prove which share were policy blocks. And these rates are per contacted lead in one operator's campaigns, not a market average; the book-wide per-send figure is 1.32% (5,679 of 429,763 sends), with a median campaign bounce rate of 1.33% on the benchmarks page. On one campaign, the bounce rate was 3.34% before gateway-protected recipients were moved into their own send and 1.19% on sends made after the split (an observed change, not a controlled test), as documented on why verified lists still bounce.

Paste the bounce, get the verdict

Paste the rejection text from any bounce notification - the SMTP line or the whole non-delivery report - and this classifies it into the categories above: hard invalid-address, hard policy or reputation block, soft temporary, greylisting or mailbox-full, and names the security gateway where one identifies itself in the string. The parsing runs in your browser; nothing you paste is sent anywhere.

Need the provider's own wording for a code? The classifier gives a hard, soft or policy verdict; SMTP error codes lists every response Google and Microsoft document for Gmail and Microsoft 365, with what each means for a cold email.

Why bounce rate is the metric that compounds

Bounces are not just lost sends; they are evidence about you, logged by the receiving side. Providers read a sender that keeps hitting invalid addresses as a sender that bought a list, and they adjust placement for everything that sender does next. That is why we hold a working ceiling of 2% and treat sustained rates above 5% as an emergency, and why bounce rate should be watched on the sends made since your last change, not on cumulative averages that bury recent behaviour under old data. Where bounce rate sits among the numbers that actually predict revenue is covered in cold email metrics.

What to do about each kind

• Hard bounce, invalid address. Suppress it everywhere, feed the failure back into your list source, and check whether that source's failure rate justifies keeping it.
• Hard bounce, policy string. Do not delete the lead - the address works. Fix the sending side: full authentication, warmed mailboxes, conservative per-mailbox volume, and segment gateway-protected recipients so their behaviour does not distort the rest of the campaign's numbers.
• Soft bounce. Let the retry window run. If the same recipient soft-bounces across the whole window, treat it as hard. If many recipients on one receiving domain soft-bounce at once, the domain is throttling you - reduce volume to it rather than pushing.
• Any bounce spike after a change. Whatever you changed is the prime suspect: a new list segment, a new domain, a volume increase. Diagnose before sending more; capacity spent while bouncing is reputation spent for nothing.

Prevention beats triage

Three habits keep bounce rate under the ceiling before triage is ever needed: verify the list live immediately before sending rather than when it was purchased; treat catch-all domains as their own risk class, because verification cannot confirm those mailboxes; and check your own technical setup with the deliverability checker, because a broken SPF record turns even a clean list into a bounce problem.

When this page does not apply

• You send opted-in marketing email from an email service provider. This page is written for B2B cold email; newsletter platforms apply their own automatic suppression rules, so follow your provider's bounce documentation first.
• You need the hard vs soft split of the provider figures. The provider bounce rates count every contacted lead the sending platform marked as bounced; the platform counts hard and soft bounces together (see why verified lists still bounce), so use the classifier above on the actual rejection strings.
• You want a market-wide bounce benchmark. The figures describe one operator's campaigns (97 campaigns, April-September 2026), measured per contacted lead: pooled, 6,486 of 327,273 contacted leads bounced (1.98%), against 1.32% per send in the separate 115-campaign book; neither is an industry average.
• You are reading this months from now. The dataset was extracted on 23 September 2026; the current version, its CSV and its method are on the provider dataset page.

How this page was built and checked

The definitions follow the SMTP reply-code classes in RFC 5321 and the enhanced status codes in RFC 3463; the operating thresholds (a 2% working ceiling, above 5% as an emergency) are ReplyLead's own practice, not a provider rule. The bounce figures come from ReplyLead's campaign book: 327,273 contacted leads (one lead in one campaign that was sent at least one email) across 97 campaigns created 1 April to 21 September 2026, extracted 23 September 2026; the recipient environment is the owner of the recipient domain's MX host, with security gateways classified first; intervals are Wilson 95%; within-campaign ratios are Mantel-Haenszel risk ratios across campaigns. The 1.32% book-wide rate is per send from a separate extraction (429,763 sends, campaigns created 1 April to 10 August 2026), so it is not directly comparable with the per-lead provider rates. We did not test any mailbox provider's filters directly. Last checked 24 September 2026.

Sources and check dates

ReplyLead's own data behind every figure on this page (archived with DOI 10.5281/zenodo.22920956):

1. Cold email reply rates by email provider (open dataset, CSV + JSON, CC BY 4.0): every provider bounce rate, interval and within-campaign ratio on this page.
2. Cold email benchmarks 2026: the 1.32% book-wide bounce rate (5,679 of 429,763 sends) and the 1.33% median campaign rate.
3. Why verified lists still bounce: the 3.34% to 1.19% gateway-split example.
4. B2B Email Infrastructure Index 2026 Q3: the 8.28% of 9,847,723 domains that cannot receive mail.

Outside primary sources for the definitions and codes, each read on the date shown:

1. RFC 5321, Simple Mail Transfer Protocol (IETF): reply codes: 4yz transient negative completion, 5yz permanent negative completion; with no MX, the domain's address (A or AAAA) record is treated as an implicit MX. checked 24 September 2026.
2. RFC 3463, Enhanced Mail System Status Codes (IETF): the X.1.1 'bad destination mailbox address' detail behind 550 5.1.1 and the persistent transient (4.X.X) vs permanent (5.X.X) failure classes. checked 24 September 2026.
3. RFC 3464, An Extensible Message Format for Delivery Status Notifications (IETF): the non-delivery report format whose text the classifier reads. checked 24 September 2026.
4. RFC 6647, Email Greylisting: An Applicability Statement for SMTP (IETF): greylisting as a deliberate temporary refusal that a legitimate server retries. checked 24 September 2026.
5. Microsoft Learn: Email nondelivery reports (NDRs) and SMTP errors in Exchange Online: how Microsoft 365 reports rejections, including 5.1.1 and policy codes. checked 24 September 2026.
6. Google Workspace: Gmail SMTP errors and codes: the 4xx and 5xx codes Gmail and Google Workspace return, with their enhanced codes. checked 24 September 2026.