Hard Bounce vs. Soft Bounce: What Should Your Sending Platform Do?

Most cold email platforms show you one number: bounce rate. Behind that number are at least four very different events, and the right response to each one is different. Treat them all the same and you'll either burn good leads by suppressing them permanently, or keep hammering a mailbox that a receiving provider has already decided to block.

The distinction between a hard bounce and a soft bounce is the starting point, not the whole story. Here's what each actually means at the SMTP level, where the classification breaks down, and what a sending platform should do automatically in each case.

Hard bounce: the address is permanently undeliverable

A hard bounce is a permanent failure — a 5xx SMTP response that says the recipient does not exist, the domain does not resolve, or the mailbox has been deleted. The receiving server is telling you this will never work, don't try again.

Typical responses:

* 550 5.1.1 User unknown / Recipient address rejected: User unknown in virtual mailbox table * 550 5.1.10 RESOLVER.ADR.RecipientNotFound (Microsoft 365) * 553 5.1.2 Domain not found / invalid domain * 550 5.4.1 Recipient address rejected: Access denied (Microsoft — usually a nonexistent user in that tenant)

The correct platform behaviour: stop immediately, do not retry, remove the lead from every active and future sequence, and add the address to the workspace suppression list so another campaign doesn't rediscover the same dead address next quarter. If the failure is domain-level (NXDOMAIN, no MX), the platform should flag every other lead sharing that domain in your list, because they're all going to fail too.

Hard bounces are the number mailbox providers actually judge you on. They're the signal of a scraped, stale, or unverified list. This is the figure that needs to stay under about 2–3%, and why verifying every lead before you send is not optional.

Soft bounce: temporary, retryable, and mostly noise

A soft bounce is a 4xx response — a temporary failure. The address is fine; the server just can't accept the message right now.

Common causes:

• Greylisting. The receiving server deliberately rejects the first attempt from an unknown sender with a 450 or 451, expecting a legitimate sender to retry. Retrying after 5–15 minutes usually works.
• Mailbox full. 452 4.2.2. Retryable, but if it persists over a week the address is often abandoned.
• Rate limiting / throttling. 421 4.7.0, 421 4.3.2, or Google's "4.7.28 Our system has detected an unusual rate of unsolicited mail". This one is temporary in form but reputational in substance.
• Transient server issues. 451 4.3.0, connection timeouts, DNS hiccups on their side.

Correct platform behaviour: retry on a backoff schedule — something like 15 minutes, 1 hour, 4 hours, 24 hours — for up to 48–72 hours, then mark it as undeliverable-for-now and move on without permanently suppressing the lead. A soft bounce should not count toward the headline bounce rate you compare against safety thresholds, because it says nothing about list quality.

One critical exception: if soft bounces from a single provider spike — say 4.7.28 from Gmail across a dozen leads in an hour — that is not a list problem, it's a sender problem. The platform should treat that as a reputation event, not a retry queue.

The third category: 5xx responses that aren't about the recipient

This is where most tools get it wrong. A permanent 5xx can mean "this person doesn't exist" or it can mean "we know who you are and we don't want your mail." Same response class, opposite meanings, opposite remedies.

Examples of policy or reputation rejections:

• 550 5.7.1 Service unavailable, Client host [IP] blocked using Spamhaus
• 554 5.7.1 Message rejected due to content restrictions
• 550 5.7.1 Unauthenticated email from yourdomain.com is not accepted due to domain's DMARC policy
• 550 5.7.509 Access denied, sending domain does not pass DMARC verification (Microsoft)
• 571 5.7.1 Message refused — recipient's provider rejected it (generic Microsoft OU-prefixed codes)

If your platform files these as hard bounces, two bad things happen at once. Your bounce rate inflates and you panic about list quality that was never the issue. And perfectly valid leads get permanently suppressed because a receiving server was blocking your IP or your authentication was broken that day.

What should happen instead: classify these as block events, keep the lead eligible, and act on the sending side — pause the affected mailbox, check SPF, DKIM, and DMARC alignment, check whether the sending IP is listed, and don't resume until the cause is fixed.

Classification table

What good bounce handling looks like in practice

If you're evaluating a sending platform, these are the behaviours worth checking before you commit a domain to it.

• It stores the raw SMTP response. Not "bounced" — the full string, visible on the lead record. Without it you cannot diagnose anything.
• It separates hard, soft, and block events in reporting. A single blended bounce percentage is close to useless for decision-making.
• It retries soft bounces on a backoff, not instantly. Immediate retries against a greylisting server look like a misconfigured bot.
• It suppresses hard bounces at the workspace level, not just the campaign level, so the same dead address doesn't resurface in next month's list.
• It pauses on thresholds, not after the damage. If a mailbox crosses, say, 5% hard bounces in a campaign, sending should stop automatically and ask you to intervene — not keep dialling.
• It applies thresholds per provider. A 6% hard bounce rate concentrated entirely in one receiving domain is a different problem from 6% spread evenly.
• It doesn't count out-of-office replies as bounces — or as replies. Auto-responders are neither. If your tool counts them as positive engagement, every reply metric you have is inflated.

On thresholds: hard bounces above 3% on a campaign warrant stopping and re-verifying the list; above 5% you're actively damaging the sending domain. We go deeper on where the lines sit in what bounce rate is too high for cold email.

The catch-all problem

Roughly a fifth of B2B domains are configured as catch-all: the server accepts mail for any address at that domain, then silently discards anything that doesn't match a real mailbox. You get a clean 250 OK and a bounce rate that looks great while the message goes nowhere.

No bounce classification can fix this. The only honest handling is to tag catch-all domains at import, cap how many you include in a campaign, and judge them on reply rate rather than delivery rate. A platform that reports catch-all sends as "delivered" without qualification is flattering you.

How Sendvanta handles it

Sendvanta classifies every failure by SMTP response rather than lumping them into one bounce bucket. Hard bounces are suppressed workspace-wide and never re-enter a sequence. Soft bounces retry on a backoff and don't inflate your headline bounce rate. Policy and reputation rejections are treated as a sending-side signal: they feed the layered health score across mailbox, domain, DKIM, and IP, and when risk thresholds are crossed the affected mailbox slows down or pauses automatically rather than continuing to collect blocks. The raw SMTP string stays on the lead record so you can see exactly what the receiving server said.

Because Sendvanta sends through your own Gmail, Microsoft 365, or SMTP mailboxes and never proxies through shared IPs, a block event points at your infrastructure — which means fixing it actually fixes the problem. You can test the whole setup on the free plan ($0, no card, 1,000 active leads, 3,000 emails/month, up to 10 of your own SMTP mailboxes), or see the full breakdown on the features page.

Methodology: classifications and SMTP response examples in this post reflect current Google Workspace, Microsoft 365, and common MTA behaviour as observed in February 2026; specific response strings vary by receiving server and change over time, so always read the raw text rather than the label your tool assigns.