Backscatterer Blacklist: Two Causes, One Four-Week Clock

A monitoring job turns a row red for Backscatterer, and the team spends the morning auditing a list nobody bought and copy nobody complained about. Neither is the cause. Backscatterer does not look at what you send to prospects at all. It looks at the automated replies your infrastructure sends to strangers, and one of the two behaviours it lists is something an email verification setup does on purpose.

That distinction decides whether the row deserves an hour or a note in a spreadsheet.

What the list is, and who runs it

Backscatterer.org is operated by the UCEPROTECT-Network, which says so on the page banner and again in the licence text for the zone. The service publishes one DNS blocklist, and its home page describes the scope in a single sentence: "Our DNSBL lists any kind of Backscatterer which we see at the UCEPROTECT-Network."

The zone is ips.backscatterer.org, and the operator says it exists "for scoring or rejecting misdirected bounces and misdirected autoresponders and sender callouts from abusive systems".

The next thing the operator publishes is the part most reports strip out. Its usage page carries a warning in capitals that the zone "is NOT a spammerlist. It's a Backscatterer list", and points anybody wanting a spam list at UCEPROTECT instead. A red Backscatterer row is therefore not an accusation of spamming, and treating it as one sends a team looking in the wrong place.

The same page tells receivers how the operator wants the list consumed. Safe mode, in the operator's wording, "means you will do DNSBL-Querys if MAIL FROM: is <> or postmaster only", and the operator says a receiver using it that way "will protect you against misdirected bounces and misdirected autoresponders and sender callouts while you can not lose any real mail". A receiver following that advice only consults the list for null-sender and postmaster traffic, which is bounce traffic. Ordinary mail from your campaign never reaches the query.

Each statement above sits on backscatterer.org's own pages, fetched 2 September 2026.

The two things that get an IP listed

The operator states one listing policy for both causes: "Every IP which backscatters (Sending misdirected bounces or misdirected autoresponders or sender callouts) will be listed the next 4 weeks here."

Misdirected bounces. The operator's own page on the subject sets the rule for a well configured server: "Email servers should be configured to provide Non-Delivery Reports (bounces) to local users only. Unacceptable email from anywhere else should be rejected." A server that accepts a message for a mailbox that does not exist, discovers the problem afterwards, and returns a report to the address in the envelope has sent that report to whoever was forged into it. At spam-run volumes those reports land on strangers, and some of them land on the operator's traps. The receiving side of that experience is worked through in bounces for mail you never sent; this list is about being on the sending side of it.

Sender callouts. This is the cause that catches senders who have never emitted a stray bounce in their lives. A sender callout, also written SAV or sender verify, is the technique of opening an SMTP conversation with somebody else's mail server purely to find out whether an address exists, then dropping the connection. The operator's argument against it starts from the fact that the SMTP command designed for that purpose, VRFY, is disabled almost everywhere, and that disabling it is a statement of policy. It then makes a claim about the technique's value that is worth reading before buying any tool that uses it: "The maximum that your system can test with such an abusive SAV call is whether an emailaddress would accept email from you at the time of connection, after which the answer is out-dated."

That is the operator's own view, and you do not have to agree with the reasoning to care about the consequence. A verification step that probes recipient servers from an address you control can put that address on this list, and it will look for all the world like a deliverability problem caused by your campaign.

1. Step 1A list needs checking

   A tool or a script is pointed at the addresses before a send

2. Step 2It opens a conversation

   It connects to each recipient server and asks whether the mailbox exists

3. Step 3One of those servers is a trap

   The operator runs addresses whose only purpose is to record who probes them

4. Step 4The connecting address is listed

   Not the domain, not the copy, and not because anything was delivered

Finding out which address is actually listed

Two checks answer different questions and both are free.

The operator runs its own lookup, reached from the Test and Remove IP link in its navigation, and that is the authoritative answer because it is the live zone rather than an aggregator's cached row. MXToolbox publishes a problem page for the list, and its description matches the operator's: a listing "indicates that your server is issuing" backscatter in the form of non-delivery reports to external users, "or misdirected autoresponders and sender callouts".

The harder question is whose address to check, and it is a question about your own architecture rather than about the list. If your mail leaves through Google Workspace, Microsoft 365 or a relay, the address that connects to the receiving server belongs to that provider, is shared with an enormous sender population, and is not yours to fix. That whole diagnosis, including the rule that the address to check is the one quoted in a rejection message, is worked through in whose IP a blocklist lookup is checking.

