Hard vs soft bounces: the difference, causes, and how to handle each
When an email fails to deliver, your sending platform files the failure into one of two buckets: hard bounce or soft bounce. The label is not cosmetic. It determines whether you should ever send to that address again, how much reputation damage the failure did, and what your next action should be. Getting the two confused is one of the fastest ways to quietly wreck your deliverability — so this article draws the line clearly, with the SMTP codes and handling rules behind each.
The core difference in one sentence
That distinction maps directly onto the SMTP reply codes the receiving server returns. Codes in the 5xx range are permanent rejections (hard). Codes in the 4xx range are temporary rejections (soft). The three-digit code, and the enhanced status code that follows it, tell you exactly which failure you hit.
What causes a hard bounce
Hard bounces come from the address or domain being fundamentally undeliverable. The most common causes:
- The mailbox does not exist. Server returns
550 5.1.1 No such user here. This is the biggest single source of hard bounces on aged lists — the person left, the mailbox was deleted, or the address was mistyped at capture. - The domain has no mail server. No MX record means the domain cannot receive mail at all. Every send to it is a guaranteed hard bounce.
- The domain does not exist. Typos like
@gmial.comor a company that shut down. DNS resolution fails and the message is returned immediately. - The recipient's server blocked you.
550 5.7.1— your IP or domain is on a blocklist, or your authentication failed hard. Technically the mailbox may exist, but you specifically are refused.
The rule for hard bounces is absolute: remove the address immediately and never send to it again. Every reputable ESP will automatically suppress a hard-bounced address, and continuing to mail known-dead addresses is exactly the pattern that gets a sending domain flagged.
What causes a soft bounce
Soft bounces come from conditions that are temporary or specific to that moment. The address itself is usually fine. Common causes:
- Mailbox full.
452 4.2.2 Mailbox full. The user exists but their storage quota is exceeded. Often clears on its own. - Server temporarily unavailable.
421 4.3.2 Service not available. The receiving server is down, overloaded, or in maintenance. - Greylisting.
451 4.7.1 Greylisted, try again later. A deliberate anti-spam tactic: the server rejects the first attempt from an unknown sender and expects a retry. Legitimate mail servers retry automatically; the message usually delivers on the second attempt. - Message too large.
552 5.3.4or a4xxsize rejection when your message exceeds the recipient's limit. - Rate limiting / throttling.
421 4.7.0 Too many messages. You are sending faster than the receiver will accept; slow down and the mail flows.
Soft bounces should be retried automatically by your sending platform on a back-off schedule. The important nuance: a soft bounce that repeats across many consecutive sends should be treated as a hard bounce. If an address soft-bounces on, say, five straight campaigns, the mailbox is effectively dead (abandoned and permanently full, for instance) — suppress it.
Hard vs soft at a glance
| Hard bounce | Soft bounce | |
|---|---|---|
| SMTP code range | 5xx (permanent) | 4xx (temporary) |
| Typical cause | Address/domain doesn't exist, blocked | Full mailbox, server down, greylisting, throttling |
| Will it ever deliver? | No | Possibly, on retry |
| Correct action | Suppress immediately, never resend | Retry with back-off; suppress after repeated failures |
| Reputation impact | High — signals a poorly maintained list | Low per event, but persistent softs add up |
| Preventable by verification? | Mostly yes | Partially |
Why hard bounces hurt more
Mailbox providers use bounce patterns as a proxy for how well you know your audience. A sender who repeatedly mails non-existent addresses looks like someone who bought a list or scraped the web — the exact profile of a spammer. Hard bounces above roughly 2% invite throttling, and above 5% you risk being flagged. Soft bounces are far more forgiving because they are expected background noise; every legitimate sender gets some. The danger with soft bounces is only when you ignore the ones that never recover.
How to handle each correctly
Hard bounces
- Ensure your ESP's automatic suppression is enabled (it almost always is by default — do not disable it).
- Do not re-import hard-bounced addresses from an old export. This is the most common way dead addresses sneak back into a list.
- Investigate a sudden spike. A jump in hard bounces usually means the list source was bad — a purchased list, a stale segment, or a broken signup form.
Soft bounces
- Let your platform retry on its back-off schedule; do not manually resend.
- Set a threshold: after N consecutive soft bounces (many teams use 3–5), convert the address to suppressed.
- If soft bounces spike across a whole campaign — not specific addresses — the cause is usually on your side: an authentication problem or a reputation dip. Check your SPF and DMARC alignment and whether your IP has landed on a blacklist.
Prevention beats handling
The cheapest bounce is the one that never happens. Verifying addresses before you send catches the entire category of hard bounces caused by non-existent mailboxes and dead domains — because that is exactly what a verifier checks. A live SMTP RCPT probe asks the receiving server whether the mailbox exists, an MX lookup confirms the domain can receive mail at all, and syntax parsing kills the typos. Everything that would have returned a 550 at send time gets removed while it is still just a row in your list. For the mechanics of how that probe works without delivering a message, see how SMTP RCPT validation works.
Verification cannot prevent soft bounces — a mailbox that is full today looks valid today — but it removes the guaranteed hard bounces that do the real reputation damage. That is the highest-leverage prevention step available before a send.
Catch the hard bounces before you send
Mailcheq runs syntax, MX, disposable, role-account, and a live SMTP probe in under 500ms — free in your browser.
Verify an address →The bottom line
Hard bounces are permanent and dangerous — suppress them on the first failure and never look back. Soft bounces are temporary and mostly harmless — retry them, but convert persistent ones to suppressed. Read the SMTP code range (5xx vs 4xx) to tell which is which. And since most hard bounces come from addresses that never existed, verifying your list up front is the one action that removes the whole problem before the providers ever see it. If your bounce rate is creeping up, our guide to a healthy bounce rate covers the numbers to aim for.
Spotted an error in this article? Email hello@mailcheq.com and we will fix it.