Hard Bounce vs Soft Bounce Explained (+ How to Handle Each)

Every bounce that comes back to your inbox is carrying a number, and that number tells you exactly what to do next. Most cold senders never read it. They lump every failed email into one pile called "bad," delete the lot, and move on. That's how you end up suppressing a perfectly good lead whose mailbox was full for an afternoon, or worse, hammering a dead address until your domain reputation cracks.

This is the hard bounce vs soft bounce explained the way an operator actually uses it: by the SMTP code attached to the failure. Get the taxonomy right and the handling rules write themselves. A permanent failure gets suppressed. A temporary one gets retried. The whole skill is telling them apart in the half-second before you act.

Hard bounce vs soft bounce: the short answer

A hard bounce is a permanent delivery failure. The receiving server is telling you this address will never accept your mail: it doesn't exist, the domain can't receive email, or you've been explicitly blocked. A soft bounce is a temporary failure. The address is probably fine, but something stood in the way right now: a full mailbox, a rate limit, a server hiccup, or an anti-spam delay.

The difference isn't a guess. It's encoded in the first digit of the SMTP reply code.

That table is the entire decision tree. The rest of this article is about reading the codes confidently and handling the handful of cases that sit in the gray zone.

The numbers behind every bounce

When a mail server refuses your message, it answers with a reply code. The original SMTP spec, RFC 5321, sorts these three-digit codes by their first digit. A 2yz code is a success. A 4yz code is a "Transient Negative Completion Reply," meaning the command failed but the condition is temporary and the same request may succeed if you try later. A 5yz code is a "Permanent Negative Completion Reply," meaning retrying with the same parameters will fail again.

That single digit is the foundation of the whole hard-versus-soft split. Four means try again. Five means stop.

Modern servers stack a second, more precise code on top, defined in RFC 3463. These are the enhanced status codes you see in bounce messages, written as class.subject.detail:

• Class is the first number: 2 (success), 4 (persistent transient failure), or 5 (permanent failure). It mirrors the basic reply code's first digit.
• Subject is the middle number and points at the source of the problem. x.1.x is an addressing issue, x.2.x is a mailbox issue, x.7.x is a security or policy issue.
• Detail is the last number, the precise error.

So 5.1.1 reads as: permanent failure (5), addressing problem (1), bad destination mailbox address (1). Microsoft's Exchange Online documentation describes the same format and confirms the rule directly: "a 5.x.x code indicates a permanent error, and a 4.x.x code indicates a temporary error." Both numbers, the basic and the enhanced, travel together in the bounce. Read the first digit of either and you already know whether you're holding a hard bounce or a soft one.

When you see a full bounce message, the formal name for that report is a DSN (Delivery Status Notification) or NDR (Non-Delivery Report). It's the same thing your tool surfaces as a "bounce." Inside it lives the code that decides everything.

What is a hard bounce?

A hard bounce is a class 5.x.x permanent failure. The mailbox provider has made a final decision, and no amount of retrying will change it. There are three flavors worth knowing.

The address doesn't exist. This is the classic hard bounce and the one you'll see most on a cold list. Gmail returns 550 5.1.1 with the text "The email account that you tried to reach does not exist," per Google Workspace's SMTP error reference. Microsoft maps the same 5.1.1 to "Bad destination mailbox address." The person left the company, the address was a typo, or it was never real. Suppress it.

The mailbox is disabled. Gmail's 550 5.2.1 means "The email account that you tried to reach is inactive." The account existed but has been shut off. Treat it like a dead address and suppress.

The whole domain can't receive mail. A 5.1.2 "bad destination system address" or 5.1.10 "recipient not found" points at the right side of the @ sign. The domain has no working mail server, or the SMTP lookup found nothing. The address is unreachable at the domain level. Suppress.

Across all three, the action is identical and non-negotiable: add the address to your suppression list and never send to it again. Repeatedly mailing addresses that hard-bounce is one of the loudest negative signals you can send a mailbox provider. It says you're working from a list you didn't validate, which is exactly the profile of a spammer.

What is a soft bounce?

A soft bounce is a class 4.x.x transient failure. The address is presumed good, but delivery didn't happen this time. The receiving server is effectively saying "not now, ask again later." Common causes:

