Hard Bounce: The Permanent Failure That Is Not Always About the Address

Hard Bounce: The Permanent Failure That Is Not Always About the Address

A hard bounce is a permanent delivery failure. The receiving mail server refused the message with an SMTP 5xx reply, and the sending server is not expected to attempt it again. The address is marked undeliverable, the sending platform stops trying, and the message never arrives.

That is the complete definition. Notice what it leaves out: it says nothing about the address being wrong.

The reply code is the definition

Mail servers answer each other in three-digit codes, and the first digit carries the category. RFC 5321, the SMTP specification, defines a 5yz reply as a Permanent Negative Completion reply: "The command was not accepted and the requested action did not occur. The SMTP client SHOULD NOT repeat the exact request (in the same sequence)."

That instruction is the whole mechanism. A 4xx tells the sending server to queue the message and try later, which is what everyone calls a soft bounce. A 5xx tells it to stop. Your platform obeys, writes the failure into its reporting, and flags the address so no future campaign attempts it.

The reply usually arrives as a 550 or a 554 with a short human-readable string after the code, and that string is the only part of the exchange that says why. The digits carry the verdict. The text carries the reason. Most reporting interfaces surface the verdict prominently and bury the reason behind a click, which is where most of the misreading in this article begins.

The three shapes of a permanent refusal

Permanent failures arrive from three genuinely different places, and only the first two are about the person you were writing to.

The mailbox does not exist. The domain accepted the connection, looked up the local part of the address, and found nothing. Someone left the company, the address was mistyped at capture, or an enrichment tool guessed a pattern that this organisation does not use. This is the case the word "hard bounce" was coined for.

The domain does not resolve or accepts no mail. The address's domain has no mail exchanger record, or no DNS record at all. The company folded, the domain lapsed, or the record was never there. This failure often happens before any SMTP conversation takes place, since there is no server to talk to, and the sending platform generates the bounce itself rather than reporting one it received.

The sender is refused by policy. The address may be perfect. The receiving side simply declined to accept mail from you, from your domain, or from the network your mail came out of. The reply is a 5xx like any other, and it lands in the same bucket in your dashboard as a dead mailbox.

Two details make the first shape less obvious than it sounds. Plenty of business domains are configured to accept mail for every local part and sort it out internally, so they never produce a permanent failure at the door even when the mailbox is fictional. Verification tools report those domains as accept-all, and the addresses behind them are unresolved rather than confirmed. Other domains reject unknown recipients only after accepting the message, which produces the failure minutes or hours later as a separate delivery report. Either way, the count you read immediately after a send is provisional, and a figure taken once the reports have settled is the one worth comparing against anything.

Address-level failureThe recipient does not exist

• The local part is unknown at that domain
• Wrong at capture, or the person has left
• Scattered across many receiving domains
• Remove the address and move on
• Verification before sending prevents most of it

Domain-level failureNowhere to deliver

• No mail exchanger record, or no DNS at all
• The business closed or the domain lapsed
• Every address at that company fails together
• Remove the whole domain from the list
• Visible before send if the list is checked for live mail exchangers

Policy refusalThe receiver declined you

• The address is usually valid and reachable
• A blocked sending domain, a listed network, or a gateway rule
• Concentrated at one receiving domain or one gateway vendor
• Removing the recipient makes this worse
• Fix the sending side before sending into that provider again

Why the address has to come out

An address that produced a permanent failure has to leave the sending list immediately, and the reason is not tidiness.

Receiving providers read bounce rate as a statement about the sender. A mail stream carrying a high share of addresses that do not exist looks like a list that was bought, guessed or scraped, because that is overwhelmingly what produces one. The receiving side has no way to inspect your intentions and every reason to use the cheapest available proxy for list quality, so it uses the proportion of your mail that lands nowhere. Sending again into the same dead address after being told it is dead is the clearest possible signal that nothing on your side is reading the responses.

The damage therefore accrues to the sender rather than being confined to the wasted send. A campaign with a high permanent-failure rate degrades the standing of the domain that sent it, and that degraded standing is applied to every message from that domain afterwards, including the ones going to perfectly valid people who would have replied. That is the asymmetry worth internalising: the bad address costs you one wasted send, and the pattern of bad addresses costs you placement on all the good ones. What a healthy rate looks like on cold traffic is set out in cold email bounce rate benchmarks, and the practical prevention is a verification pass before the send, compared in email verification tools.

Where the definition breaks

Not every hard bounce is a bad address, and the default handling of the exception makes the underlying problem worse in two ways at once.

A 5xx can be a policy rejection of you. A blocked sending domain, a listed IP range, or a security gateway configured to refuse mail that fails its own checks will all refuse permanently, in the same reply class as a dead mailbox. The recipient is a real person at a real company who reads their mail every morning. The refusal is a statement about your sending infrastructure, delivered in a format that your tooling reads as a statement about their data.

