Blocklists explained: DNSBLs, Spamhaus, and getting delisted

A blocklist is a published list of IP addresses or domains that some organization believes are sources of spam, and the technical form it takes is surprisingly elegant: it's a DNS zone. Mail servers check whether you're listed by making an ordinary DNS query, the same kind of lookup covered back in DNS for email. There's no central authority behind blocklists and no appeals court, and quality varies wildly from list to list. A handful, led by Spamhaus, genuinely influence whether your mail is accepted. Many others are noise that exists mainly to frighten people.

The mechanics: a list you query with DNS

The scheme is called a DNSBL (DNS-based blocklist). To publish a list, an operator sets up a DNS zone, say zen.spamhaus.org. To check an IP, a mail server reverses the octets of the address (the four dot-separated numbers) and prepends them to the zone name. Checking 203.0.113.7 means looking up 7.113.0.203.zen.spamhaus.org. If the name resolves, the IP is listed; if the query returns nothing, it's clean.

You can watch this work yourself, with one setup caveat. Spamhaus reserves 127.0.0.2 as a permanent test entry:

dig +short 2.0.0.127.zen.spamhaus.org
127.0.0.2
127.0.0.4
127.0.0.10

The caveat: Spamhaus refuses queries that arrive through the big public resolvers, so if your machine uses 8.8.8.8 or 1.1.1.1 (many do), this query returns nothing and looks like a clean answer. Point dig at your ISP's resolver, or use the web lookup at spamhaus.org, before concluding anything.

The answer is itself informative. DNSBL answers live in the reserved 127.x range, and each value is a return code naming a sub-list that matched; the test entry sits on several components at once, which is why several lines come back. IP lists answer in 127.0.0.x; Spamhaus's domain list uses 127.0.1.x codes. Domain blocklists otherwise work the same way with no octet-reversing: to check a domain against Spamhaus's domain list you look up yourdomain.com.dbl.spamhaus.org.

The reason for building it on DNS is speed and scale. A receiving mail server can check every incoming connection against a blocklist in a few milliseconds, cached, using infrastructure that already exists everywhere. When mail arrives at your server, one of the first things that happens, before any content is read, is a round of these lookups.

The Spamhaus family, precisely

Spamhaus is the operator whose lists carry real weight, consulted directly or indirectly by a large share of the world's mail infrastructure, so its lists are worth knowing by name. Each answers a different question.

• SBL (Spamhaus Blocklist) lists IP addresses that Spamhaus researchers have verified as spam sources: spam operations, hijacked address space, and snowshoe ranges (spam spread thinly across many IPs to stay under detection thresholds). A listing here is an accusation with evidence behind it.
• XBL (Exploits Blocklist) lists compromised machines: infected computers, hacked servers, open proxies and other exploited devices observed sending abuse. The owner is usually a victim, not a spammer, but the mail is refused all the same.
• PBL (Policy Blocklist) is the one everyone misreads. It lists IP ranges that should not be sending mail directly to the internet at all, like consumer broadband addresses, as declared by the networks that own them or by Spamhaus policy. It is not an accusation of anything. A home connection is on the PBL because home connections are supposed to relay mail through a proper server, and finding your office IP on it means "route your mail correctly", never "you are a spammer".
• DBL (Domain Blocklist) lists domains rather than IPs: domains seen in spam, phishing campaigns, malware distribution and other abuse. This is the listing that follows your domain to any infrastructure, however clean the IP.
• ZEN is the combined IP zone: one query that covers SBL, XBL and PBL together, with return codes telling you which component matched. It's what most mail servers actually query, which is why the distinction between components matters when you find yourself listed.

Spamhaus documents all of these at spamhaus.org, including a lookup tool where you can check any IP or domain and read the reason for a listing.

How you get listed

Operators feed their lists from a few well-understood sources, and knowing them tells you what to fix.

Spam traps are the classic. A trap is an email address that no human ever owned, or one abandoned so long ago that no legitimate list should still contain it, seeded where scrapers find it or resurrected from dead mailboxes. Nobody can legitimately have that address. Mail arriving there proves the sender scraped, bought a list, or hasn't cleaned theirs in years, and trap operators feed listings directly from hits.

Complaint volume and researcher evidence drive further listings, particularly SBL and DBL. Compromised accounts and machines drive XBL: your WordPress box gets hacked, quietly pumps pharmacy spam for a week, and the IP lands on XBL without you sending a single campaign. And on shared infrastructure you can be listed by proximity, when a pool-mate's behavior gets an IP flagged that your mail also flows through, which we covered in the shared IP lesson.

