Why email bounces, and what actually fixes it.
Follow one message from your app to the inbox. Every stop on the way can turn it back, and the reply code that comes back tells you where. Tap a stop to see what it checks.
Select a stop on the route to see what happens there.
Your app signup forms, newsletter tool, receipts
Every problem further down the route starts here: who is on the list, how they got there, and whether the app listens when an address bounces. A list that never drops dead addresses keeps paying for it in reputation.
List hygiene and sunset policiesSending server the MTA: queues, retries, return-path
The mail transfer agent opens the SMTP connection, retries deferred mail and decides where bounces go. The envelope sender it uses (the return-path) is the address every bounce is sent back to.
Return-path, DSNs and VERPDNS checks SPF, DKIM and DMARC
Before trusting the message, the receiver looks you up in DNS. SPF asks whether this IP may send for the envelope domain, DKIM checks a signature, and DMARC asks whether either result lines up with the visible From domain.
SPF, DKIM and DMARCRecipient server the MX that accepts, defers or refuses
Identity only gets you evaluated. The receiving server then weighs your sending history: volume, complaints, spam-trap hits and bounce rate. That reputation decides whether it says 250, 421 or 550.
How sender reputation worksInbox folder placement and complaints
Accepted is not the same as seen. Placement in the inbox or the spam folder, and every press of the spam button, feeds back into the next decision the receiver makes about you.
Feedback loops and complaint ratesBounce (DSN) the way back to the sender
When delivery fails, the answer travels back: either as an SMTP reply in the same session or as a delivery status notification sent to the return-path. The status code inside tells you whether to retry or stop.
SMTP bounce codes explainedDecode a bounce
Paste the status line from a bounce message or your sending log, for example , , or . It is read in your browser only; nothing is sent or stored.
Guides, stop by stop
Grouped by where on the route the problem sits. If you do not know where yet, start with diagnosing a deliverability drop.
Your app
signup forms, newsletter tool, receipts
- List Hygiene and Sunset Policies: Protecting Domain Reputation
An engineering blueprint for automated bounce suppression, double opt-in verification, subscriber sunset workflows, and risk elimination in subscriber database management.
Sending server
the MTA: queues, retries, return-path
- Return-Path, DSNs and VERP: Where Bounces Actually Go
How the envelope sender decides where a bounce is delivered, what a delivery status notification contains, why bounces use an empty sender, and how VERP tells you exactly which recipient failed.
DNS checks
SPF, DKIM and DMARC
- SPF, DKIM, and DMARC: The Mechanics of Email Authentication
A deep dive into RFC 7208, RFC 6376, and RFC 7489, detailing how domain verification protocols function, how alignment is calculated, and why authentication alone cannot guarantee inbox placement.
Recipient server
the MX that accepts, defers or refuses
- Sender Reputation Dynamics: How Mailbox Providers Rate Your Domain
An operational breakdown of IP versus domain reputation, spam trap mechanics, behavioral engagement signals, and volume ramp algorithms enforced by major mailbox providers.
Inbox
folder placement and complaints
- Step-by-Step Guide to Diagnosing a Deliverability Drop
A comprehensive diagnostic protocol for engineering teams: analyzing SMTP bounce logs, verifying authentication alignment, auditing receiver telemetry, and executing targeted remediation.
- Feedback Loops and Spam Complaints: Thresholds and Protocol Requirements
An operational guide to Abuse Reporting Format (ARF), receiver Feedback Loops, Google Postmaster complaint telemetry, and RFC 8058 One-Click Unsubscribe headers.
Bounce (DSN)
the way back to the sender
- SMTP Reply Codes: Deciphering 4xx and 5xx Bounce Signals
A technical analysis of RFC 5321 and RFC 3463 status codes, explaining how receiving servers communicate delivery failure and how MTA loggers should handle transient versus permanent bounces.
Bounces are information
A returned message is the receiving system telling you something precise: the address is gone, the mailbox is full, your signature did not verify, or you are sending faster than it trusts you. Most deliverability trouble comes from not reading those answers, or from reading them and carrying on anyway.