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.
Category: Networking
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
Topics covered: smtp, email, bounces, deliverability, dns, dmarc, suppression, networking, educational, interactive
// simulator
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.
550 5.1.1 <jhon@exmaple.com>: Recipient address rejected: User unknown in virtual mailbox table
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.
Overview
When an email cannot be delivered, the receiving server answers with an SMTP status code and a diagnostic message, and the sender has to decide what to do next. This simulator gives you real bounce messages, with codes and wording modeled on RFC 3463 enhanced status codes and on what major mailbox providers actually send, and asks you to triage each one. The possible actions are to suppress the address, retry later, fix the content, slow down, or stop and investigate. The central lesson is that the first digit of the code is a hint, not the answer. A 550 can mean the mailbox does not exist, which calls for suppression, but it can also mean your content was filtered or your domain failed DMARC authentication, where suppressing recipients only hides a problem on your side. A 4xx can mean greylisting, which a later retry fixes, or "too many messages", which means slow down. Reading the enhanced status code and the diagnostic text is what separates a correct decision from one that either damages your sender reputation by hammering a dead address or throws away a recipient who was only temporarily unavailable.
Try this
- Read the first bounce, choose an action and press "Triage it" to see whether suppress, retry, fix content, slow down or investigate was right.
- Compare the 421 "Too many messages" bounce, which means slow down, with a 550 5.1.1 "User unknown" hard bounce and a 550 5.7.26 DMARC rejection that suppressing recipients would only hide.
- Work through every bounce with "Next bounce", then use "Start over" and try to get them all right on the second run.
Frequently asked questions
- What is the difference between a hard bounce and a soft bounce?
- A hard bounce is a permanent failure, such as a mailbox that does not exist, so the address should be suppressed. A soft bounce is temporary, such as a full mailbox or a busy server, so the message can be retried later.
- Does every 5xx SMTP code mean the address is invalid?
- No. Some providers return 5xx codes for policy blocks, rate limits or content filtering. The enhanced status code and the diagnostic text tell you whether the problem is the address, your content or your sending rate.
- What is an enhanced status code?
- A three-part code such as 5.1.1 defined in RFC 3463. The first part is the class (success, temporary or permanent), the second is the subject (address, mailbox, system, policy and so on) and the third gives the detail.
Try next
// simulator
DNS Resolution Simulator
Learn how DNS works with an interactive step-by-step simulator. Visualize the DNS hierarchy, understand caching at different levels, and see the difference between recursive and iterative queries.
// simulator
Kubernetes Networking / CNI Simulator
Visualize Kubernetes networking and CNI packet paths with an interactive simulator. Learn Pod-to-Pod routing, same-node and cross-node traffic, ClusterIP Services, EndpointSlices, headless Services, LoadBalancer, NodePort, kube-proxy, eBPF service routing, Ingress, NetworkPolicy, and internet egress.
// simulator
SMTP Flow Simulator
Visualize how SMTP email delivery works from app submission through EHLO, STARTTLS, AUTH, MAIL FROM, RCPT TO, DATA, SPF, DKIM, DMARC, recipient MX relay, temporary failures and retries, auth failures, and inbox placement. Sponsored by SMTPfast.