When spammers forge your domain as their envelope sender, the bounces come to you. What backscatter is, why it happens, and how to stop causing and receiving it.
One morning your abuse mailbox fills with delivery failure notifications for messages nobody at your company sent, in languages you do not use, advertising products you have never heard of. Nothing was hacked. A spam operation somewhere put your domain in its envelope sender, and every receiving server that accepted a message before deciding to reject it is now dutifully mailing the bounce to you, the forged return address. This is backscatter: the mail system's error handling weaponized by forgery, and it has two sides, receiving it and causing it, each with its own fixes.
The mechanics: accept-then-bounce
SMTP offers two ways to refuse mail. Rejecting during the transaction (a 5xx before accepting DATA) puts the burden on the actual connecting server: a legitimate sender generates its own bounce locally, and a spammer eats the rejection silently. Accepting the message and generating a bounce afterward sends a new message to the envelope sender, whoever that claims to be. Since spammers forge envelope senders as a matter of course, every accept-then-bounce system is a backscatter cannon pointed at innocent domains. The same logic condemns autoresponders and challenge-response systems that reply to unauthenticated mail: any automated response to a forged message is delivered to the forgery victim.
Receiving it: diagnosis and response
A backscatter wave against your domain is evidence of a forgery campaign, not a compromise: check that the bounced originals show sending IPs that are not yours, which the embedded headers usually reveal. The volume is driven by the spammer's campaign size and dies with it, typically days to weeks. DMARC enforcement is the structural mitigation, since receivers that check DMARC reject the forged mail at SMTP time (no acceptance, no bounce), and your aggregate reports will show the campaign as a spike of failing traffic from unknown sources, which is DMARC's reporting loop doing exactly its job. The residue comes from receivers that check nothing, and shrinks every year as enforcement spreads.
Causing it: the audit that keeps you off blocklists
The other side matters more, because causing backscatter is a blocklistable offense: Backscatterer.org exists specifically to list IPs that emit misdirected bounces, and reputation systems score the behaviour. The classic architectural mistake is a perimeter that accepts mail for the whole domain and discovers invalid recipients afterward, a secondary MX or gateway without recipient validation, which converts every dictionary-attack message into a bounce to a forged victim. The fix is recipient validation at the edge: the outermost server that talks to the internet must know the valid address list and reject unknown users during the transaction.
The no-backscatter checklist
- 1
Reject at SMTP time, everywhere
Unknown recipients, policy failures, and spam verdicts all return 5xx during the transaction. Post-acceptance bounces are reserved for genuinely late failures, which good architecture makes rare.
- 2
Validate recipients at the perimeter
Every edge MX, including backups and gateways, checks recipient validity before accepting. A backup MX that accepts everything is the classic backscatter source and the classic spam hole in one.
- 3
Gate every autoresponder on authentication
Out-of-office replies, challenge systems, and ticket acknowledgments respond only to mail that passed authentication checks, and never to bounces (null envelope sender).
- 4
Send your own bounces correctly
DSNs use the null envelope sender (MAIL FROM:<>) so they can never be bounced back, and quote enough of the original for the recipient to identify it without replaying full spam payloads.
- 5
Check your exposure
Verify your sending IPs against Backscatterer.org, and test your own perimeter by attempting delivery to a nonexistent address from outside: a 5xx during the session is the right answer, a bounce afterward is the finding.
Backscatter is a small, old problem that encodes a large principle: in a system where senders can claim any identity, responding to unverified claims makes you the attacker's delivery mechanism. Every fix in this article is a variation on the same move, deciding at the front door instead of apologizing afterward, and the mail architecture that gets this right also greylists better, filters better, and bounces less in general. The front door is where the decisions belong.
Frequently Asked Questions
Does backscatter damage the forged domain's reputation?
We landed on Backscatterer.org. How bad is it?
Why do bounces use the null sender instead of a real address?
Can DMARC eliminate backscatter entirely?
Key Takeaways
- Backscatter is bounce mail delivered to forged senders, generated by accept-then-bounce architectures and autoresponders
- Receiving it means your domain is being forged somewhere; DMARC enforcement shrinks it and reports the campaign
- Causing it is blocklistable: reject at SMTP time and validate recipients at every edge server, including backup MXes
- Filter inbound bounces surgically by matching them to mail you actually sent; never block all DSNs
- Automated responses go only to authenticated mail, and your own bounces use the null sender so they cannot loop
Related articles
DNSSEC for Email Operators: Worth It, and How Not to Break Everything
Every email trust decision resolves through DNS, and DNSSEC is what makes those answers tamper-proof. What it buys email, what DANE requires, and safe operations.
Transactional Latency: Measuring Time-to-Inbox
For OTPs and password resets, seconds are the metric. Where latency hides in the sending path, how to measure time-to-inbox honestly, and what budgets to hold.
Bot Clicks and Link Scanners: Cleaning Your Click Data
Security gateways click every link in every email before humans see them. How scanner traffic pollutes click metrics, breaks one-click flows, and how to filter it.