Spamhaus 127.255.255.254: why your blacklist check lies

If a domain lookup just came back as Spamhaus 127.255.255.254, your domain is probably fine. That code means Spamhaus declined to answer, because the query reached it through a public or open resolver it won't serve. We hit the same wall building our own blocklist monitor, and the refusal turned out to be the easy problem.

Every Sunday at 03:00 UTC, Newsletrix checks each sender domain in the newsletters it has collected against Spamhaus DBL, SURBL and URIBL. Spamhaus and URIBL refused our early checks, which is why our knowledge base has an entry titled "Why are all my Spamhaus and URIBL results errors?" A refusal is annoying, but you can see it. What you can't see is a resolver that hands back a clean answer for a listed domain.

What Spamhaus 127.255.255.254 means

Spamhaus publishes three error codes for its DNS blocklists, all inside 127.255.255.0/24. Its return-codes page, dated February 11, 2021, says it first announced them in late 2019 and started returning them in March 2021.

Code	Spamhaus's description	What it tells you
127.255.255.252	Typing error in DNSBL name	Your zone name is wrong
127.255.255.254	Query via public/open resolver/generic unattributable rDNS	Your resolver is the problem
127.255.255.255	Excessive number of queries	You are over the free-use volume

None of the three says anything about the domain you asked about. Spamhaus states that these codes don't relate to the reputation of the query and that no application should use them to reject mail. Its stated reason for .254 is volume: through a public resolver, Spamhaus can't measure how much any one organisation queries, so it doesn't allow DNSBL queries that way.

Spam filters already know this. SpamAssassin's URI blocklist rules include URIBL_DBL_BLOCKED_OPENDNS, which matches 127.255.255.254, and URIBL_BLOCKED, which matches URIBL's refusal code. Both descriptions open with "ADMINISTRATOR NOTICE". They're addressed to whoever runs the filter, and they say nothing about the sender.

The worse failure: a clean result that isn't

Each list operator keeps a test entry that is always listed. On October 8, 2026, we asked for all three through Google Public DNS, using its DNS-over-HTTPS endpoint at dns.google, and then asked again through a private recursive resolver.

Test query	Google Public DNS	Private resolver
dbltest.com.dbl.spamhaus.org	NXDOMAIN	127.0.1.2
test.uribl.com.multi.uribl.com	127.0.0.1	127.0.0.14
test.surbl.org.multi.surbl.org	127.0.0.254	127.0.0.254

Same questions, different resolver, and two of the three answers flip. The URIBL row is the failure you can see. 127.0.0.1 is URIBL's "query blocked" code, and a checker that treats any 127 answer as a hit reports a listing that doesn't exist. The DBL row is the dangerous one. Spamhaus documents dbltest.com as always answering 127.0.1.2. Through Google it came back NXDOMAIN, which is exactly what a clean domain returns. No error code, nothing to flag, and no reason for a checker to doubt it. Ours wouldn't.

This isn't new. Al Iverson wrote on Spam Resource in November 2021 that Google Public DNS "seems to only give NXDOMAIN responses to Spamhaus query attempts." Five years later, same result. And Spamhaus's return-codes page never mentions NXDOMAIN, so a checker written against that page watches for 127.255.255.254, never sees it through Google, and reports clean.

SURBL answered Google correctly on the day we tested. Don't read that as a rule. SURBL's own documentation says a 127.0.0.1 answer from its public nameservers means your access is blocked, so the same policy can bite there.

So here's where we land. A blacklist check run through a public resolver is worse than no check at all. With no check, you know you don't know. A false clean gives you a green badge for a domain Spamhaus has listed, and you stop looking.

Read Spamhaus 127.255.255.254 and URIBL 127.0.0.1 zone by zone

RFC 5782, the Informational RFC John Levine published in February 2010 to describe how DNS blocklists work, says list answers SHOULD sit in 127.0.0.0/8 so a stray answer can't be used as a real address. That's where the shortcut "any 127 answer means listed" comes from. It breaks now because operators put their error codes in the same range, each in a different place.

Zone	Listing	Refusal or error	Test entry
Spamhaus DBL	127.0.1.2 to 127.0.1.254	127.255.255.252, .254, .255	dbltest.com
URIBL (multi)	Bitmask: 2 black, 4 grey, 8 red	127.0.0.1, query blocked	test.uribl.com
SURBL (multi)	Bitmask: 4 DM, 8 PH, 16 MW, 32 CT, 64 ABUSE, 128 CR	127.0.0.1, access blocked	test.surbl.org

Our monitor's classify() function follows that table. For DBL it counts only 127.0.1.2 through 127.0.1.254 as a listing, and the codes Spamhaus documents in that range run from 127.0.1.2 (spam domain) to 127.0.1.106 (abused legit botnet C&C). For URIBL and SURBL it reads the last octet as a bitmask and treats 127.0.0.1 as a refusal. A genuine listing beats an error when both come back. Any 127 answer it doesn't recognise becomes an error with the raw code attached, which our blacklist screen shows as an amber Error badge.

One trap in the RFC. It says domain lists MUST contain an entry for the reserved name TEST. DBL and SURBL do, and test.dbl.spamhaus.org answered 127.0.1.2 for us. URIBL doesn't: test.multi.uribl.com returned NXDOMAIN, because URIBL's test point is test.uribl.com. Check each list's own documentation before you build a test on the RFC name.

Fix the resolver: run your own, or use Spamhaus DQS