• Full mailbox. A temporary "mailbox full" returns 4.2.2, which RFC 3463 defines as a persistent transient failure tied to quota or capacity. The user just needs to clear space. Retry over the next day or two and it usually clears.
• Greylisting. Some servers deliberately reject the first attempt from an unfamiliar sender with a 450 or 451 4.7.1, then accept it on retry. This is a standard anti-spam tactic described in RFC 6647. Legitimate mail servers retry automatically, so greylisting usually resolves within an hour or two without you doing anything.
• Rate limiting. When you send too fast, Gmail returns 421 4.7.28 with "Gmail has detected an unusual rate of email... email has been temporarily rate limited." A related 421 4.7.0 fires when the sending IP's reputation is low. These are transient: slow down and the queue drains.
• Server-side trouble. A 421 service-not-available, a 451 local processing error, or a 452 4.x.x "insufficient system storage" all sit on the receiving end. Nothing's wrong with the address. Wait and retry.

The handling rule for soft bounces is patience with a ceiling. Retry on a sensible schedule (most sending engines space attempts hours apart over a few days), but don't retry forever. If an address soft-bounces on every attempt for several days running, it has graduated into a problem worth suppressing, because a mailbox that's been "full" for a week is functionally dead.

Email bounce types: the codes that decide your action

Here's the reference table I keep within arm's reach. It maps the codes a cold sender actually meets to a bounce type and a single action. When a bounce lands, find the code, read the row, act.

Two rows in that table deserve a second look, because they're where smart senders make mistakes.

The "full mailbox" trap: 4.2.2 vs 5.2.2

Mailbox-full comes in two versions, and the first digit is the whole story. RFC 3463 puts a temporary full mailbox at 4.2.2, a transient failure you retry. But there's also a permanent 5.2.2. Gmail's 552 5.2.2 reads "The recipient's inbox is out of storage space and inactive," and that word "inactive" is the tell. Google has decided this mailbox is abandoned, not just briefly full. Microsoft, confusingly, uses 5.2.2 "Submission quota exceeded" to mean something different again: that the sending account exceeded its own rate limit, often a sign the account was compromised.

The lesson isn't to memorize every vendor's quirk. It's to trust the class digit. A 4 in front means retry. A 5 in front means treat it as a hard bounce and stop sending, even when the words say "full."

Block bounces: when a 5.x.x isn't a dead address

This is the single most useful distinction in the whole taxonomy, and most guides skip it.

A 550 5.7.1 is a permanent failure by class, so technically it's a hard bounce. But it doesn't mean the address is bad. It means you were blocked. Google's text for 5.7.1 is blunt: "The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent," or "This message is likely unsolicited email... this message has been blocked." Microsoft's 5.7.1 is "Delivery not authorized, message refused."

Suppressing the address here would be a mistake. The mailbox exists and the person is real. The receiving server rejected this message from this sender on reputation or policy grounds. The fix isn't to delete the lead. It's to fix the cause: check your authentication, slow your volume, and review your content. If you're seeing a wave of 5.7.1 blocks, that's a reputation problem, and the playbook is in our guides on how to avoid spam filters and, if things have gone badly, how to recover a burned cold email domain.

