Rejection, soft bounce, or spam folder: reading a 2026 delivery failure correctly

For years, “my email didn’t get delivered” mostly meant one of two things: it bounced, or it landed in spam. In 2026, across Gmail, Yahoo, and Microsoft’s consumer mailboxes, that binary isn’t precise enough anymore. Enforcement of bulk-sender rules has gotten more granular on all three, which means the failures have too — and reading a delivery problem correctly now requires telling apart three genuinely different things: a hard authentication rejection, a reputation-based soft bounce, and mail that was accepted but silently spam-foldered. Each one points at a different root cause, and fixing the wrong one wastes time without fixing anything.

This post assumes you already know how to pull raw headers off a message — if you don’t, this field guide covers the mechanics. What follows is how to interpret what you find once you have it.

The three failure signatures

	Hard rejection	Soft bounce / throttle	Silent spam-foldering
SMTP response	Permanent 5xx	Temporary 4xx	None — 250 OK accepted
Example code	550 5.7.26 (Gmail) / 550 5.7.515 (Microsoft)	421 4.7.28 (Gmail)	No bounce logged
Root cause	Authentication failure: SPF/DKIM/DMARC not passing	Sending rate or reputation tripped a limit	Content, engagement, or reputation signals after acceptance
Visible in your logs?	✓	✓	—
Automatic retry helps?	—	✓	—
The fix	Fix DNS records and alignment	Slow down, let reputation recover	Improve relevance, list hygiene, engagement

Hard rejection: the message never lands anywhere

A permanent 5xx response means the receiving mailbox provider refused the message during the SMTP conversation itself. It didn’t go to spam — it was never accepted. Gmail’s 550 5.7.26 and Microsoft’s 550 5.7.515 both mean the same underlying thing despite the different code: SPF and DKIM did not pass, or DMARC alignment failed, for the sending domain. Retrying the identical message changes nothing, because the message itself isn’t the problem — the DNS configuration behind it is. Microsoft has stated explicitly that recipient-side safe-sender lists don’t override this either; a broken authentication chain fails regardless of whether the recipient trusts you.

The fix is entirely in DNS: correct SPF, publish or fix DKIM signing, and make sure DMARC aligns with the domain in your From: header, not just some intermediate sending platform’s domain.

Soft bounce: a temporary rate or reputation problem

A 4xx response is Gmail (and, less commonly, other providers) telling your sending server “not right now, try again later.” 421 4.7.28 specifically flags an unusual rate of mail from your sending IP or domain relative to its established reputation — a classic symptom of ramping volume too fast, especially on a domain or IP without much sending history behind it yet. Unlike a hard rejection, this one is meant to self-resolve: a compliant sending platform retries automatically, and if the underlying volume spike settles down, delivery typically recovers within a day or two.

The mistake here is treating a soft bounce like a hard one and immediately auditing DNS records — there’s usually nothing wrong with them. The actual fix is slowing down: reduce sending volume, avoid sudden spikes, and let a newer domain or IP build reputation gradually rather than pushing full volume on day one. That’s the specific failure mode Norbelys’s warmup ramp exists to prevent in the first place — a new mailbox’s daily volume increases on a schedule instead of jumping straight to campaign-size sends, so the domain has reputation history behind it before it’s ever asked to carry real volume, rather than discovering the 421 the hard way on day two.

Silent spam-foldering: the one with no error at all

This is the failure mode most likely to go unnoticed, because nothing in your send logs flags it. The SMTP transaction completes successfully, the message is accepted, and your platform reports it as delivered — but the receiving provider’s post-acceptance content and engagement filters route it to spam anyway. There’s no code to read, because there’s no error. The only symptom is indirect: opens and replies quietly trending toward zero on a segment or domain where they used to be normal.

Diagnosing this one requires looking outside your own send logs — a seed-list inbox-placement test, or spam-rate data from Google Postmaster Tools for a Gmail-heavy audience, since the provider-side placement decision isn’t visible from the sending side at all. The fix isn’t a DNS change or a slower send rate; it’s relevance and permission — tighter targeting, cleaner lists, and sequences that respect engagement signals instead of pushing volume at people who’ve stopped opening.