There are two fixes, and each has a cost. The first is a recursive resolver you operate, such as Unbound on the machine that runs the check, so queries reach the list operators from your own IP with proper forward and reverse DNS. That's what Spamhaus asks for. The trap is forwarding. A local Unbound that forwards everything to 8.8.8.8 is still Google asking, and you get Google's answers. It has to resolve recursively from the root. You also take on another daemon to patch, and the public mirrors carry Spamhaus's free-use terms, so read those before pointing a commercial workload at them.

The second is the Spamhaus Data Query Service. You sign up, verify an email address and get a key that goes into the query name. Our monitor switches to it when SPAMHAUS_DQS_KEY is set, and DBL lookups become <domain>.<key>.dbl.dq.spamhaus.net instead of <domain>.dbl.spamhaus.org. The key tells Spamhaus who is asking, which is why DQS isn't subject to the open-resolver block. It's free for non-commercial use by small and medium-sized organisations; a SaaS product checking customer domains is commercial, so budget for it. The key also sits in plain text in every query name, so anyone who can read your resolver logs can read it. Treat it like a password.

Canary-test your blacklist checker before you trust it

The fix for a false clean is to test the resolver path on every run with names whose answers you already know. If the known-listed names don't come back listed, the run tells you nothing.

1. Through the resolver your checker uses, query dbltest.com.dbl.spamhaus.org, test.uribl.com.multi.uribl.com and test.surbl.org.multi.surbl.org.
2. Confirm each answer is a real listing code for its zone: 127.0.1.2 for DBL, a bitmask of 2 or higher for URIBL and SURBL. NXDOMAIN, 127.0.0.1 or anything in 127.255.255.0/24 means the path is broken.
3. Query invalid.dbl.spamhaus.org, invalid.multi.uribl.com and invalid.multi.surbl.org. RFC 5782 forbids listing INVALID, and all three returned NXDOMAIN for us. Any other answer means something is inventing results.
4. If a canary fails, record that zone's results for the run as errors, not as clean.
5. Repeat the canary on each run. Resolver configs drift, and providers change policy.

That's six extra DNS queries per run, the cheapest part of the whole setup.

Where our own monitor falls short

We'd rather say this than have you find it. Our check_domain() function reads NXDOMAIN and empty answers as not listed, and nothing in the monitor runs the canary above. Point it at Google Public DNS and DBL would come back clean for every domain, with no error. What keeps it honest is configuration: the script's own docstring says to set BLACKLIST_DNS_SERVERS to a private recursive resolver, or to set a DQS key. A canary belongs in the code, not in a setup note, and we haven't written it yet.

Two smaller notes. The code maps 127.255.255.253 to an unauthorised-resolver message, but Spamhaus's return-codes page documents only .252, .254 and .255, so treat .253 as unknown if you ever see it. And the check covers domain lists only. A sending IP on an IP blocklist won't show up on our screen, and the knowledge base says so.

Why domain blocklists hit newsletters you thought were clean

Spamhaus describes the DBL as built for two kinds of lookup. URI queries check domains in links inside the message. RHSBL queries check things like rDNS, the HELO string and the From domain. A newsletter carries a lot of link domains: your click-tracking host, a shortener, an affiliate redirect, the sponsor in this week's slot. One listed domain in the body can count against the whole message, even when your sending IP and your own domain are clean.

That's why the DBL code 127.0.1.103, abused spammed redirector domain, matters to newsletter senders. If your ESP's default tracking domain is shared with thousands of other senders, its reputation is partly theirs. Our guide on whether custom click-tracking domains matter for newsletters covers when your own host is worth the setup, and how spam filters score your newsletter shows where a blocklist hit fits among everything else a filter weighs. If mail is already in spam, start with why newsletter emails go to spam. Google Postmaster Tools shows your domain reputation at Gmail, which no blocklist check will.

Blocklists are one input and content is another. Our free spam score checker reads a message the way a content filter does. If you're choosing between pre-send testing and competitor tracking, here's how Newsletrix compares with Litmus.

Before you trust the next green badge, run one query, dbltest.com.dbl.spamhaus.org, through the same resolver your checker uses. If it doesn't come back 127.0.1.2, nothing else that checker told you means anything.

Frequently asked questions

What does 127.255.255.254 mean from Spamhaus?

It means Spamhaus refused the query because it arrived through a public or open resolver, or from generic rDNS that Spamhaus cannot attribute. It is not a listing and says nothing about the domain's reputation. Query through a recursive resolver you operate, or through the Spamhaus Data Query Service (DQS), instead.

Is URIBL 127.0.0.1 a listing?

No. In URIBL's bitmask, 127.0.0.1 means the query was blocked, often because of volume or a shared public resolver. Real listings set higher bits: 2 for black, 4 for grey and 8 for red. SURBL also uses 127.0.0.1 to mean your access is blocked.

Can I check Spamhaus through Google DNS 8.8.8.8?

No. Spamhaus does not allow DNSBL queries through public resolvers. In our test on October 8, 2026, Google Public DNS returned NXDOMAIN for dbltest.com, the domain Spamhaus keeps permanently listed for testing, so a lookup through Google can report a listed domain as clean.

Is Spamhaus DQS free?

Spamhaus offers the Data Query Service free for non-commercial use by small and medium-sized organisations, at query volumes that fit that use. Commercial use, such as a SaaS product checking customer domains, needs a paid subscription. You sign up, verify your email address and receive a key that goes into each query name.

How do I test my blacklist checker?

Query each list's permanent test entry through the same resolver your checker uses: dbltest.com for Spamhaus DBL (expect 127.0.1.2), test.uribl.com for URIBL and test.surbl.org for SURBL. Then query invalid under each zone, which RFC 5782 says must never be listed. If a test entry comes back unlisted, or an invalid name comes back listed, discard that run.

Related reading