Poppin’ off about email bounces

March 13, 2026

 

This week, the Bounce House is going meta and talking about all things email bounce.

Bouncing sounds like fun, until you fall on your as…
I mean, trampolines are bouncy, but deceptively dangerous. Leprechauns are bouncy, but they’re tricksters. Email bounce logs are bouncy, but they’re also misleading. 

Every email expert in existence teaches the same neat little rule: 

4xx = soft bounce (temporary, retry!) 5xx = hard bounce (permanent, delete!) 

And I will admit that is broadly true. In the same way “green means go” is true, but you still wait for oncoming traffic to clear the intersection before you hit the gas. 

Here’s what most glossaries skip over:
Bounce codes are signals. Treating them as law will get you sideswiped. 

They’re strategic, they’re contextual, and they are absolutely not applied consistently across mailbox providers, private servers, or even time and space. 

There is no global bounce tribunal. The Inbox Supreme Court won’t say a bounce rule is unjust. No international bounce standards enforcement squad will be pulling mailbox providers over like: 

“Excuse me, Gmail, you used a 4xx for something that feels pretty 5xx-ish. We’re gonna need to see some ID.” 

Mailbox providers return whatever response best protects their users, not optimizing for your ROI. Which means if you’re treating bounces like a flowchart instead of a conversation, it’s time to spring forward. 

It’s 2026, and we’re moving past binary bounce logic. 

Senders love a hard and fast rule of thumb, like: 

✅ 4xx = “It’s fine, just retry!”  

❌ 5xx = “It’s dead, suppress forever!” 

But delivereality (I just coined that one, you’re welcome) is messier: 

• Some 4xx failures will never succeed, no matter how often you retry. 

• Some 5xx failures will resolve later when conditions change. 

• The same code can mean different things at different providers. 

• Providers can change how they use codes or introduce new ones without notice. 

• Sometimes they get it wrong, and probably won’t admit it. 

They optimize for user safety, not your reporting clarity. Mailbox providers can label a failure however they want, and it’s up to us to interpret what actually happened. 

1) SMTP gives providers suggested verbiage, not ironclad templates 

SMTP basically says: “Here’s how you format a response.” It does not say: “Here’s exactly when you must use each response and what to say.” 

Mailbox providers classify failures based on what they care about, which is primarily: 

• Abuse prevention 

• Resource constraints 

• Spam patterns 

• User behavior signals 

• Policy changes 

• Internal risk scoring 

• Their own operational quirks 

• My job security (thank you Microsoft for your continued service) 

2) Failures happen at different points in the handshake 

Not all bounces are created equal. “Failed” could mean: 

• The domain is dead or broken 

• The recipient address doesn’t exist 

• The server wants to slow you down 

• The provider thinks you’re sketchy 

• Your content triggered a policy block 

• You’re sending like a firehose but you’ve only got a sprinkler’s reputation 

And those all get represented as… a couple of digits and a link, probably to a postmaster page that was last updated in the dialup days. 

3) Some “temporary” failures are permanent in practice 

Classic example: mailbox full. 

Technically temporary. But, practically? That mailbox may have been full since the pandemic (RIP social distancing, we barely knew ye). 

Other “4xx but don’t kid yourself” scenarios: 

• Corporate policy blocks that require manual allowlisting (and nobody will do it) 

• Greylisting loops your retry pattern never satisfies 

• No MX record  

Retrying those endlessly is like texting “wyd” to a disconnected number, only worse; in this scenario T-Mobile could just choose to never deliver any of your “u up?”s to anyone, ever again, even if they wanted them and were indeed up. 

4) Sometimes “permanent” doesn’t mean “forever” 

Meanwhile, 5xx can sometimes be situational: 

• DNS gets fixed 

• A user reactivates an old account 

• A provider reverses a mistaken policy block 

• Authentication changes 

If your system treats every 5xx like a dramatic eject button, you’ll slowly shrink your reachable audience over time and wonder why engagement and revenue keep dropping. As an imaginary example: buoncehouse@example.com bounces with “user unknown” and feels like a slam‑dunk permanent failure. It looks like a typo, the mailbox doesn’t exist, case closed. But email addresses are more like apartments than tombstones — people move in and out. Someone could stroll in tomorrow, claim that exact username for whatever reason, and suddenly your “permanent” failure is a very real human, with a very real spam button, and possibly very real, negative opinions about getting your newsletter. 