Getting delisted

Delisting is usually less dramatic than people fear, with one hard rule: fix the cause first. Reputable operators remove listings readily once the underlying problem is gone, and they re-list fast, with less patience, when it isn't.

The shape of the process at Spamhaus: look up your IP or domain in their checker, read the reason, remediate, then request removal through the process the listing page describes. The components behave differently. XBL listings clear once the compromised machine stops emitting abuse, and much of that expiry is automatic. PBL removal is a routing-policy conversation, and the honest fix is usually to send through proper infrastructure instead of insisting the range be excepted. SBL and DBL listings need the actual spam problem addressed and reviewed. Smaller reputable lists follow a similar fix-then-request pattern, some with simple self-service removal.

One warning: never pay for delisting from a list you've never heard of. Reputable operators do not charge to remove you. A list whose business model is fees to get off it is closer to a protection racket than a security service, and the receivers that matter don't consult it anyway.

Which lists matter, and the vanity-list scare

There are hundreds of public DNSBLs. What decides whether a listing hurts you is one question only: do real receivers consult this list when deciding to accept mail? For Spamhaus-class lists the answer is emphatically yes. For a long tail of hobby lists, abandoned zones, aggressive one-person operations and pay-to-delist rackets, the answer is no, and a listing there costs you nothing but sleep.

The scare usually arrives via multi-list checker sites that test an IP against a hundred zones and display alarming red rows. Someone finds their ESP's shared IP flagged on three obscure lists and panics. The best-known example of the pattern is UCEPROTECT, whose Level 3 list flags entire network ranges because of abuse from a few addresses within them, so vast blocks of innocent senders show as "listed" while almost no major mailbox provider treats it as meaningful. Red rows on lists nobody queries are decoration.

This is a place where I want our own tool to be honest about what it does. The free health check checks your domain, and the sending IPs it discovers from your real emails, against an aggregated commercial blocklist feed (Abusix Guardian Mail) covering both IP and domain listings in one pass. That answers "listed or not" decisively; when you need the name of a specific list and the reason behind a listing, the operator lookups above, Spamhaus's first, are the right tool. A monitoring pattern worth knowing: blocklistings are step changes, not drifts, and they're also among the few deliverability problems that are definitively checkable. You never have to wonder. You query, and DNS answers.

You have already seen what the receiving server does with that answer inside the filtering decision. Next: the behaviour side of the ledger, engagement signals, and why your own view of them went dark.

Terms from this lesson

• blocklist - a published list of IPs or domains an operator considers spam sources, which receiving mail servers consult when deciding whether to accept mail.
• DNSBL - a blocklist published as a DNS zone, checked by querying a name built from the IP or domain plus the zone name.
• SBL - the Spamhaus Blocklist: IPs verified by researchers as spam sources.
• XBL - the Spamhaus Exploits Blocklist: compromised machines observed sending abuse, hacked rather than malicious.
• PBL - the Spamhaus Policy Blocklist: IP ranges that shouldn't send mail directly by network policy. A statement about routing, never an accusation.
• DBL - the Spamhaus Domain Blocklist: domains, rather than IPs, seen in spam and phishing.
• ZEN - the combined Spamhaus IP zone covering SBL, XBL and PBL in a single query, and the one most mail servers use.
• spam trap - an address with no legitimate owner, used to catch senders whose lists were never built on real consent.

Check yourself

1. How does a mail server check an IP against a DNSBL?

It downloads the full list nightly and searches itIt emails the blocklist operator and waits for a replyIt queries a DNS name built from the reversed IP plus the blocklist zone, and a resolving answer means listed

2. Your office IP appears on the Spamhaus PBL. What does that mean?

Spamhaus has evidence you are sending spamYour machine has been compromised by malwareYour domain has been seen in phishing campaignsThe IP range is not supposed to send mail directly by network policy; it is a routing statement, not an accusation

3. Which Spamhaus zone combines SBL, XBL and PBL into one query?

ZENSBLDBL

4. You discover a listing on an obscure blocklist that demands a fee for removal. What should you do?

Pay quickly to limit the damageNothing beyond noting it; reputable operators never charge for delisting, and receivers that matter don't consult pay-to-delist zonesRotate to a new sending domain immediately