Backscatterer, run by the UCEPROTECT-Network, lists IP addresses observed sending backscatter: bounce messages, autoresponder replies and sender-verification callouts directed at addresses that never sent the original mail. Spammers forge sender addresses; if your server accepts a message to a non-existent recipient and then bounces it to the forged sender, your server has emailed an innocent third party. That is what gets listed.
So the cause is not your campaign. It is your mail server's configuration. Two published facts shape the response: listings expire automatically and free of charge four weeks after the last observed event, and the operator sells an express removal for people who will not wait.
Check it
The zone is ips.backscatterer.org, queried the same way as any DNSBL, with the octets reversed:
dig +short 9.113.0.203.ips.backscatterer.org dig +short -t txt 9.113.0.203.ips.backscatterer.org
Like every RFC 5782-compliant zone, 127.0.0.2 must always answer listed as a handshake that the zone is alive and answering truthfully — do not mistake that for your own result unless you queried your actual sending IP. A real listing returns the same 127.0.0.2 address; the TXT record is where the operator's stated reason lives.
Which behaviour listed you
Three mechanisms account for nearly all listings:
- Accept-then-bounce. Your MTA accepts mail for any address at your domain, discovers later that the recipient does not exist, and generates a bounce to the envelope sender — which was forged.
- Autoresponders without discrimination. Out-of-office and ticket-system auto-replies fired at forged senders of spam your server accepted.
- Sender callouts (callback verification). Your server, when deciding whether to accept inbound mail, connects back to the claimed sender's domain to test whether the address exists. At scale this is indistinguishable from address harvesting, and Backscatterer lists it specifically.
Fix the configuration
- Reject unknown recipients during the SMTP conversation, with a
550atRCPT TO, instead of accepting and bouncing afterwards. This single change eliminates most backscatter. In Postfix terms it means the recipient validation that allowsreject_unlisted_recipientto work; on Exchange it means recipient filtering with tarpitting; any modern MTA supports it. - Do not run a catch-all on a domain that receives any volume of spam. A catch-all guarantees you accept mail you cannot deliver.
- Suppress autoresponders for messages that failed authentication or scored as spam, and never auto-reply to null or forged senders.
- Turn off sender callouts. They were a reasonable idea twenty years ago, they are rude at today's volumes, and they are an explicit listing reason here.
- Check your spam filter's quarantine notifications. Notifying the forged sender that their "message" was quarantined is backscatter wearing a helpful face.
- Rate-limit and authenticate everything that can generate mail, including web forms and ticket systems.
Removal, and the thing to notice about it
Once the behaviour stops, the listing expires on its own four weeks after the last event Backscatterer observed. That is the free path and, for most operators, the correct one: fix the configuration, verify no bounces are leaving for forged senders, and wait.
The operator also offers paid express removal. Treat that offer with the scepticism it has earned. The same network publishes UCEPROTECT's Level 2 and Level 3 lists, which list entire networks and ASNs because of a neighbour's behaviour and then sell removal to the affected bystanders. Paying does not fix your MTA, and it funds a model whose incentive is to list more people.
There is one asymmetry worth knowing if you also *receive* mail: Backscatterer's own guidance is that its data is meant for use at the connection or sender-verification stage, not as a general-purpose inbound DNSBL. Filtering all inbound mail on it will cost you legitimate messages, including ordinary bounces you actually want.
What not to do
- Do not pay for express delisting. Four weeks of a correctly configured server costs nothing; the fee buys a cleared entry and no fix.
- Do not request removal before the configuration change ships. The clock restarts on the next event, so an unfixed server never reaches the four-week mark.
- Do not blame your ESP. This listing is almost always about your *inbound* mail server — the one accepting mail for your domain — not the platform that sends your campaigns.
- Do not use Backscatterer as a blunt inbound filter. Its reach is narrow and its intended use is narrower.
- Do not confuse it with UCEPROTECT Levels 1 to 3. Same operator, different lists, different causes. Being on one says nothing about the others.
Why it matters even though its reach is modest
Backscatter is an outbound mail problem on a server you probably are not watching. If your MTA is bouncing to forged senders, it is also accepting mail it should refuse, generating queue load from spam, and leaking your valid-recipient list through callout responses. The listing is a modest nuisance; the configuration behind it is a real one.
MailPilot focuses on the sending side — warming mailboxes over OAuth or SMTP, verifying SPF, DKIM and DMARC, and measuring per-provider inbox placement daily — so once the inbound configuration is corrected you can confirm that outbound delivery is where it should be.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial