A DNS blocklist answers in addresses. Ask it about an IP or a domain and it replies with something in 127.0.0.0/8, or with nothing at all. The trap is that the same reply means different things on different zones, and a reader that applies one table to all of them is wrong in both directions: it will hide real listings and invent listings that are not there.
We captured what 37 zones actually return, three rounds each across two independent resolvers, recording every distinct answer. Eight of them do not behave the way a single shared table would predict.
RFC 5782 gives you one universal rule, and it is a handshake
The specification requires every DNS blocklist to list the address 127.0.0.2 and to leave 127.0.0.1 unlisted. That pair is a handshake, not a data point: querying both proves the zone is alive and answering truthfully at the moment you asked.
It also settles what "listed" means in general. Any A record in 127.0.0.0/8 is a listing. Not a match against 127.0.0.2 specifically, which is the single commonest bug in home-grown checkers, because plenty of zones answer with something else entirely.
Everything past this point is a zone declaring an exception to its own codes, which the zone is entitled to do and a reader has to be told about.
The same code means different things on different zones
Here is what our probes actually recorded when asking each zone for the RFC 5782 test entry.
| Zone | Answer to the test entry | What a shared table gets wrong |
|---|---|---|
| Most zones | 127.0.0.2 | nothing |
| DroneBL | 127.0.0.1 | held back as an access code, hiding a real listing |
| Suomispam | 127.0.0.99 | an equality check against 127.0.0.2 reports "not listed" |
| Scientific Spam RHSBL | 127.0.1.2 | same, because the third octet is not zero |
| SURBL Multi | 127.0.0.254 | read as a bitmask it prints six abuse categories at once |
| Mailspike | 127.0.0.10, .11, .12, .13 together | four contradictory reputation labels on one row |
| FMB DBL, NSBL, Short | 188.165.244.8 | outside 127.0.0.0/8 entirely |
Two of these are worth expanding, because they point in opposite directions.
DroneBL's 127.0.0.1 is a real listing. On nearly every other zone that value is an access, test or whitelist code, so the safe default is to hold it back. DroneBL's class identifier is the last octet, and class 1 is its testing class, so the default silently hides everything it says. 0Spam does the same thing, verified against real addresses whose TXT records carry dated abuse evidence.
SURBL's 127.0.0.254 is a listing with no category. SURBL Multi is a summed bitmask, so 4 means one thing, 8 another, and a sum means all of them. Read that way, 254 announces six abuse categories at once. Its own TXT record calls the name a permanent test point, which is a much narrower claim.
An answer outside 127.0.0.0/8 means the zone has stopped
The three FMB zones answered our probes with 188.165.244.8, a routable address. A blocklist only ever answers in 127.0.0.0/8, so a real address here means something else is answering: usually a lapsed domain being wildcarded by a parking provider.
That failure mode is the dangerous one, because it is silent in the direction of "everything is fine". A wildcarded zone answers every query with the same address, so a reader that treats any answer as a listing reports every subject on earth as listed, and a reader that only recognizes 127.0.0.2 reports every subject as clean forever. Neither is a measurement. The correct handling is to call it an unreadable answer, which is neither.
NXDOMAIN is clean, unless the zone is dead
NXDOMAIN means the subject is not on the list. That is the normal, common, correct answer, and most queries return it.
But a zone that has shut down returns NXDOMAIN too, including for its own test entry, and the two are indistinguishable without the handshake. SORBS, which ran for two decades and appears in a great many delisting checklists written before it closed, answered NXDOMAIN for 127.0.0.2 on both resolvers when we asked. A checker still carrying that zone reports a clean result for every address, forever, and the result looks exactly like good news.
This is why the handshake is worth running rather than assuming. A zone that cannot prove it is alive should be reported as unreadable, not counted in a clean total.
A refusal is not a listing, and one of them is invisible
Two of the largest lists refuse queries arriving through open public resolvers, and they refuse in different ways.
Spamhaus publishes an error range at 127.255.x whose values, its operator says, must not be read as the subject being listed. Asked for 127.0.0.2, Spamhaus ZEN returned 127.255.255.254 through one public resolver and NXDOMAIN through another. The first is inside 127.0.0.0/8 and looks like a listing under the general rule. The second looks like clean.
URIBL refuses more legibly: it answers 127.0.0.1 and attaches a TXT record saying the query was refused, naming the resolver's address. That is still a code a naive reader could misfile, but at least the refusal is stated.
Both are why our IP blacklist checker and domain blacklist checker show these lists as direct-check links rather than as rows. A row that can only ever say one thing is not a result, and an unreadable answer is never an absent one. The route out of the biggest of them is the subject of our guide to Spamhaus delisting.
A graded zone answers with a set, not a value
Mailspike returns a reputation level rather than a yes. Its test entry answers in every listing class at once, 127.0.0.10 through .13, and the record order varies between queries.
That breaks two obvious readers. Mapping each record prints four contradictory labels on one row. Reading the first record makes the label flap between runs for the same input. The correct reading is to take the worst grade present, because a reputation is one grade and not a set, and to say plainly when a code is not one the zone documents rather than rounding it to the mildest known value.
Count operators, not rows
"Listed on 4 of 22" reads as four organizations agreeing. Check whether it is. UCEPROTECT publishes three levels that escalate from an address to a netblock to an entire network, and a fourth zone under a different domain name that is delegated to the same nameservers. One complaint against a hosting provider can light four rows on one opinion, which our guide to UCEPROTECT levels covers in full.
The rows still stand on their own, because a network-level listing genuinely is a different fact from an address-level one. The headline is what must not multiply.
How to read your own result
- Check the handshake before the verdict. A zone that cannot answer its own test entry is not telling you anything about you.
- Treat an unreadable answer as unreadable. Not clean, not listed. Absent means publish something; unreadable means something is published and it does not work.
- Read each code against its own zone, including the ones that look universal.
- Look at who lists you, not how many rows. Several rows from one operator is one opinion.
- Check whether the listing is affecting delivery at all before paying anybody. Across the domains we test for the Unspam 2026 Email Deliverability Benchmark, only 0.30% appear on a domain blacklist, so a domain listing is rare enough to be worth confirming before acting on.
The zone with the cleanest handshake of the major lists, and a removal process that states its own timing, is covered in our guide to Barracuda delisting.
To see a blocklist result next to authentication and content, rather than on its own where it is easy to over-read, run a free spam test.
