A client sends us a bounce report roughly once a month with the same note attached: bounce rate climbed, we re-verified the list, the addresses came back valid, what now. The report is always sorted into hard and soft, and that sorting is the reason the question is hard to answer.
The hard and soft labels are not a diagnosis. They are a restatement of which class of response code the receiving server returned, 5xx or 4xx, and they were a reasonable proxy for cause back when almost every permanent refusal meant the mailbox did not exist. That assumption has been eroding for years and is now wrong often enough to break the standard fix.
Two things changed. Permanent refusals started arriving for reasons that have nothing to do with the recipient, which fills the hard column with tickets that belong to your DNS and your reputation rather than to your list. And the largest authentication requirement in consumer email, Microsoft's rule for high volume senders, currently does not produce a bounce at all. It produces a Junk placement, which means the fault is invisible in the one report everybody checks.
Hard bounce vs soft bounce: what the two codes actually tell you
Hard bounce vs soft bounce describes the shape of a failure rather than its cause: a hard bounce is a permanent 5xx refusal that instructs the sender never to retry, and a soft bounce is a temporary 4xx deferral that invites a retry later. Neither one names a reason.
That distinction is genuinely useful for one decision and one decision only, which is whether your sending system should try again. It was never designed to tell you what to fix. The reason it got treated as a diagnosis is historical: for most of the history of commercial email, the overwhelming majority of 5xx refusals really were no such user, and the overwhelming majority of 4xx deferrals really were a full mailbox or a busy server. Pattern matching on the response class worked because the underlying population was lopsided.
The population is no longer lopsided. Reputation refusals and policy refusals both return 5xx, because from the receiving server's point of view they are permanent: retrying will not change the fact that it has decided not to accept mail from your domain. They are hard bounces by definition, and they tell you nothing about the address.
| WHAT THE SERVER RETURNED | WHAT YOUR TOOL CALLS IT | WHAT IT ACTUALLY MEANS | WHAT FIXES IT |
|---|---|---|---|
| 550 5.1.1 no such user | Hard bounce | The mailbox does not exist at that domain | Remove the address, and look at where the list came from |
| 550 5.7.1 blocked for policy or reputation | Hard bounce | The provider is refusing your domain or IP on reputation or policy grounds | Reduce volume, fix complaint rate, rebuild sending reputation |
| 550 5.7.515 access denied, authentication level not met | Hard bounce | The text Microsoft has published for rejecting non compliant high volume senders, on an enforcement date it has not yet announced | Fix SPF, DKIM and DMARC alignment on the sending domain, nothing to do with the address |
| 452 4.2.2 mailbox full | Soft bounce | The recipient's mailbox is over quota | Retry, and suppress after repeated failures |
| 421 4.7.0 try again later | Soft bounce | Rate limiting or throttling, often an early reputation warning | Slow the send, and treat repeats as a reputation signal rather than noise |
Read that table as a list of five different engineering tickets wearing two labels. Two of the three permanent failures have nothing to do with the recipient, and one of the two soft failures is an early warning about your own reputation rather than a transient hiccup. Any process that branches on the hard or soft label is going to send most of these to the wrong team.
The authentication failure that is not a bad address
Microsoft's authentication requirement for high volume senders does not currently produce a bounce at all: non compliant mail has been routed to the Junk folder since 5 May 2025, with outright rejection announced for a date Microsoft has not yet named.
The specifics matter, because the threshold decides whether this applies to you. The requirement covers domains sending more than 5,000 messages a day to Microsoft's consumer mail services, counted on the same domain in the visible From address, and those senders have to pass SPF, DKIM and DMARC with proper alignment. One detail inside it catches people out: once a domain has crossed that threshold, the requirements keep applying to its subsequent mail even if daily volume falls back below 5,000. The classification does not lapse because you had a quiet week. Microsoft set the rule out in its own announcement of Outlook's requirements for high volume senders.
Read the sequencing carefully, because it is the opposite of how the second hand write-ups describe it. The current state is not rejection. It is Junk, which Microsoft framed as a grace period to let senders fix their records. That is worse for diagnosis, not better: a Junk placement produces no bounce, no error string and no entry in any deliverability report that counts failures. Reply rate drops, nobody can say why, and the bounce rate looks fine because nothing bounced.
Then note what has been published about the next step. Microsoft has committed to rejecting non compliant mail from these senders and has already specified the text the rejection will carry, access denied with the sending domain named and the required authentication level cited, but has not set the date. Plan on the basis that a misaligned domain is accruing a liability that converts, on a day you will not be warned about individually, from quiet Junk placement into a visible wall of hard bounces.
Now put a typical outbound build next to the threshold. Take a program running 10 sending domains with 4 mailboxes each and 50 sends a day per mailbox: 2,000 messages a day in total, 200 a day per domain. Those are illustrative numbers rather than a benchmark, and the point of them is that a deliberately distributed architecture sits far under the consumer threshold. Many outbound senders are nowhere near it.
Which is exactly why this gets missed. Teams read the threshold, correctly conclude it does not bind their per domain volume, and stop reading. Then one of three things happens: a marketing list goes out from the same root domain and crosses it, the organisation's transactional and newsletter traffic crosses it on a domain that also carries outbound, or the domain crossed it once months ago and the classification never lapsed. Meanwhile the refusals that do reach the bounce report today, the reputation and policy blocks, land in the same column as the dead mailboxes, and the team buys more verification credits.
“A verification vendor can tell you an address exists. It cannot tell you that the receiving provider refused to speak to your domain, or quietly filed your mail in Junk.”
This is the part we want to put plainly, because it is the whole argument. Verification answers one question, and we have written at length about how narrow that question is and how fast its answer decays in why address verification is only ever a point in time check. A refusal on authentication, policy or reputation grounds is not in the set of things verification can see. Spending verification budget on it is not an overcorrection, it is a null operation, and the number will be identical next week.
Why the hard bounce vs soft bounce split misroutes the fix
The hard bounce vs soft bounce split misroutes the fix because both labels derive from the response class, while the causes behind a climbing bounce rate fall into three groups that share no remedy: the list, the authentication, and the reputation.
List problems are the ones the industry has tooling for. Addresses that were valid at scrape time and have since been retired, role accounts that were never deliverable, typo domains, catch all servers that accept everything and then refuse quietly. These decay continuously, which is the mechanic behind list decay and why verification has to be continuous rather than one shot. Verification, suppression hygiene and better sourcing move this number.
Authentication problems are structural and binary. Either the sending domain's SPF record resolves and stays inside the lookup limit, the DKIM selector signs with a key the receiver can retrieve, and the DMARC alignment holds, or it does not. When it does not, every message from that domain to a provider enforcing a requirement fails the same way at the same time. The signature is distinctive once you know to look for it: the failure rate steps rather than drifts, it steps on one domain or on all of them depending on where the record lives, and it concentrates by receiving provider. We walked through the record level mechanics in how DMARC and the DMARCbis revision land on cold email sending domains.
Reputation problems drift. Complaint rate creeps toward and past the 0.10% that Google's sender guidelines name as the ceiling, engagement thins, and the provider starts throttling before it starts refusing. The early signal is in the 4xx column, which is the column everyone ignores because the tool retried successfully and nothing looked broken. A rising count of 421 deferrals that eventually succeed is a provider telling you politely that it is losing patience.
That shape test costs nothing and resolves most of these cases in a minute. It also fails safely: if the line genuinely drifts, verification and sourcing really are where the money should go, and you have confirmed it rather than assumed it.
Reading a bounce report when the addresses are valid
Reading a bounce report when the addresses are valid starts with the enhanced status code rather than the hard or soft label, because the three part number inside the server's response names the subsystem that refused the message and the label does not.
Every SMTP refusal carries two things worth keeping: the basic response code, which is the three digit number, and the enhanced status code, which is the dotted triple that follows it. The dotted triple is the useful one. Its middle and last segments distinguish a mailbox problem (5.1.x) from a policy or security problem (5.7.x), and that single distinction separates the tickets that belong to your list from the tickets that belong to your DNS. Most sending platforms capture the full string from the receiving server and then show you a rolled up label in the interface, so the information exists and is one export away.
None of this needs new software. It needs the bounce column in the standing report to be three columns, which is the sort of change we make early in reporting and analytics engagements because it costs an afternoon and permanently stops a recurring argument. The related discipline is monitoring the provider side feeds for the same signal, and the gap that opens when one of them goes dark is worth understanding, which is what we covered on what happens to deliverability monitoring during a provider data blackout.
The pages that answer this question stop at the definition
Search demand around this question is almost entirely definitional, and the pages satisfying it rank on structure rather than authority, which leaves the diagnostic version of the question, the one practitioners actually arrive with, substantially unanswered.
We pulled the result set for the phrase on 3 October 2026. The demand is real and steady: 400 searches a month in the United States for the comparison phrase itself, 400 for hard bounce alone, 300 for soft bounce, 250 for email bounce rate. Keyword difficulty on the comparison phrase comes back at 0. Nothing about the term is competitive.
Monthly US search volume across the bounce question cluster, indexed to the largest term at 400 searches a month (Ahrefs, 3 October 2026)
The result set itself is the interesting part, and it makes a point about page level authority that we keep running into. Domain Rating across the top ten spans 11 to 99, from a schools marketing site up to a professional network, and every individual page we measured in that set carried a URL Rating of 4 or lower. Page level link equity is not what is sorting these results, because there is almost none of it anywhere in the set. Structure is.
| PAGE IN THE TOP TEN | DOMAIN RATING | URL RATING | WHAT THAT COMBINATION SAYS |
|---|---|---|---|
| A platform help centre article | 96 | 4 | Enormous domain authority, almost no page level equity, ranking on structure and domain trust |
| A professional network post | 99 | 0 | The highest domain authority in the set with zero page equity, which is as close to a pure structure result as you get |
| A niche vertical marketing blog | 11 | 4 | Domain Rating 11 holding a top ten position against both of the above |
| Community threads and Q and A pages | Not rated at page level | Not rated at page level | Forum answers occupying positions four to six, which is demand the publishers in the set are not meeting |
Two conclusions follow, and the second is the one that produced this piece. First, this is a question where a well structured answer outranks authority, so the barrier to being the best page on it is editorial rather than financial. Second, and more usefully: the questions the result set is being asked are not the questions it answers. Google's own related questions on this result set include whether you should delete hard bounced addresses, what an acceptable hard bounce rate is, and why someone is receiving bounces for mail they did not send. That last one is a spoofing and authentication question sitting in the middle of a definitions page, which is the gap in miniature.
How to instrument bounces so they point at a cause
Instrumenting bounces usefully means logging the full enhanced status code and the rejecting provider for every failure, then grouping by sending domain and by provider rather than by the hard or soft label the sending tool assigns to the response class.
The ordering is the argument. List quality goes last not because it does not matter, it matters constantly, but because it is the cause that is already resourced, already measured and already has a vendor attached to it. Putting it last is the only reliable way to stop it absorbing the budget for the two causes that have neither. Keeping that sequence on the calendar is part of how we run cold email lead generation rather than something we do after a bounce report arrives.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Josh leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.