What is Hard bounce vs soft bounce?

What a hard bounce is

A hard bounce is a permanent delivery failure: the receiving server is telling you this address will never accept your mail, so don't try again. Hard bounces are the ones that damage reputation, and the addresses behind them should be removed from active sending immediately.

• The mailbox doesn't exist — a typo, a former employee, or a made-up address.
• The domain doesn't exist or has no mail servers (no MX records).
• The mailbox has been closed or permanently disabled.
• The receiving server has blocked your domain or IP outright.

What a soft bounce is

A soft bounce is a temporary failure: the address is real, but the message couldn't be delivered right now. Mail systems treat soft bounces as retryable and will usually attempt redelivery over a period of hours or days before giving up.

• The mailbox is full and temporarily can't accept new mail.
• The receiving server is down, overloaded or rate-limiting you.
• The message is too large for the recipient's limits.
• The send was temporarily deferred (greylisted) as an anti-spam measure.

Why hard bounces are so dangerous

Hard bounces are a direct, fast-acting signal of poor list hygiene. Because a hard bounce can only happen when you mail an address that was never reachable, a cluster of them tells mailbox providers you're sending to a list you haven't verified. Even a low single-digit hard-bounce percentage is enough to drag down the sender reputation attached to your domain and IP.

The knock-on effect is what makes them costly: once reputation drops, your deliverability falls for everyone on the list, including your most engaged subscribers. A single careless send to an old, unverified list can undo months of carefully built reputation, which is why hard-bounced addresses should be suppressed the moment they're identified.

How to handle each type

The two bounce types call for opposite reflexes. Hard bounces should be removed (suppressed) immediately and permanently — never mail them again. Soft bounces should be monitored: let your email platform retry, and only treat an address as dead once it has soft-bounced repeatedly across several sends, at which point it behaves like a hard bounce and should be suppressed too.

Suppression is better than deletion. Keep hard-bounced addresses on a do-not-send list rather than simply deleting the record, so the same bad address can't be re-imported from another source and quietly re-enter your sending.

• Hard bounce → suppress immediately; never retry.
• Soft bounce → allow automatic retries; investigate if it persists.
• Repeated soft bounces (e.g. across 3+ sends) → treat as hard and suppress.
• Always suppress rather than delete, to stop bad addresses creeping back in.

Preventing bounces before they happen

The cheapest bounce is the one that never occurs. Verifying a list before you send removes the non-existent mailboxes and dead domains that cause hard bounces, so they're gone before they can register against your reputation. Verification can't prevent every soft bounce — a full mailbox or a momentary server outage is outside your control — but it eliminates the permanent failures that actually do the damage.

Pairing pre-send verification with disciplined suppression of the bounces you do receive keeps your bounce rate in the safe zone (generally at or under about 2%) and your sender reputation intact over the long run.

How to read a bounce code

Every bounce carries a status code that tells you why it failed, and learning to read them turns a vague "it bounced" into a clear action. Mail servers use three-digit SMTP reply codes, often with a more precise enhanced status code attached. The leading digit is the quickest tell of whether you're looking at a hard or soft failure.

• 5.x.x codes (e.g. 550 "no such user") are permanent failures — hard bounces. Suppress the address.
• 4.x.x codes (e.g. 452 "mailbox full", 421 "service unavailable") are temporary — soft bounces. Allow retries.
• 5.1.1 specifically means the mailbox doesn't exist — a textbook hard bounce.
• Block-style 5xx messages mentioning reputation or spam mean the receiver is refusing you, which is a reputation problem to fix, not just an address to drop.

Automating bounce handling in your platform

Reading codes by hand doesn't scale, so the goal is to let your email platform act on them automatically. Most email service providers parse bounce codes for you and maintain a suppression list, automatically removing hard-bounced addresses from future sends. The important thing is to make sure that automation is switched on and that suppression is shared across your tools — a hard bounce caught by your ESP should also be reflected in your CRM, or the same address gets re-imported and re-sent.

Where automation still needs a human decision is the boundary cases: how many consecutive soft bounces should trigger suppression (commonly three to five across separate sends), and what to do with addresses that bounce for reputation reasons rather than non-existence. Setting those rules once, and feeding verification in ahead of the send so fewer bounces happen at all, turns bounce handling from a reactive cleanup into a quiet, automatic safeguard.

What bounce rate is acceptable, and how to calculate it

Bounce rate is simply the share of your sent messages that bounced: divide the number of bounces by the number of emails sent, then multiply by 100. If you sent 10,000 emails and 200 bounced, that's a 2% bounce rate. It's worth tracking hard and soft bounces separately, because the hard-bounce figure is the one that maps most directly to list quality and reputation risk.

As a rule of thumb, most healthy senders keep their total bounce rate at or under about 2%, and their hard-bounce rate well below that. Climb past a few percent and mailbox providers start to read it as a sign you're not maintaining your list, which invites throttling and spam-foldering. Cold outreach to unverified or purchased lists routinely blows past these thresholds — sometimes 20–30% — which is enough to do real, lasting reputation damage in a single send.

The practical implication is that bounce rate is a lagging indicator you can control in advance. By verifying a list before you send, you remove the addresses that would have bounced, so the rate you report stays in the safe zone by design rather than by luck.

Bounces vs blocks vs deferrals

Not every failed delivery is a bounce in the list-hygiene sense, and conflating them leads to the wrong fix. A true bounce relates to the address or mailbox: it doesn't exist (hard) or it's temporarily unavailable (soft). A block is different — the receiving server is refusing your mail because of who you are, citing reputation, a blocklist, or content, even though the address itself may be perfectly valid.

A deferral (greylisting) is different again: the server is asking you to try again shortly as an anti-spam tactic, and legitimate mail is usually accepted on the retry. Reading these apart matters because the remedy differs. A surge of hard bounces means clean your list; a surge of blocks means investigate your reputation, authentication or content; a wave of deferrals usually resolves itself on retry. Verification fixes the first category at the source, which also indirectly helps the second by keeping the bounce-driven reputation damage that triggers blocks from happening in the first place.