· 7 min read · By Marwene Amor
The short version: On 10 September 2026 we sent 320 DNS queries to the official test points of four blocklists, through Google Public DNS, Cloudflare, Quad9 and OpenDNS, twenty attempts per combination. SURBL and Barracuda answered correctly 20 times out of 20 on every resolver. Spamhaus ZEN answered correctly between 40% and 65% of the time, and Spamhaus DBL between 40% and 75%. The failures return NXDOMAIN, which in DNSBL protocol means not listed. So a blocked query and a clean domain produce the same answer, and no checker can tell them apart.
These are test points that are guaranteed to be listed. 2.0.0.127.zen.spamhaus.org exists so you can prove your setup works; it must return an address. When it returns NXDOMAIN instead, nothing is wrong with the domain you are checking. Something is wrong with your ability to ask.
| Resolver | Blocklist | Correct answer | NXDOMAIN | Reliability |
|---|---|---|---|---|
| Google Public DNS | Spamhaus ZEN | 9 / 20 | 11 | 45% |
| Cloudflare | Spamhaus ZEN | 10 / 20 | 10 | 50% |
| Quad9 | Spamhaus ZEN | 8 / 20 | 12 | 40% |
| OpenDNS | Spamhaus ZEN | 13 / 20 | 7 | 65% |
| Google Public DNS | Spamhaus DBL | 15 / 20 | 5 | 75% |
| Cloudflare | Spamhaus DBL | 11 / 20 | 9 | 55% |
| Quad9 | Spamhaus DBL | 9 / 20 | 11 | 45% |
| OpenDNS | Spamhaus DBL | 8 / 20 | 12 | 40% |
| All four | SURBL multi | 20 / 20 | 0 | 100% |
| All four | Barracuda BRBL | 20 / 20 | 0 | 100% |
That was our first reading, and it is wrong. Watch the same two queries repeated three times, twenty seconds apart, on the same four resolvers:
Google returns a listing on run 2 and nothing on runs 1 and 3. OpenDNS does the reverse. The same resolver, the same query, twenty seconds apart, two different verdicts.
The explanation is the shape of a public resolver. Google, Cloudflare and the others answer from large pools of outbound addresses spread across many locations. Spamhaus blocks queries arriving from open public resolvers, but the block lands on specific addresses, and which address in the pool carries your particular request is not something you control. So the block is real and the result is probabilistic.
A DNSBL has two answers. Listed returns an address inside 127.0.0.0/8. Not listed returns NXDOMAIN. There is no third answer in the protocol, so a query that was refused looks exactly like a domain that is clean.
Spamhaus does publish codes for the error states. 127.255.255.254 means the query came through a public or open resolver. 127.255.255.255 means too many queries. 127.255.255.252 means the blocklist name was mistyped. In four hundred attempts we never once saw any of them. Through a public resolver, the failure arrives as silence.
SURBL publishes an equivalent, 127.0.0.1, which its guidelines describe as your access being blocked. That one is worse in a different way: it sits inside the 127.0.0.0/8 range, so a checker that treats any answer in that range as a hit will report the domain as blacklisted when in fact it was refused service.
Two failure modes, one root cause. A refused Spamhaus query reads as clean. A refused SURBL query can read as blacklisted. Both come from asking through a resolver that is not allowed to ask, and neither is visible on the page showing you the result.
We also queried dnsbl.sorbs.net. Not a domain against it, the zone itself: SOA and NS records. Both returned NXDOMAIN on 10 September 2026. The zone is gone. Proofpoint shut SORBS down in June 2024 after more than two decades.
A checker that still queries SORBS gets NXDOMAIN for every domain on earth and displays it as not listed. It looks like a pass. It is an empty answer from a service that stopped existing two years ago, and it pads the count of lists a tool claims to check.
Query from a resolver you control, on your own network, not through a public one. Then treat a missing answer as unknown, never as clean, and say so in whatever you build. Three states, not two: listed, clean, could not check.
At volume, pay for a licensed feed. The Spamhaus Data Query Service exists precisely because datacenter and public resolvers get refused, and it returns the third state rather than pretending the refusal was an all-clear.
Our deliverability checker runs in your browser, and a browser cannot query a DNSBL at all. We could proxy it through a public resolver and print a verdict. The numbers above are why we do not. The tool reads SPF, DKIM and DMARC, which public DNS answers reliably, and says plainly that blocklist status is not something a web page can tell you.
If a free checker shows you a green tick for Spamhaus, ask what resolver it used. Roughly half the time, it did not get an answer either.
Twenty A-record lookups per resolver and per blocklist, run on 10 September 2026 against each list's own published test point: 2.0.0.127.zen.spamhaus.org, dbltest.com.dbl.spamhaus.org, test.surbl.org.multi.surbl.org and 2.0.0.127.b.barracudacentral.org. Resolvers queried directly by address: 8.8.8.8, 1.1.1.1, 9.9.9.9 and 208.67.222.222. Four second timeout, six second lifetime, one second between rounds. 320 queries in total, plus 80 in the earlier trace runs.
You will get the same shape of result and different exact counts, because the failure is probabilistic rather than fixed.
It does not measure whether any particular domain is actually listed anywhere. It does not test paid data feeds, which is the whole point of paying for one. It does not cover every blocklist, only four, chosen because they are the ones free checkers name most often. And it says nothing about inbox placement, which is a separate question that no DNS query answers.
What it does establish is narrow and checkable: through the four public resolvers most likely to sit behind a free web tool, Spamhaus answers correctly less than half the time, and the other half is indistinguishable from good news.
Spamhaus blocks queries that arrive from open public resolvers, and publishes a specific answer for it, 127.255.255.254, meaning query via public or open resolver. In practice you rarely see that code. Public resolvers run large pools of outbound IP addresses, some of which carry the block and some of which do not, so the same query returns a listing on one attempt and nothing on the next.
In DNSBL protocol, yes, and that is the whole problem. A blocklist answers a listing with an address in the 127.0.0.0/8 range and answers everything else with NXDOMAIN. A refused query also produces no address. A checker cannot tell the two apart, so a blocked query is displayed as a clean result.
In our 320 queries, SURBL multi and Barracuda BRBL answered correctly on 20 attempts out of 20 through all four resolvers, and SpamCop answered correctly in spot checks. Only Spamhaus ZEN and DBL were unreliable, at 40 to 75 percent depending on the resolver and the list.
It means any checker that queries Spamhaus through a public resolver produces a result you cannot rely on, and it produces it silently. It does not mean every checker is broken. Services that pay for the Spamhaus Data Query Service, or that run their own resolver on an address Spamhaus has not blocked, get real answers. The problem is that a web page never tells you which one it is.
Query from your own resolver on your own network, not through a public one, and treat a missing answer as unknown rather than clean. If you need this at any volume, use a licensed feed such as the Spamhaus Data Query Service, which returns a distinct third state for a query it could not complete.
The dnsbl.sorbs.net zone no longer exists. We queried it for SOA and NS records on 10 September 2026 and both returned NXDOMAIN. Proofpoint shut SORBS down in June 2024. Any checker still listing it will report every domain as not listed, forever, and that reads as a pass.
Because it runs in a browser and a browser cannot query a DNSBL at all. Rather than proxy the query through a public resolver and show you an answer that is right about half the time, our deliverability checker reads what DNS can actually tell you, SPF, DKIM and DMARC, and says plainly that blocklist status is not readable from a web page.
Yes, and you should. The method is twenty A-record queries per combination against each list's own published test point, run from four public resolvers. The script is five lines of Python with dnspython and it is printed in full below. Run it and you will get the same shape of result, though not the same exact counts, because the failure is probabilistic.