Hard Bounce vs Soft Bounce: How to Handle Each Correctly

Every email you send can end three ways: it gets delivered, it gets deferred and tried again, or it fails outright. The two ways it fails are the hard bounce and the soft bounce, and knowing how to handle hard bounces vs soft bounces is the difference between a clean sender reputation and a slow slide into the spam folder. Handle them backwards — retrying a dead address or deleting a temporarily-unreachable one — and you either burn reputation or lose real recipients.

The short answer is not complicated, and this guide leads with it. Suppress hard bounces on the very first failure, because the address is permanently bad and retrying it only signals carelessness to the receiving server. Retry soft bounces on a widening schedule, because the problem is temporary and usually clears on its own — and only suppress them after a run of failures.

The part most articles miss is the third rule: when many addresses at one domain soft-bounce at once, that is rarely a hundred dead mailboxes. It is the receiving server throttling you, which is a reputation signal, not a list-hygiene problem. This post gives you the concrete retry and suppression rules for each, grounded in the SMTP standards that define the two categories in the first place.

The short version: suppress hard, retry soft, watch the domain#

If you only take three rules from this page, take these. They are the whole handling policy in miniature, and the rest of the post is the reasoning and the exact thresholds behind them.

• Hard bounce (5xx): suppress the address immediately and permanently. It is invalid, and the SMTP standard says a permanent failure must not be retried. Retrying it hurts you.
• Soft bounce (4xx): let your sending system retry it on a decaying schedule. The condition — a full mailbox, a server hiccup, a rate limit — usually clears. Suppress only after it keeps failing for several days.
• A cluster of soft bounces from one domain: stop treating it as a mailbox problem. When many addresses at the same provider defer at once, the receiver is throttling your mail, and the fix is your reputation and authentication, not your list.

Hard bounce vs soft bounce at a glance#

Both are non-delivery reports, and both arrive as a message telling you your email did not reach someone. The difference is whether the failure is permanent or temporary — and that single fact decides everything about how you respond.

What actually makes a bounce hard or soft?#

The two categories are not a marketing convention. They come straight from the SMTP standard, and the receiving server tells you which one you got through its reply code. Getting the handling right starts with reading that code correctly.

RFC 5321, the SMTP standard, splits reply codes by their first digit. A code that starts with 4 is a Transient Negative Completion: the action did not happen, but "the error condition is temporary, and the same command may be retried later." A code that starts with 5 is a Permanent Negative Completion: the action did not happen and "the same command MUST NOT be retried." That is the entire hard-versus-soft distinction in one sentence — 4xx invites a retry, 5xx forbids one.

RFC 3463 adds a more detailed enhanced status code, like 5.1.1 or 4.2.2, on top of the basic reply. It defines the 5.X.X class as a permanent failure — one that is "not likely to be resolved by resending the message in the current form" — and the 4.X.X class as a persistent transient failure, where the message is valid but a temporary condition has delayed it. When you read a bounce message, the leading digit of either code is the first thing to check.

How to handle a hard bounce: suppress on the first failure#

Hard-bounce suppression best practice is refreshingly blunt: one strike and the address is out. A 5xx permanent failure means the mailbox does not exist, the domain is invalid, or the server has permanently refused the message. None of those get better with a second attempt, and the standard itself says a permanent failure must not be retried.

The reason to suppress immediately is not tidiness — it is reputation. Mailbox providers watch how you treat known-bad addresses. Continuing to send to an address that already returned a permanent failure looks like a sender who does not clean their list, which is exactly the profile of a spammer working from a purchased list. That behavior pushes down your sender reputation and, with it, your inbox placement for everyone else on the list.

1. 1

   Confirm it is a 5xx

   Check the reply code in the bounce. A leading 5 (and a 5.X.X enhanced code) is a hard bounce. A leading 4 is not — do not suppress it here.

2. 2

   Add the address to your suppression list

   Move it to a permanent do-not-send list immediately. Most email service providers do this automatically for hard bounces; confirm that yours is enabled rather than assuming it.

3. 3

   Never re-import it

   A suppression list only works if a later upload cannot resurrect the address. Suppress at the account level so a fresh CSV import does not quietly add the dead address back.

4. 4

   Investigate a spike

   A handful of hard bounces per send is normal list decay. A sudden spike usually means a bad import, a typo in a signup form, or a list you should not be mailing at all.

The whole handling decision in one flow#

Before the soft-bounce rules, here is the entire policy as a single decision. Read the code, split on the first digit, and the two paths almost handle themselves.

How to handle a soft bounce: retry, then suppress#

A soft bounce is a temporary failure, so the correct response is patience, not deletion. The address is probably fine — the mailbox was full, the server was briefly down, the receiver was greylisting new senders, or you hit a rate limit. Give the condition time to clear and try again.

In practice, your sending server does most of this for you. When a message gets a 4xx, the mail server queues it and retries on a widening interval — a short gap at first, then longer ones. Most servers keep retrying for roughly four to five days and then give up, at which point the temporary failure is finally reported back to you as a permanent one (a "delayed, then failed" bounce). Those exact intervals are configurable and vary by server, but the shape is always the same: try, back off, try again, give up.