Saging the house is good, but don’t Konmari your list into oblivion. Even Marie had regrets. 

A deferral (usually 4xx) means: “Not right now.” 

Often this shows up for rate limiting, greylisting, temporary system load, or suspicious behavior that hasn’t crossed a hard threshold yet. 

A block (usually 5xx) means: “Not ever.” 

These are typically tied to reputation failures, authentication problems, policy violations, or nonexistent recipients. 

But here’s where it gets juicy: 

Some providers intentionally use repeated deferrals as a behavior correction tool. Technically they’re saying “you can try again later.” Practically, they’re saying: “Fix your behavior before we let this through. Time heals most wounds, but not this one.” 

The first digit tells you classification, but it’s missing context. 

This is where it gets squishy. 

When a bounce happens, you’re actually making two separate decisions: 

1. Should I retry this specific message? 

2. Should I trust this address in the future? 

Those are not the same thing. A temporary rate limit might mean: retry this message later. It does not automatically mean: this address is guaranteed good for delivery in the future. 

Similarly, a permanent rejection might mean: stop trying this message. It does not always mean: burn this address from your database for eternity. 

If you collapse them into one reflexive reaction, you’ll either retry toxic addresses indefinitely, or suppress recoverable ones. Mailbox providers expect you to understand your audience, and if you don’t even know which addresses are actually alive, that’s not exactly a positive reputation signal. 

Every ESP — including Mailgun — implements bounce handling. At scale, infinite retries are downright dangerous. 

But suppression strategies vary widely across platforms and philosophies: 

• Some suppress aggressively after a small number of soft failures 

• Some let soft bounces decay indefinitely 

• Some retry aggressively 

• Some are extremely conservative. 

Those are risk calculations and not universal truths. Platform logic protects infrastructure, but your list quality? That’s all you! 

One sender’s typo is another sender’s spam trap. 
One sender’s “rate limited” is another sender’s reputation spiral. 

The cleaner your acquisition — especially with confirmed opt-in — the clearer those signals become. 

Even if your ESP is thoughtful, you should still review your own patterns. 

(If you’re a Mailgun customer, you can review how we approach bounce handling and suppression in our documentation. If you’re using another provider, it’s worth asking how they classify and suppress addresses — and what thresholds trigger suppression, if any.) 

Triangulate. Don’t just automate. 

You don’t need the full Encyclopedia Bouncetannica, you just need a better mental model: 

Bounces are evidence, but they’re not the verdict. 

When you see failures, look at: 

• The full response text (policy? spam? rate limit? authentication?).   

• The provider (consumer MBP vs private infrastructure matters) 

• Your recent sending behavior (volume spike? new list? dormant segment reactivation?) 

• The pattern over time (isolated vs trend) 

• Previous behavior for this recipient (did the confirm opt in? Engage previously? How recently? How many emails have you sent without them interacting?) 
   
   

One bounce is a symptom, but a pattern is a diagnosis. 

Chasing delivery without context is like chasing a leprechaun. You can sprint after every “temporary failure” hoping it turns into inbox gold — and end up lost in the woods, yelling at a rainbow, with your sender reputation in shambles. 

Instead: 

✅ Read the whole bounce response, not just the code  

✅ Watch for patterns across time and providers  

✅ Audit your sending behavior  

✅ Separate retry decisions from suppression ones 

✅ Look for what’s driving failures, not just for the impact report 

Because the inbox is not obligated to be consistent. But you are. 

• 4xx vs. 5xx is a guideline, not a guarantee. 

• Retry logic and suppression decisions are different — don’t collapse them. 

• Deferrals can function like blocks when providers use them as behavior correction. 

• Some permanent failures resolve. Some temporary failures never will. 

• ESP bounce logic is prevention but sending behavior is the cure 

• What’s best for your list is usually triangulation, not blind automation. 

Bounce codes aren’t red or green lights; they’re yellow. Like that pot of ROI gold that will be perpetually out of reach if you take bounces at face value. 

March is the perfect time to stop reacting to the number and start understanding the message.