Handled by default, two things then happen. The address is suppressed, so a real and valid prospect is deleted from your data permanently, and the deletion is invisible because it looks exactly like the routine removal of a dead mailbox. And the evidence disappears with it. Once the recipient is gone, the sending problem stops recurring at that address, so it never accumulates into a pattern anyone can see. A reputation event has been quietly filed as a data-quality event, and the filing system has destroyed the record that would have corrected it.

Reading a permanent failure before you automate the removal

• ✓Yes: Open the reply text. The reason string, not the code, tells you which of the three shapes you have
• ✓Yes: Group the failures by receiving domain before reading any total
• ✓Yes: Check whether the same failures name a gateway vendor rather than a mailbox
• ✓Yes: Check whether good, verified addresses at that receiving domain failed alongside the doubtful ones
• ✓Yes: Check whether the pattern follows one of your sending domains across many receivers
• ✕No: Suppress the address on a wording you have not read
• ✕No: Treat a campaign-wide percentage as the diagnosis

The distribution is what separates the cases, and it separates them cleanly enough that you rarely need to guess. Address-level failures scatter. Bad data is randomly distributed across the receiving world, so dead mailboxes turn up at hundreds of unrelated domains in roughly the proportion those domains appear in your list. Policy failures concentrate. They cluster at one receiving domain, or at several domains that turn out to share one security gateway vendor, and they take down good addresses next to bad ones without discriminating, because the rule they tripped was never about the recipient.

The second tell is which of your own sending domains is involved. A failure pattern that follows one sending domain across many receivers is that domain's problem: its authentication, its history, its presence on a list somewhere. A failure pattern that appears at one receiver across all of your sending domains is that receiver's judgment of you as a whole. Neither is fixed by cleaning data. The delisting and recovery path for the first is in email blacklist check and recovery, and the wider diagnostic order is in the cold email deliverability guide.

There is a further wrinkle in the gateway case that is worth naming, because it is the one people most often mistake for a data problem. Security gateways sit in front of a company's real mail system, and a single vendor may sit in front of thousands of unrelated companies. When one of those vendors decides against your sending domain, the refusals appear at a long list of receiving domains that look unconnected in your reporting, which makes the pattern read as scattered rather than concentrated. The concentration is real, and it is visible only if you resolve the receiving domains to whatever is actually answering for them. That check turns an apparently random spread of failures back into what it is, which is one vendor's decision applied many times.

So the operating rule is narrow and easy to apply. Read the reply text before you automate the removal. If the text names the recipient, remove the recipient. If the text names you, keep the recipient, stop sending into that receiver, and fix the thing the receiver objected to.

What a rate hides

A single campaign-level bounce percentage is the least informative number in the report, because it averages the three causes above into one figure that responds to all of them and diagnoses none.

1. Step 1Split address-level from policy refusals

   Read the reason strings and sort them. The two classes have opposite remedies, so a combined figure recommends nothing.

2. Step 2Group by receiving domain

   Scatter across many receivers points at data. Concentration at one receiver or one gateway vendor points at your sending.

3. Step 3Group by sending domain

   A pattern that follows one of your own domains everywhere is that domain's standing, not your list.

4. Step 4Act on the class, not the total

   Address failures leave the list. Policy refusals stay in the data and stop the sending until the cause is cleared.

There is a second thing the rate hides, and it works in the flattering direction. Verification removes addresses that would have failed permanently, which is the point of running it. It also removes them from the denominator of the problem, so a heavily verified list can show a comfortable bounce figure while a policy refusal is quietly eating a specific receiving domain in the background. The comfortable number is real and the hidden problem is also real. Reading the rate by receiving domain is what surfaces the second one, and it costs nothing beyond the decision to look.

Soft bounces sit on the other side of this boundary and behave differently in every respect that matters: a temporary refusal keeps the address, keeps the message queued, and frequently resolves itself without any intervention. The two are worth keeping firmly separate in your own reporting, because a platform that collapses them into a single "bounced" column removes the one distinction that tells you what to do next.

In a live programme

The practical shape of this is unglamorous. Verify before sending, so the address-level class is small enough that the policy class becomes visible against it. Read failure reasons by receiving domain rather than as a campaign total. Keep an address that failed for a reason that named your infrastructure, and treat that failure as an infrastructure task rather than a list task.

The one habit that pays for itself repeatedly is checking whether a spike is concentrated before deciding what it means. A concentrated spike is nearly always about you. A scattered one is nearly always about the data. Almost every wrong response to a bounce report comes from skipping that single check and applying the remedy for one class to the other.

Reading reply text at volume is a habit rather than a tool. Our pay-per-qualified-meeting outbound is the arrangement where we keep the habit and you keep the meetings.

Verified as of August 2026. Verify current terms with the vendor before relying on them.