Back to all experiments

Experiment 003, infrastructure

Our blocklist checker said clean. It was lying.

Every tool we had said our sending domains were fine. We checked by hand, and most of them were on Spamhaus.

The day we checked by hand

One day we ran the Spamhaus domain blocklist query ourselves, one domain at a time, against sending domains that every dashboard showed as healthy.

DomainsDashboardSpamhaus DBL, queried by hand
Our sending domainsCleanMost listed

The dashboard was not wrong on purpose. It was asking a different question, and so was our own first script.

We tested the checkers first

Before checking our own domains, we gave three free blacklist checkers one domain Spamhaus keeps listed on purpose. Two said listed. One said clean. Same domain, same day.

Why a checker can say clean

Spamhaus answers a blocklist query with a code. A listing is one kind of code. But if you ask through a public DNS resolver, or ask too often, it answers with a refusal code instead, and a refusal looks exactly like clean to anything that only checks for a listing.

listed: 127.0.1.x    refused: 127.255.255.254    clean: no answer (only if dbltest.com came back listed)

So every check starts with a control query. dbltest.com is a domain Spamhaus keeps listed on purpose. If that query does not come back listed, nothing else in the run means anything. Our own daily script learned this the hard way: once it flagged a healthy domain as listed because one query in the middle of the run was refused. We fixed it the same day. Tools include ours.

The second surprise

Once we could read the list properly, it did not track delivery either.

DomainHistorySpamhaus
Our most burned domain0.03% reply rate, thousands of sendsClean
A domain that never sent a campaignWarmup onlyListed

A clean listing is not a health signal. A listing is a kill signal. Those are different things, and a checker that reports one green light cannot tell you either.

The list that does not matter

There is a second blocklist, SURBL, that our provider's panel checks. Some of our domains sit on it today; the panel calls everything else clean. We measured what a SURBL listing costs: about one rejected email per 1,000 sends, from a few corporate gateways. Gmail and Microsoft 365 do not use it. So we track it and ignore it.

What we do now

Our own rule, not a vendor's: a Spamhaus listing retires the domain, SURBL does not, and no panel is trusted on its own. Every run starts with the control query. A domain is reused only after a clean Spamhaus answer and a real read of its delivery. No third party tool gets the final word, including the one we wrote.

To be clear: we do not know what caused those listings, and we do not blame our DNS host or our warmup for them. The rule is about reading the list correctly, not about what put us on it.

Try this

Check this domain first: dbltest.com. It is listed on purpose, so any checker that calls it clean is not reading the list. Then paste this into your AI assistant:

Check whether these domains are on the Spamhaus Domain Block List: [your domains]. First query dbltest.com.dbl.spamhaus.org. Spamhaus keeps it listed on purpose, so it must return 127.0.1.2. If it does not, stop and tell me the check is being refused. Do not report anything as clean. Do not use a public DNS resolver like 1.1.1.1 or 8.8.8.8, Spamhaus refuses those. Any 127.0.1.x answer means listed. 127.255.255.x means refused, not clean.

If you use a terminal, the same control query is one line:

dig +short dbltest.com.dbl.spamhaus.org A

If the answer is not 127.0.1.2, your resolver is being refused, and every clean result you have seen from it was a refusal too.

If you want me to check your domains the right way, book a call with me and I’ll look at it with you.

Book a 30 minute call