Bounce Triage Simulator

Read a real SMTP bounce and decide what it is and what to do about it. Twelve genuine failures from Gmail, Outlook, Postfix and Proofpoint: hard bounces, soft bounces, content blocks, rate limits and spam complaints. Learn why the 4xx and 5xx class digit is a hint rather than the answer, which bounces to suppress permanently, which to retry, and what each mistake costs you in lost subscribers or lost sending reputation.

What You Will Learn

How to read an SMTP bounce: the reply code, the enhanced status code, and the diagnostic text
The difference between a hard bounce, a soft bounce, a block, and a spam complaint
Why the 4xx and 5xx class digit is a hint rather than the answer
Which bounces to suppress permanently and which to retry with backoff
Why suppressing a soft bounce quietly costs you real subscribers
Why retrying a hard bounce damages your sending reputation every time
What a 5.7.26 DMARC rejection and a 421 rate limit are really telling you

This interactive simulator requires JavaScript to run. Please enable JavaScript in your browser to use this tool.

// simulator

Bounce Triage Simulator

Supported by

|Become a sponsor

Bounce 1 of 120 correct

To [email protected]via Postfix

550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in virtual mailbox table

What kind of failure is this?

What do you do with it?

About this bounce triage simulator

What you'll learn

How to read a real SMTP bounce without looking anything up
Which failures are permanent and which will deliver on the next try
Why some 5xx responses have nothing to do with the recipient
What each mistake costs: lost subscribers, or lost reputation
Where complaints fit, and why they are weighted so much more heavily

How to read a bounce

The reply code: 4xx is temporary, 5xx is permanent. Treat it as a hint, not a verdict
The enhanced status: 5.1.1 no such mailbox, 4.2.2 over quota, 5.7.x policy or authentication
The diagnostic text: free-form, and usually the part that actually tells you what happened
The address itself: a surprising share of hard bounces are simple typos made at signup

The mistake that costs the most

Both triage errors are expensive, in opposite directions. Suppress a soft bounce and you permanently drop a real subscriber because their mailbox was briefly full. Retry a hard bounce and you damage your sending reputation every single time, because mailbox providers read repeated delivery to a known-dead address as a sign you are working from a purchased list. The 5xx responses that are really about content or rate are where most people go wrong: the 5 looks permanent, so they get filed with the dead addresses and a fixable template problem turns into a shrinking list.

Doing this automatically in production

Nobody triages bounces by hand at volume. In production your provider posts a webhook for each bounce and complaint, and your handler classifies it and writes to a suppression list that the next send checks before it queues anything. The part worth caring about when you choose a provider is whether you get the receiving server's actual response, like the ones in this simulator, or just a category label. "Bounced" is not enough to act on: 550 5.1.1 user unknown and 550 5.7.1 content rejected are the same category and need opposite responses. SMTPfast keeps the full diagnostic next to the message that caused it, and suppression is enforced on send rather than being advisory.

Go deeper

Send an email by hand with raw SMTP walks the conversation these codes come from, one command at a time. The SMTP flow simulator covers the same handshake interactively, and what sending a developer newsletter actually takes covers the suppression list these bounces feed into.

Why learn it this way?

Bounce codes are only memorable once you have been wrong about one.
Every response here is one a real mail server actually sends, wording included.
Reading them quickly is the difference between a list that stays healthy and a sending domain that quietly stops reaching inboxes.