Every rejected message comes back with an SMTP reply code, and the very first digit tells you almost everything you need. A 5 means permanent failure — a hard bounce. A 4 means transient failure — a soft bounce. (A 2 means the message was accepted.) The enhanced status codes from RFC 3463 — the 5.1.1-style numbers — follow the same convention and add a precise reason. Get the classification right and the correct action follows automatically.
Hard bounce: permanent failure
A hard bounce is a 5.x.x rejection that will never succeed no matter how many times you retry, because the problem is permanent. The address doesn’t exist, the mailbox is disabled, or the domain has no working mail server. Typical hard bounces:
550 5.1.1— mailbox doesn’t exist (no such user). The most common hard bounce. Remove immediately.5.2.1— mailbox disabled. A closed, suspended or deactivated account. Suppress; don’t keep retrying.5.1.2/5.4.4— domain invalid or has no mail servers. The domain is defunct or misconfigured. Remove.550 5.7.1/554 5.7.1— blocked by policy (relaying denied, or a spam/reputation rejection). Permanent, but the cause is on your side or the recipient’s policy, not a bad mailbox — see below.
What to do: add the address to your suppression list the moment it hard-bounces, and never mail it again unless the person re-confirms through a fresh opt-in. Retrying a hard bounce is the worst thing you can do — each repeat is another strike against your sender reputation. One caveat: a 5.7.x policy block (like Gmail’s 550 5.7.26 or Outlook’s 550 5.7.515) is permanent but is an authentication problem, not a dead address. Don’t suppress those recipients — fix your SPF/DKIM/DMARC instead, as covered in fixing Gmail and Outlook rejections.
Soft bounce: temporary failure
A soft bounce is a 4.x.x deferral. The mailbox is real and reachable, but the receiving server couldn’t accept the message at that moment. The situation usually resolves on its own, so the right move is to let your mail server retry — which it does automatically. Typical soft bounces:
421 4.7.0— temporary deferral / greylisting. The receiver is asking you to try again shortly; most greylisters accept on the second attempt.451 4.3.0— local error at the receiver. Their problem, not yours. It typically clears on its own.452 4.2.2— mailbox full / over quota. May free up; retry over a day or two.450 4.x.x— mailbox temporarily unavailable, often greylisting or a soft reputation block.
What to do: keep the recipient and let your server retry with normal backoff over the next hours and days — do not remove the address on the first soft bounce. But don’t retry forever. If the same address soft-bounces on every attempt across several days (a persistently full mailbox, for instance), treat it as effectively dead and suppress it. A good rule of thumb is to convert a soft bounce to a suppression after it fails consistently for several consecutive campaigns.
The one confusing case: mailbox full
Mailbox-full is where the two categories blur. Some servers report it as a transient 452 4.2.2, others as a permanent-looking 552 5.2.2. Despite the 5, a full mailbox is often temporary — the user may clear space. Treat it as a soft bounce first: retry over a few days. Only if it keeps failing should you suppress. When a code’s meaning is ambiguous like this, paste the full bounce into the Bounce Message Analyzer — it reads the diagnostic text and tells you whether to retry or suppress.
Why the distinction matters for reputation
Mailbox providers watch how you respond to bounces, not just how many you get. Repeatedly hammering hard-bounced addresses is a textbook spammer behaviour and it damages your reputation fast — which is why hard bounces must be suppressed immediately. Handling soft bounces correctly (retry, then eventually suppress) keeps your list accurate without discarding recipients who were only briefly unavailable. Both feed your overall bounce rate, and most providers begin throttling once that rate climbs above roughly 2% — a widely-used industry benchmark. The full playbook for staying under it is in how to reduce your bounce rate.
Verify before you suppress
Before you permanently remove an address that hard-bounced, you can confirm it really is dead with the Email Verifier, which runs a live SMTP check without sending anything. And to decode any individual code in isolation, use the SMTP Response Code Analyzer. Cleaning proactively with the list-cleaning workflow means far fewer bounces to classify in the first place.
Common failure modes
- Suppressing on the first soft bounce. You throw away valid, reachable recipients over a momentary deferral. Let the server retry first.
- Retrying hard bounces. The address is gone; every retry hurts your reputation. Suppress on the first
5.x.xmailbox failure. - Suppressing 5.7.x authentication blocks as bad addresses. Those recipients are fine — your authentication is broken. Fix SPF/DKIM/DMARC instead.
- Ignoring persistent soft bounces. A mailbox that’s been full for weeks is effectively dead. Suppress after several consecutive failures.
Sources
The three-digit SMTP reply codes and their permanent (5xx) vs transient (4xx) meaning are defined in RFC 5321. The enhanced status codes (class.subject.detail, e.g. 5.1.1) come from RFC 3463, and the delivery status notification that carries a bounce is specified in RFC 3464.