Why the wrong diagnosis costs more time than the actual fix

Here’s the shape of the mistake that shows up most often in practice. A sender notices reply rates dropping on a campaign and, understandably, assumes something broke. They pull up their sending platform’s dashboard, see delivery marked “successful” for nearly every message, and conclude the problem must be upstream — bad list data, a weak subject line, an off week for the audience. So they rewrite the email, test new subject lines, maybe add another follow-up step to compensate for the apparent drop in response. None of it moves the number, because none of it touches the actual cause: the messages were silently spam-foldered, and “delivered” in the dashboard only ever meant “the SMTP transaction completed,” not “a human ever saw it in their primary inbox.”

The inverse mistake is just as common and just as expensive. A domain starts seeing 421 4.7.28 deferrals after a volume increase, and the sender’s first instinct is to audit every DNS record — SPF, DKIM, DMARC — assuming something about authentication broke. Hours go into re-verifying records that were never the problem, while the actual fix (slow down, let the spike settle, resume at a lower rate) sits untried the entire time. Meanwhile the deferred messages keep queuing and retrying against a receiving server that’s still seeing the same elevated rate, because nothing about the sending behavior changed while the DNS investigation was underway.

Both failures come from the same root habit: treating “delivery failed somehow” as one problem instead of three, and reaching for the fix that feels most familiar — usually a content or DNS change — instead of first reading which of the three signatures actually occurred. The five minutes it takes to check the SMTP response class before touching anything else is what separates a fix that works from a week of changing things that were never broken.

Match the fix to the failure

The single most common mistake across all three is applying the wrong fix: re-checking DNS records that were never broken, throttling volume when the real problem is content relevance, or waiting out a “temporary” issue that’s actually a permanent rejection that will recur on every retry. Reading the SMTP response class (4 vs. 5), the extended status code, and — critically — whether there was a response at all is what tells you which of the three problems you’re actually looking at before you spend time fixing the wrong one.

If you’re troubleshooting a live domain, Norbelys’s deliverability monitoring surfaces authentication status and spam-complaint trends per sending domain, which narrows down which of these three categories a delivery problem falls into faster than reading raw bounce logs one message at a time.

Reading delivery failures — quick answers

Can a single campaign trigger all three failure modes at once?+

Yes, and it happens more often than senders expect. A campaign sent too fast on a newer domain can pick up 421 deferrals early, while messages that do get through land in spam because engagement signals are already weak, and a subset from a misconfigured secondary sending source get hard-rejected outright. Each recipient's outcome depends on the receiving provider, the sending IP or domain's specific reputation, and that individual message's authentication — so three different senders' logs, or even three segments of one send, can show three different failure types simultaneously.

Does retrying a hard-rejected message ever work?+

Not on its own. A permanent 5xx rejection is tied to the authentication configuration, not the specific message, so an identical retry fails the identical way every time. The only thing that changes the outcome is fixing SPF, DKIM, or DMARC alignment first, then sending — at which point it's a new attempt against a corrected configuration, not a genuine retry of the failed one.

How quickly does a soft-bounce reputation problem usually recover?+

Typically within a day or two once the sending rate drops back to something consistent with the domain or IP's established history — there's no fixed universal number since providers don't publish their exact thresholds, but the pattern is a gradual return to normal deferral rates rather than an instant reset the moment volume decreases.

Is there any way to see spam-foldering directly, rather than inferring it from engagement drops?+

Only through tools that sit outside your own send logs — seed-list inbox-placement testing, or aggregate spam-rate data from a mailbox provider's own postmaster tooling for high-volume Gmail-heavy sends. Neither your sending platform nor the receiving server tells you directly that a specific message was spam-foldered; a dropping engagement trend on an otherwise-unchanged audience is the closest thing to a direct signal available from the sending side.