What in your estate could have done this

• ✓Yes: An email verification tool or script that probes recipient servers rather than reading published records
• ✓Yes: A mail server accepting mail for unknown local users and bouncing it afterwards
• ✓Yes: An out of office or vacation autoresponder replying to forged senders
• ✓Yes: A ticketing or helpdesk system that acknowledges every inbound message automatically
• ~Depends: A shared provider address you send through, which you cannot change and did not cause
• ✕No: Your campaign copy, your list source or your sending volume, none of which this list evaluates

Removal, and the two answers on one page

The operator publishes an expiry rather than a queue. Its listing policy says a backscattering address "will be listed the next 4 weeks here", so a listing whose cause has stopped clears on its own. There is no case to argue and nothing to write.

MXToolbox's problem page for the list carries two statements that do not agree with each other, and disclosing that is more useful than picking one. It says the list "does not offer any form of manual request to delist" and that an address "will either automatically expire from listing after a given timeframe, or after time expires from the last receipt of spam into their spamtraps". Further down the same page it says the list "does support a manual request to remove, delist, or expedite your IP Address from their database upon Payment or Donation of fees to their organization". The same page gives MXToolbox's own view of that route in one sentence: "Simply requesting delisting and paying their fee will do nothing to help you correct the problem and will give you no guarantee that you won't get blacklisted again."

Both statements were read on the same page on 2 September 2026. What follows from either of them is the same: the four week clock only starts once the behaviour stops, so the work is finding the system that is doing it.

What a listing is worth to a cold outbound programme

Weight it by what the list tests and by how receivers are told to use it.

The operator asks receivers to consult the zone in safe mode, for null-sender and postmaster traffic only. A receiver doing that cannot reject your campaign on this list, because your campaign does not arrive with a null sender. That is the operator's own recommendation rather than a guarantee about every receiver, and a receiver querying the zone against ordinary mail is doing something the operator advises against. The practical reading is that a Backscatterer row rarely explains a placement problem on its own, which is why it belongs low in the triage order set out in checking and recovering from a blacklisting.

What it is genuinely worth is as a signal about a system you did not know was talking to strangers. Two of the three common causes are configuration rather than campaign work. The third, callout-based verification, is a real choice with a real cost, and the alternative is verification that reads published records and provider signals rather than probing mailboxes. The trade-offs there sit in how the verification tools differ.

The architectural version is shorter than any of the remedies. Outbound leaves on domains and infrastructure kept separate from the corporate estate, so a listing earned by a helpdesk autoresponder cannot reach the mail that matters. One purpose per domain. Verification that does not require probing other people's servers. And enough spare warmed capacity that any single address going bad is a swap rather than an outage, which is the same posture that makes a UCEPROTECT Level 2 listing a note rather than an incident.

The short version

Backscatterer is run by the UCEPROTECT-Network and lists addresses for two behaviours: sending misdirected bounces, autoresponses and sender callouts. The operator states plainly that the zone "is NOT a spammerlist", so the row says nothing about your list, your copy or your volume.

The listing policy is an expiry rather than a queue. The operator publishes four weeks from the last observed behaviour, which means the only work that matters is finding the system producing it. MXToolbox's page for the list contradicts itself on whether a paid expedite exists, and separately recommends against paying for delisting anywhere.

The cause worth checking first is the least obvious one. Callout-based address verification connects to other people's servers to test whether mailboxes exist, and the operator lists addresses that do it. A team can hold a clean list, clean copy and a flat bounce rate and still be listed for a verification step that runs before every send.

Receivers are asked to query the zone only for null-sender and postmaster traffic, so a listing here is a low weight row on a report rather than an explanation for a bad week. Read it as a configuration finding, fix the system, and let the four weeks run.

If you would rather run outbound on infrastructure where verification never probes a stranger's server and a bad address is replaced rather than argued over, we plan the first campaign for free.

The zone name, the listing policy, the four week window, the safe mode definition and the sender callout reasoning are taken from backscatterer.org's own home, usage, bounces and sender callout pages, fetched 2 September 2026. The delisting statements and the view on paying are taken from MXToolbox's Backscatterer problem page, fetched the same day. Verify current list behaviour with the operator before relying on it.