So the mental model has three buckets, not two: hard bounces (dead address, suppress), soft bounces (temporary, retry), and block bounces (you're being filtered, fix yourself). The first digit alone can't separate that third bucket from the first. You have to read the subject digit too. An x.1.x or x.2.x permanent failure is about the recipient. An x.7.x permanent failure is about you.

How to handle each bounce: the operator's ruleset

Put it all together and the workflow is short.

1. Read the class digit first. 4 means transient, 5 means permanent. This is your fork in the road.
2. For 5.x.x, read the subject digit. x.1.x (addressing) or x.2.x (mailbox) means the address is genuinely bad: suppress it now, this campaign and forever. x.7.x (security or policy) means you got blocked: leave the address alone and fix your sending.
3. For 4.x.x, retry on a schedule. Let your sending engine handle the spacing. Greylisting and rate limits clear on their own. Set a hard ceiling: if an address soft-bounces every attempt for roughly 72 hours, promote it to suppressed.
4. Log everything. Keep the raw code with each contact. Patterns in the codes are diagnostic. A spike in 5.1.1 means your list is stale. A spike in 421/4.7.x means you're sending too fast. A spike in 5.7.1 means your reputation is slipping.

A decent sending platform does most of this for you. MailBeast classifies each SMTP response at the source, separates retryable soft failures from permanent hard bounces, and auto-suppresses dead addresses so you don't keep mailing them by accident. But even with automation, you should understand the codes, because the patterns in your bounce log are an early-warning system for deliverability problems you'd otherwise notice weeks too late.

Why getting this right protects your domain

Mailbox providers watch how you respond to their feedback. Hard-bouncing the same address again and again tells Gmail and Outlook that you're not maintaining your list, and list hygiene is one of the signals they weigh when deciding whether your next message lands in the inbox or the spam folder.

Google's sender guidelines make the underlying expectation clear. They tell senders to "confirm each recipient's email address before subscribing them" and to "send email only to people who want to get messages from you." On bounces specifically, Google's advice is direct: "If messages start bouncing or start being deferred, reduce the sending volume until the SMTP error rate decreases." That last line is worth taping to your monitor. When bounces climb, the move is to slow down, not to push harder.

There's a second-order effect too. Many dead addresses on old domains quietly become spam traps, and hitting one can get you onto a blocklist. We cover the trap mechanism separately, but the defensive principle is the same: a clean list that respects hard bounces is a list that doesn't accumulate landmines.

What counts as "too many" bounces? That's a benchmark question with its own answer, and rather than repeat it here, see what is a good email bounce rate for the provider-by-provider thresholds. For the broader set of metrics that tell you whether your sending is healthy, the cold email metrics guide lays out the 12 that matter.

Prevention beats handling

The cleanest way to handle bounces is to have fewer of them. Almost every hard bounce on a cold list is avoidable, because the address was already dead before you hit send. The fix happens upstream, in three places:

• Verify before you send. A verification pass catches the dead and malformed addresses that would otherwise hard-bounce, so you never spend reputation on them. The full process is in how to verify email addresses before sending.
• Decide what to do with catch-all domains. Catch-all (accept-all) servers accept everything at the SMTP layer, which means a verifier can't always confirm a specific mailbox, and some of those "accepted" addresses bounce later. How to treat them is its own decision, covered in handling catch-all emails on a cold list.
• Clean the list, then keep it clean. Stale lists rot. Running a list through a hygiene pass before every major campaign keeps your hard-bounce rate low. Use the email list cleaning checklist as your pre-send routine.

For the wider playbook of tactics that drive the number down, how to reduce email bounce rate collects them in one place. And if you're building your list from scratch and want it accurate from day one, the B2B lead list guide starts you with cleaner data. Bounce handling is downstream cleanup. Verification and list hygiene are the actual fix.

Common questions

Is a soft bounce bad for my sender reputation?

Not on its own. A soft bounce is a temporary deferral, and providers expect a small number of them on any send. They only become a problem if they're caused by you, for example a 421 4.7.28 rate-limit or a low-reputation block, or if the same address soft-bounces indefinitely. A handful of transient failures that resolve on retry won't move your reputation. A steady stream of 4.7.x throttling responses is a sign you're sending too fast.

How many times should I retry a soft bounce?

Let your sending engine handle the cadence, usually a few attempts spaced hours apart over two to three days. Greylisting and rate limits clear quickly. A practical ceiling is around 72 hours: if an address still soft-bounces after that, treat it as permanently undeliverable and suppress it. Beyond that window, you're spending reputation to reach a mailbox that isn't responding.

Does one hard bounce hurt my domain?

A single hard bounce is normal and harmless. Even a well-verified list will have a few addresses that went dead between verification and send. The damage comes from repeatedly sending to addresses you already know are dead, and from high hard-bounce rates that signal an unverified list. Suppress on the first hard bounce and you're fine.

What's the difference between a bounce and a block?

A bounce is a delivery failure reported back to you. A block is a specific kind of permanent failure, usually a 5.7.x code, where the receiving server refused your message on reputation or policy grounds rather than because the address is bad. Blocks are technically "hard" by SMTP class, but you handle them differently: fix your authentication, volume, and content instead of suppressing the recipient.

Can I tell hard from soft just by the bounce message text?

Sometimes, but the code is more reliable than the words. Vendor wording is inconsistent, "mailbox full" can be either a temporary 4.2.2 or a permanent 5.2.2. The first digit of the SMTP class never lies: 4 is transient, 5 is permanent. When the text and the code seem to disagree, trust the code.

The bottom line

Hard bounce vs soft bounce, explained in one rule: read the first digit. A 5 is permanent, so suppress the address and stop. A 4 is temporary, so retry within reason and move on. The only nuance worth carrying is the third bucket: a 5.7.x block is permanent by class but isn't a dead address, it's a signal to fix your own sending.

Wire that logic into your process, log the codes, and watch the patterns. Your bounce report stops being a graveyard of failures and becomes one of the most honest deliverability dashboards you have. Most of all, do the upstream work, because a verified, clean list turns the entire hard-versus-soft question into a footnote.

Sources

• IETF, RFC 5321: Simple Mail Transfer Protocol
• IETF, RFC 3463: Enhanced Mail System Status Codes
• IETF, RFC 6647: Email Greylisting
• Google Workspace, Gmail SMTP errors and codes
• Google, Email sender guidelines
• Microsoft, Email nondelivery reports (NDRs) and SMTP errors in Exchange Online