Email bounces and backscatter explained: why misconfigured mail servers amplify abuse
A bounce is a notification a mail server generates when it can't deliver a message, sent back to the message's envelope sender as defined by RFC 5321 and formatted as a Delivery Status Notification per RFC 3464; backscatter happens when a spammer forges that envelope sender as an innocent third party's address, so every bounce a misconfigured receiving server generates lands not on the spammer but on someone who never sent anything at all.
By AdminKit team, Netbase JSC · Updated October 24, 2026
What a bounce is supposed to do
Mail delivery is not guaranteed to succeed on the first attempt — a mailbox may not exist, may be full, or may reject a message outright — and RFC 5321 expects whichever server detects that failure to tell the sender. RFC 3464 standardizes the format of that notification as a Delivery Status Notification (DSN), a machine-readable report of what failed and why, attached to a human-readable explanation. This is ordinary, necessary plumbing: without bounces, a sender would have no way to learn that a message silently failed to reach anyone.
One detail in RFC 5321 matters more than it first appears: Section 4.5.5 requires non-delivery notifications to carry a null reverse-path — an empty MAIL FROM:<> — specifically so a bounce can never itself bounce and start an infinite loop of notifications about notifications. This single rule is why a bounce message, when it does go somewhere wrong, dead-ends rather than cascading.
Where backscatter comes from
A bounce is addressed to the original message’s envelope sender — the address given in the SMTP MAIL FROM command — not necessarily the “From:” header a reader sees in their inbox. SMTP as specified by RFC 5321 places no requirement that the envelope sender be authenticated or even real at the moment a server accepts a message; a spammer can put any address at all in MAIL FROM, including an address belonging to someone who has nothing to do with the spam run.
Backscatter is what happens next: a spam campaign goes out to a large list of addresses, many invalid, all carrying the same forged envelope sender, and every receiving server that accepted a message before realizing the recipient didn’t exist now has to send a bounce — to the forged address, not to the real spammer. One spam run can generate thousands of bounces, all converging on a single innocent victim whose address was simply picked at random as the forged sender. RFC 3834, which sets out recommendations for automatic email responses generally, exists precisely because automated replies sent to an unverified or forged address are a long-standing, documented source of unwanted and sometimes overwhelming mail traffic.
The configuration choice that determines whether a server contributes to the problem
The deciding factor is when a mail server checks whether a recipient actually exists. A server that validates the recipient during the live SMTP conversation — before accepting the message — can simply refuse it on the spot; the failure happens in real time, between the two servers, and no bounce is ever generated because nothing was accepted in the first place. A server that accepts every message up front and only checks mailbox validity afterward has already committed to notifying somebody, and that somebody is whoever the envelope sender claimed to be. This “accept first, bounce later” pattern is almost entirely what turns ordinary bounce-handling into a backscatter source, and it is avoidable: rejecting unknown recipients during the SMTP transaction, a standard and widely supported mail server setting, removes the server from the backscatter problem entirely.
What to do if you’re receiving backscatter
If your domain or address is suddenly flooded with “Undelivered Mail Returned to Sender” notifications for messages you never sent, your address was almost certainly forged as the envelope sender in someone else’s spam run — there’s no configuration fix on your end for a forgery that happened on infrastructure you don’t control, only filtering the resulting flood. A correctly deployed SPF/DKIM/DMARC setup, covered in our SPF, DKIM and DMARC explained guide, makes your domain harder to use as a forged envelope sender in the first place, since a receiving server that checks SPF/DMARC before accepting a message is less likely to accept — and later bounce — mail that falsely claims to be from you. If your own forwarding setup is involved, see our guide on why email forwarding breaks SPF for a related way envelope-sender handling causes authentication failures.
Related checks
Backscatter, blacklisting and forwarding-related authentication failures are three different symptoms of the same underlying SMTP trust gap — the protocol never required the envelope sender to be verified. See why is my IP blacklisted for what happens when a server’s outbound reputation is damaged by abuse like this, and use AdminKit’s MX lookup tool to confirm which servers are actually authoritative for handling a domain’s mail before investigating further.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
What is a bounce message, technically?
When a mail server can't deliver a message — the recipient address doesn't exist, the mailbox is full, content was rejected — RFC 5321 expects the server that detected the failure to notify the sender, and RFC 3464 defines the standard machine-readable format for that notification, a Delivery Status Notification (DSN). Critically, RFC 5321 Section 4.5.5 requires non-delivery notifications to be sent with a 'null reverse-path' (`MAIL FROM:<>`), specifically so that a bounce about a bounce can never trigger an infinite notification loop.
Where does the bounce actually get sent, and why does that matter?
A bounce is sent to the envelope sender of the original message — the address in the SMTP `MAIL FROM` command, which is not necessarily the same as the human-readable 'From:' header a mail client displays. Spam and phishing routinely forge the envelope sender to an address the attacker doesn't control, because SMTP has no built-in requirement that the envelope sender be authentic at the time a message is accepted; whoever's address was forged is who receives the bounce if the message later fails to deliver.
What exactly is backscatter?
Backscatter is the flood of bounce messages that lands on a forged envelope-sender address after a spam run, generated not by the spammer but by the receiving mail servers that accepted the spam and only discovered a delivery problem afterward. A single spam campaign sent to thousands of addresses, many of them invalid, with one forged sender, can generate thousands of bounce notifications — all addressed to a victim who never sent a single message. RFC 3834's recommendations for automatic email responses exist specifically because automated replies and notifications sent to a forged or inappropriate address are a long-documented source of unwanted mail.
Why do some mail servers generate backscatter and others don't?
The difference is when the receiving server checks whether a recipient address is valid. A server that rejects an unknown recipient during the SMTP conversation itself — before accepting the message — never generates a bounce at all, because the sending server (or spam tool) gets the failure immediately and the receiving server never took responsibility for the message. A server that accepts every message first and only checks recipient validity afterward has no choice but to generate a bounce to whatever envelope sender was given, and if that sender was forged, the bounce becomes backscatter. Rejecting at SMTP time, rather than accepting-then-bouncing, is the single configuration choice that eliminates the problem at its source.
How do I know if my domain is a backscatter victim, or a source?
As a victim, a sudden flood of bounce messages ('Undelivered Mail Returned to Sender', 'Mailbox not found') for messages you never sent is the signature — it usually means your domain or a specific address was forged as the envelope sender in a spam run, and there's no fix on your end beyond filtering, since the forgery happened upstream. As a potential source, check whether your own mail server rejects unknown recipients during the SMTP transaction (the correct behavior) or accepts everything and bounces later — the latter configuration makes your server a backscatter generator for anyone whose address gets forged in spam sent toward your domain. A correctly configured SPF/DMARC policy, covered in our SPF/DKIM/DMARC guide, also makes it harder for your own domain to be used as a forged envelope sender in the first place.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.