How many soft bounces before suppressing an address?#

There is no single standard number, and any article that gives you one as gospel is guessing. What matters is that you pick a consistent threshold and apply it. A workable rule most senders can defend: suppress an address once it soft-bounces on every attempt across a defined window — commonly around three to five consecutive sends, or after it has been soft-bouncing continuously for the same four-to-five-day window your mail server uses before it gives up.

So should you remove soft bounces from your list? Not on the first one, and not the second. A single soft bounce is noise. A pattern of them from the same address, with no successful delivery in between, means that mailbox is effectively dead even though it never returned a clean 5xx — and at that point it belongs on the suppression list just like a hard bounce. The judgment call is the count and the window, not the eventual action.

One nuance decides whether your threshold works: count consecutive failures, not total ones. An address that soft-bounced once last month and delivers fine today is healthy. Reset the counter every time a message lands, and only suppress when the streak of failures with no delivery in between crosses your threshold.

When soft bounces are a reputation signal, not a mailbox problem#

Here is the rule almost no bounce guide states plainly. A soft bounce from one address is a mailbox problem. A wave of soft bounces from many addresses at the same domain, all at once, is usually not. It is that provider throttling your mail, and treating it as a list-hygiene issue sends you fixing the wrong thing.

The tell is in the timing and the wording. If a hundred Gmail addresses defer within the same hour, with 4xx replies mentioning rate limits, temporary deferral, or reputation, those mailboxes are almost certainly fine. Gmail is slowing you down because something about your sending looks risky — a volume spike, a jump in spam complaints, or broken authentication. Suppressing those addresses would delete valid recipients while ignoring the actual problem.

When you see a domain-wide soft-bounce cluster, stop cleaning the list and check your reputation instead. Confirm SPF, DKIM, and DMARC are aligned, look at your spam-complaint rate in the provider's postmaster tools, and check whether your send volume just jumped. The soft bounce is the symptom; your sender reputation is the disease.

What bounce rate is too high?#

Two numbers get confused here, so separate them. There is your bounce rate — the share of sends that fail — and there is your spam-complaint rate, which the big mailbox providers actually publish thresholds for. They are not the same measurement, and only one of them has hard published limits.

For bounce rate itself, there is no official cross-provider ceiling. The widely used industry rule of thumb is to keep hard bounces under about 2% and investigate anything above that, because a high bounce rate signals a stale or purchased list — which is a reputation risk in its own right. Treat 2% as a convention to act on, not a published law.

The numbers that are published are complaint rates, and Gmail's are the ones to know. As of August 2026, Google's sender guidelines tell bulk senders — those sending 5,000 or more messages a day to personal Gmail accounts — to keep the spam rate reported in Postmaster Tools below 0.10% and to "avoid ever reaching a spam rate of 0.30% or higher." These are complaint thresholds, not bounce thresholds, but they are the reputation numbers a high bounce rate ultimately threatens.

The third category: a block that only looks like a hard bounce#

Hard and soft is the useful split, but there is a third case that hides inside the hard-bounce category and deserves its own handling. It is the block bounce — a 5xx rejection where the address is perfectly valid, but the receiver refused your message on reputation or policy grounds.

You can usually tell a block from a true dead address by the wording of the bounce. "No such user" or "mailbox unavailable" (often 5.1.1) is a genuine hard bounce — suppress it. But "message blocked," "spam content," "policy rejection," or a code like Gmail's 550 5.7.26 or Microsoft's 550 5.7.515 means the mailbox exists and your mail was turned away. Suppressing those addresses is exactly the wrong move: you would remove real recipients and leave the actual problem — your authentication or reputation — untouched.

Who these rules are for — and where AI Emaily fits#

Bounce handling is a sender's job, and specifically the job of whatever platform sends your mail at volume. If you run campaigns or sequences, your email service provider — Mailchimp, Brevo, Amazon SES, Postmark, SendGrid and the like — is where hard-bounce suppression and soft-bounce retries actually happen. Most of them auto-suppress hard bounces and manage the retry schedule for you; your job is to confirm those settings are on and to watch your rates in a postmaster tool. Groups like M3AAWG publish the sender best-practice documents these platforms build on.

We build AI Emaily, and here is the honest placement: it is not that tool. AI Emaily is an AI email client, not an email service provider — it does not send bulk mail, it does not keep a suppression list, and it does not run retry logic for a campaign. On the sending side of everything above, your ESP is the answer, and we will not pretend otherwise.

Where AI Emaily is genuinely useful is the other end of the same problem: the bounce that lands back in your own inbox. When a one-to-one email fails, the non-delivery report returns as a message, and in a busy inbox those get buried under everything else. AI Emaily triages your inbox so a real bounce surfaces instead of getting lost, and helps you read what the code is actually telling you. That is inbox work, not deliverability infrastructure — the job we do, stated at its real size. You can see how the triage works at aiemaily.com.