How to check a mail server against blocklists (and why "not checkable" is not "clear")

What a DNS blocklist is

A DNS blocklist (DNSBL, or RBL after the first one) is a list of IP addresses published as a DNS zone. A receiving mail server consults it the moment a connection arrives: it forms a name from the connecting address under the list's zone and asks DNS. An answer means the address is listed, and the server refuses the message, usually with a reply that names the list. No answer means it is not. The whole exchange is one DNS query, which is why every mail server can afford it on every connection, and why a listing bites within minutes.

Two things follow. A blocklist is about an address, not a domain: the address your mail leaves from. And a listing is decided by the list's operator on their evidence and applied by receivers who never see it.

How the lookup works

The name is the address with its four octets reversed, under the zone. For 192.0.2.1 on Spamhaus ZEN it is 1.2.0.192.zen.spamhaus.org. The receiver asks for an A record. If the name does not exist, the address is not on the list. If it does, the answer is an address in 127.0.0.0/8 whose last octets carry the reason, and each list documents its own codes. Many publish a TXT record at the same name too, with the reason or a link.

The four lists hostnag reads

hostnag reads 4 lists on each poll of a mail domain: Spamhaus ZEN, SpamCop, PSBL, UCEPROTECT. Each is consulted by real receivers and documents its answers.

Spamhaus ZEN (zen.spamhaus.org) is the combined Spamhaus zone. One query covers the SBL, addresses with evidence of sending spam; the CSS, addresses with a poor sending reputation; the XBL, hijacked or infected machines; and the PBL, address space whose owner has said should not send mail directly, such as home connections and cloud ranges meant to relay through a provider. The return code says which. A rejection that names a list usually names this one.

SpamCop (bl.spamcop.net) is built from spam that SpamCop's users report and from its own spamtraps. Listings are automatic and short: they expire once reports stop, so a SpamCop listing says something is sending right now.

PSBL (psbl.surriel.com), the Passive Spam Block List, lists addresses that delivered mail to its spamtraps. Only a trap hit lists an address, listings lapse on their own, and removal is self-service.

UCEPROTECT (dnsbl-1.uceprotect.net) is UCEPROTECT's Level 1: single addresses caught by its trap network recently. hostnag does not read Levels 2 and 3, which list whole ranges and networks for their neighbours' behaviour. Level 1 listings expire after a period without new hits; the operator also sells immediate removal, which some receivers hold against the list itself.

SORBS, on every checklist for years, shut its zones in 2024. A query there answers nothing for anyone; a checker that still shows it as clean is reporting on a list that no longer exists.

How an address gets listed

Your own users. A compromised mailbox or a web form with no rate limit sends spam through your server, and its address is listed.

Somebody else on the same address. An office mail server that shares its public address with the office network is listed on the XBL when one infected laptop behind it sends spam directly. A new cloud address arrives with its previous tenant's history.

The address should not be sending. A server on a home connection, or on a cloud range its provider registered with the PBL, is listed for where it is, not for what it did. Relay through the provider's outbound servers or, for a static address you control, ask for removal.

Your legitimate mail hits traps. An old subscriber list holds addresses that died years ago and became spamtraps. A server that accepts a message and bounces it later sends the bounce to a forged sender, which may be a trap. Both look like spam from where the list sits.

Check an address by hand

dig +short 1.2.0.192.zen.spamhaus.org
dig +short txt 1.2.0.192.zen.spamhaus.org

192.0.2.1 is a documentation address (RFC 5737), never assigned to anyone, so the first command prints nothing: not listed. Put your own mail server's address in, reversed. Nothing means not listed. An address from 127.0.0.2 through 127.0.0.11 means listed, and Spamhaus documents which code belongs to which of its zones; the TXT record from the second command says it in words with a link. An answer starting 127.255.255. means the zone declined to answer: .252 a typo in the name, .254 a query through a public resolver (Spamhaus refuses them, 8.8.8.8 and 1.1.1.1 included), .255 too many queries from one place. Run it through a resolver you control.

Getting delisted

Fix the cause before asking for removal, or the address is relisted on the next trap hit. Then each list has a way out. Spamhaus shows the reason on its lookup page and takes removal requests there; a PBL listing on a static address is self-service. SpamCop needs nothing from you: the listing expires once reports stop. PSBL has a removal form. UCEPROTECT Level 1 lapses after its window, or sooner for a fee.

Removal from the public zone is not quite the end. Large receivers often run a local copy of a list on their own refresh schedule, so mail can be refused for a while after the zone clears.

Why not checkable is not clear

The lazy way to read a DNSBL answer is: any A record means listed, anything else means clean. It is wrong both ways, and the second is the dangerous one. A zone that refuses your query answers with an address too, so a checker that only asks "is there an A record" reports a refusal as a listing. A checker that tests for its known codes and calls everything else clean makes the opposite mistake: a refusal, a timeout or a resolver failure becomes a green light, and a listed address reads as clean.

hostnag's rule is narrow on purpose. A zone answers "listed" only with one of its own documented return codes. Every other answer in 127.0.0.0/8, and 127.255.255.x above all, is not checkable, and so is a lookup that did not answer at all. Not checkable raises no finding and is never counted as clean: the Blocklists row, on the monitor page and in the mail check alike, keeps "clean" and "not checkable" as separate counts, and when no list answered the row says so instead of reading normal. A gap in what was learned is shown as a gap.

Why hostnag uses its own resolver for these

A mail monitor lets you name a resolver for its record lookups, MX, SPF, DKIM and DMARC, because those records are yours and reading them from a particular place can be the point. Blocklist lookups never use it: they go through the runner's own resolver every time.

The reason is who is under test. A blocklist answer decides whether you are told your server is listed, and the party being judged must not choose who answers. A resolver you point hostnag at could be made to return "no such name" for every blocklist query: a filtering resolver that blocks DNSBL zones, a resolver on a network that has been taken over, a plain misconfiguration. Every answer would read as clean and nothing would look wrong. With the runner's own resolver, the answer comes from the list through a path you did not pick. In the feature page's words, a customer's resolver could be made to hide a listing.

What the monitor does with a listing

On each poll hostnag resolves the domain's MX hosts to their IPv4 addresses and checks up to 8 of them on all 4 lists; a domain with more sending addresses than that has the rest skipped. A listing is a critical finding, written the way the alert reads it: "203.0.113.10 is listed on Spamhaus ZEN." The alert is "Mail for example.com is at risk", with the finding as its text; when the address clears, a recovery notice says the domain's mail is healthy again.

The mail monitor polls at least daily on every plan (1440 minutes on Free), and as often as every 60 minutes on Pro and every 15 on Business. A listing can land at any hour; the shorter interval turns "a customer told us" into "we told the customer". The blocklist part can be switched off per monitor for a domain whose MX addresses are a provider's, not yours to fix.

Check it now, then watch it

Check it now: paste a mail domain into the mail check to read its MX, SPF, DKIM and DMARC records and see up to 8 sending addresses against Spamhaus ZEN, SpamCop, PSBL, UCEPROTECT.

Watch it for good: mail health monitoring checks up to 8 MX addresses on the 4 lists on its schedule, always with the runner's own resolver, and raises a critical alert on the poll that finds a listing.