DNS Blocklists and the Spamhaus Zones

Spamhaus is the most widely consumed reputation provider in email. Mailbox providers such as Comcast, RoadRunner, and Sky use commercial spam filters and reputation data from providers like Cloudmark and Spamhaus; the largest freemail providers (Gmail, Hotmail/Outlook.com, Verizon Media — the former Yahoo and AOL) rely mostly on home-grown filtering built on their own user data, and may or may not combine it with commercial data. Being listed by a widely-adopted reputation provider can therefore block delivery at thousands of receiving networks at once.

There are hundreds of blocklists in the industry, but only a few have broad impact. Any comprehensive blocklist-checking tool (see Deliverability Testing Tools) will show your IP or domain listed somewhere; how seriously to take a listing depends on who issues it. A Spamhaus SBL listing has enormous reach; a listing on a defunct or obscure list can be ignored.

How a DNSBL works

A DNS-based blocklist (DNSBL) publishes listing data as a DNS zone. The receiving mail server checks a connecting IP (or a domain seen during the transaction) by issuing an ordinary DNS A record query:

• IP lists: reverse the octets of the IP and append the zone. To check 192.0.2.99 against ZEN, query 99.2.0.192.zen.spamhaus.org.
• Domain lists: append the domain to the zone, e.g. example.com.dbl.spamhaus.org.

If the IP/domain is not listed, the query returns NXDOMAIN. If it is listed, the query returns one or more addresses in 127.0.0.0/8; the specific return code identifies which dataset listed it and why. A single ZEN query can return several answers in one response packet — one per dataset the IP appears in — which is why querying ZEN is equivalent to (and cheaper than) querying SBL, CSS, XBL and PBL separately.

Receivers use the answer at different stages:

SMTP stage	What is checked	Lists used
Initial connection	Connecting IP; rDNS domain of the connecting IP	ZEN (SBL/CSS/XBL/PBL), DBL
SMTP transaction	HELO string, MAIL FROM domain	DBL, ZRD
Content inspection (after DATA)	Domains/URLs in headers and body, file hashes	DBL, ZRD, HBL

The Spamhaus zones

Zone	Type	Contents
sbl.spamhaus.org	IP	SBL: verified spam sources, spam operations, spam-support infrastructure (includes CSS)
xbl.spamhaus.org	IP	XBL: exploited/compromised systems (malware-infected hosts, open proxies, botnet nodes)
pbl.spamhaus.org	IP	PBL: policy list of IP space that should not be sending direct-to-MX mail (dynamic/residential ranges, IoT)
zen.spamhaus.org	IP	ZEN: SBL + CSS + XBL + PBL in a single query — the recommended IP list
dbl.spamhaus.org	Domain	DBL: domains with poor reputation (spam, phish, malware, botnet C&C, abused-legit)
zrd.spamhaus.org	Domain	ZRD: Zero Reputation Domains — domains observed registered within the last 24 hours
authbl (DQS)	IP	AuthBL: IPs participating in credential-stuffing / brute-force authentication attacks
hbl (DQS)	Hash	HBL: SHA-256/SHA-1 hashes of malware files, cryptowallets, and email/URL artifacts seen in spam

Return codes

A listed query returns one or more of these codes:

Return code	Zone(s)	Meaning
127.0.0.2	sbl, zen	SBL listing (manually investigated spam source/operation)
127.0.0.3	sbl, zen	CSS listing (automated Combined Spam Sources detection)
127.0.0.4	xbl, zen	XBL listing (compromised host)
127.0.0.9	sbl, zen	SBL DROP data (hijacked/leased-to-spammers netblocks; never route)
127.0.0.10	pbl, zen	PBL — range designated by the ISP itself
127.0.0.11	pbl, zen	PBL — range designated by Spamhaus
127.0.0.20	authbl	AuthBL listing
127.0.0.30	sbl, zen	BCL (Botnet Controller List)
127.0.1.2	dbl	Spam domain
127.0.1.4	dbl	Phish domain
127.0.1.5	dbl	Malware domain
127.0.1.6	dbl	Botnet C&C domain
127.0.1.102	dbl	Abused-legit: compromised legitimate site used for spam
127.0.1.103	dbl	Abused-legit: spammed redirector
127.0.1.104	dbl	Abused-legit: phishing on a hacked site
127.0.1.105	dbl	Abused-legit: malware on a hacked site
127.0.1.106	dbl	Abused-legit: botnet C&C on a hacked site
127.0.1.255	dbl	Error: an IP was queried against the DBL (IP queries always return "listed" to flag misuse)
127.0.2.2 – 127.0.2.24	zrd	Domain age in hours since first observation (2–24 h)
127.0.3.2	hbl	Email address seen in spam
127.0.3.10	hbl	Malware file hash
127.0.3.15	hbl	Suspicious file hash
127.0.3.20	hbl	Cryptowallet seen in spam
127.0.3.30	hbl	URL seen in spam
127.255.255.250	any	Error: DQS key disabled
127.255.255.251	any	Error: DQS key illegally used
127.255.255.252	any	Error: typing error in DNSBL name

Any answer in 127.255.255.0/24 is an error signal, not a listing — treat it as "do not block."

Usage terms

Use of the public Spamhaus DNSBL mirrors is free for low-volume, non-commercial users under the DNSBL Fair Use Policy; commercial and high-volume users must use the subscription Data Query Service (DQS). ZEN covers IPs only — it provides no protection against malicious domains, which is what DBL/ZRD are for.

Why senders get listed

For a legitimate sender (as opposed to a compromised host), listings almost always trace back to data problems, not content:

• Spamtrap hits — the strongest signal of poor address acquisition or list hygiene (see spamtrap taxonomy below).
• High complaint volumes at receivers and via feedback loops.
• Sending to purchased, rented, harvested, appended, or co-reg lists. Spamhaus's position, aligned with M3AAWG: "The practice of selling, buying or sending to lists of purchased email addresses – whether B2B, B2C or other categories, is in direct violation of M3AAWG core values." Consent is not transferable; a purchased list can never carry consent.
• High unknown-user rates (hard bounces) — the signature of a stale or fabricated list.
• Bursty, erratic volume that mimics an infected host.
• Compromised infrastructure — a hacked form, an open relay, stolen SMTP credentials (→ XBL/CSS/AuthBL).
• Sending direct-to-MX from dynamic/residential IP space (→ PBL; not an accusation of spamming, just a policy statement about that IP range).
• Brand-new domains sending immediately after registration (→ ZRD for the first 24 hours; a reason to register domains well before first use).

Delisting

All checking and delisting goes through the IP & Domain Reputation Checker at check.spamhaus.org (free, no account required to check; the tool auto-detects and evaluates your client IP on load). It shows which dataset lists you, why, and walks through a troubleshooting/removal flow.

Per-list specifics:

• PBL: self-service removal for end users who legitimately run a mail server on the IP; alternatively route mail through your provider's smarthost. ISP-designated ranges (127.0.0.10) are policy statements by the network owner.
• XBL: self-service after remediating the compromised device/malware. Re-listing follows quickly if the infection persists.
• CSS (127.0.0.3): largely self-resolving automated listings; before requesting removal you must meet the sending best practices of RFC 5321/5322 (valid rDNS, matching HELO, etc.). The checker includes a dedicated CSS troubleshooting step.
• SBL (127.0.0.2): manually investigated; removal requires convincing a Spamhaus researcher the issue is resolved. Investigations frequently demand proof of consent (see data collection below); ISPs and reputation providers may also require a re-permissioning pass of the whole list.
• DBL: listings expire automatically once the domain stops matching listing criteria; manual removal via the checker ("using the form does not guarantee removal"). Approved removals propagate within minutes, up to 24 hours for some mirrors.

Delisting is always free. Spamhaus: "Any offer from anyone to remove any Spamhaus listing for a fee is a scam."

Note that receiver-side blocks referencing Spamhaus (e.g. 554 The IP address of your mail server (…) was found in the Spamhaus blocklist. See https://check.spamhaus.org/) clear on the receiver's schedule after the listing is removed — typically 24–72 hours after the triggering issue ceases.

Spamhaus's deliverability guidance (Deliverability 101)

The Spamhaus "Deliverability 101" eBook is written from the reputation provider's side of the fence. Its core claim matches the foundations of this KB: there is no shortcut — consistently send correctly authenticated, carefully targeted emails to an engaged audience. The sections below capture what it adds beyond the existing articles.

What feeds reputation (in Spamhaus's model)

Reputation is composed of an unknown number of variables that ISPs and reputation providers do not reveal, but the known components are:

Component	Notes
Spamtrap hits	Expose both illegitimate senders and legitimate ones with poor data hygiene
Complaint volumes	Receivers weight complaint counts per IP; thresholds are secret and vary per ISP; good reputation buys slightly more forgiveness
Engagement metrics	Clicks, opens, purchases. Opens/clicks are weaker evidence since Apple Mail Privacy Protection; note Spamhaus itself (and many anti-spam appliances) opens spam and follows non-subscription links, so an open/click is not proof of consent
Bounce / invalid-address management	Unknown-user rate is a primary spammer signature
Consistent mail-stream volumes	ISPs care more about botnet spam than marketing mail; sudden volume changes look like infected hosts. "Bursty" streams degrade even well-established reputation at major freemail ISPs

Key asymmetry, by design and with no override: it is much easier to drive reputation down than to repair it. IP reputation has also become less central than domain and content reputation — IPv6's 340 undecillion addresses mean criminals burn IPs freely, so filters lean on domains. Inbox placement is recalculated exceptionally quickly in response to end-user reactions; treatment can change by the moment. "Whitelisting"/allowlisting by ISPs no longer exists.

Looking legitimate: setup checklist

Intentions matter far less than behavior — spam filters cannot tell a well-meaning sender from a spammer if the behavioral basics are missing:

• Authenticate everything with SPF and DKIM at minimum; keep the SPF record as narrow as possible (designating the whole internet as permitted sender invites abuse). See DMARC for alignment rules.
• Domain strategy for ESP customers, best to worst: (1) delegate a subdomain of the brand's primary domain, e.g. email.customerbrand.com; (2) customerbrand.espdomain.com; (3) last resort, a cousin domain like customerbrand-email.com — if unavoidable it must clearly relate to the brand, since phishing has made users wary of look-alikes.
• Do not use anonymized WHOIS on sending domains; legitimate businesses have no reason to hide identity (registrars that defaulted to privacy post-GDPR will usually unmask on request).
• Limit the number of distinct sending domains; more unique domains sending the same mail raises more flags. Use the primary business domain or its subdomains.
• Every domain that sends email should have functional abuse@ and postmaster@ addresses, plus a working website; link/tracking domains should redirect to the primary business site.
• Use contiguous IPs on the same network where possible; do not use more IPs than needed — hundreds of IPs scattered across networks is the definition of snowshoeing (see Basic IP Allocation).
• ESPs: publish an easy-to-find, enforced AUP/ToS; watch SMTP logs for unexpected bounces, tempfails, and mail-stream anomalies.
• Reputation is established during warm-up, so plan it: select highly-engaged recipients for initial mailings and grow volume based on each previous deployment's results (see IP Warm-Up).

Address acquisition and consent records

Record for every contact, and preserve/update it:

• Date & time of sign-up in UTC
• The channel used to obtain the address
• The IP address that submitted it

If an IP or domain is blocklisted and manual intervention is needed, ISPs and reputation providers often demand this proof of consent; without it, resolution takes longer or fails. It also protects against GDPR-type complaints.

Form rules: opt-in checkboxes must be voluntarily selected (pre-checked boxes are dishonest and illegal in some countries); protect forms with CAPTCHA/reCAPTCHA — since roughly August 2016 there has been escalating bot abuse of unsecured signup forms, poisoning databases (including malicious spamtrap submissions) and amounting to a DoS.

Acquisition methods ranked:

Method	Verdict
Confirmed opt-in (COI/double opt-in)	Gold standard. Confirmation email with a click-to-confirm link; no click → no marketing mail. Provides provable consent, near-zero spamtrap risk, higher engagement
Single opt-in	Workable but risky: uncertainty of intent, typo/bot/throw-away submissions, spamtrap poisoning, higher complaint rates, potential blocklisting
Opt-out	Avoid at all costs — guaranteed high bounces, complaints, spamtrap hits, ISP blocks, and blocklistings. Permission cannot be acquired retrospectively
Purchased/rented lists, harvesting, appending (e-pending), co-reg/affiliate lists	Never. Consent is not transferable; damage is severe and long-lasting

Frequency, engagement, and sunset policy

Set the frequency expectation in the confirmation/welcome message and keep it; unexpected or erratic mail drives spam reports. Spamhaus's example sunset ladder:

1. Recipient hasn't opened in > 1 week → move from weekly to monthly.
2. Hasn't opened in > 1 month → send a "do you wish to continue your subscription?" message with a confirm link.
3. No response → add to the suppression list and stop.

Review engagement continuously and segment out non-engagers; the usual starting cutoff is one year of inactivity, tightening to six months, then three, depending on results. Sending in bulk to addresses that never consented is spam; continually sending to addresses that never successfully delivered is also spam.

The perceived holiday-season "tightening of the rules" by ISPs and reputation vendors is a myth: nothing changes on the receiver side. Senders reaching deep into old/unengaged segments (or buying lists) for holiday revenue trigger the reputation decline themselves — tempfails, deferrals, blocks, and sometimes Spamhaus listings.

Bounce handling

Hard bounce — permanent failure, no retry (5xx). If you get one, never send to that contact again: delete or suppress. Codes frequently seen by senders:

Code	Meaning
550	Non-existent email address (the vast majority of 550s = user unknown)
512	DNS error: recipient's domain does not exist in DNS
551	User not local / invalid address – relay denied
552	Exceeded storage allocation (mailbox full, treated as permanent by some servers)
553	Mailbox name invalid (malformed recipient address)

Most hard bounces in a marketing context are direct results of poor data hygiene; note that non-existent domains can later become spamtraps.

Soft bounce — temporary failure, retry will occur (4xx); the sender's system retries until accepted or timeout (timeout is set on the sending side and varies by network):

Code	Meaning
421	Service unavailable / connection problem — exceeded simultaneous connections, receiver resource shortage, or a reputation dip
450	Mailbox unavailable — corrupted/offline mailbox, or refusal due to reputation/blocklisting
451	Local error in processing
452	Too many emails/recipients, or server storage limit exceeded

Some ISPs respond to reputation dips with tempfails ("421 4.7.0 [TS01] Messages from x.x.x.x temporarily deferred due to user complaints"): mail is deferred until either the flow stops or reputation recovers. Addresses hit by a tempfail should not automatically be removed from the list — fix the list-quality problem instead.

ISP hard block — a policy rejection of the whole stream, usually 554, often carrying a URL to consult (e.g. a Spamhaus reference). Causes: URL/body content blocks, missing authentication, poor IP/domain reputation, or presence on a blocklist the receiver uses. Blocks typically clear over an arbitrary 24–72 hours once the trigger ceases; otherwise resolve the root cause first, then open a ticket with the blocking network. Some ISPs, notably Gmail, have no remediation channel at all — the general receiver escalation pattern is: spam-foldering → tempfailing/throttling → bouncing → hard blocking.

Complaints and feedback loops

Manageable complaint causes: no real sign-up, expectations not set for frequency/content, too much mail or a sudden frequency change, purchased lists, irrelevant content, and mailing after unsubscribe (remove immediately on unsubscribe, regardless of what the applicable law allows as a grace period). Less manageable: recipients who simply don't remember signing up (mail promptly after sign-up — a first email weeks later gets forgotten), point-of-sale collection typos, and frustrated users who mass-report their whole inbox.

Reduce complaints by: keeping the promise made at opt-in; offering a preference center with frequency options; never pre-checking boxes; never buying lists; making unsubscribing trivial (never require a login — illegal in some places; put the link where it's found faster than the spam button, e.g. at the top).

Monitoring data sources: Outlook/Hotmail SNDS (mail volume, deferrals, complaint rates, trap hits per IP), Google Postmaster Tools (complaint volumes and domain reputation), and every available feedback loop (FBL) — ISPs report user spam complaints back to the originating network in ARF (Abuse Reporting Format, PII-redacted); process reports promptly and suppress complainants immediately.

Spamtrap taxonomy

Spamtraps are proof of a data-collection or hygiene problem — fix the process, not the trap. Traps are never revealed by their owners (they're part of the filtering secret sauce, and identified traps just get suppressed by bad actors without fixing anything). Types:

Type	What it is	What hitting it proves
Classic / pristine	Address never given to any live user (often wildcard domains, *@example.com) that starts receiving mail	Fabricated or generated list
Seeded	Addresses deliberately scattered in non-obvious places (e.g. web page source)	Scraping/harvesting, or buying from a scraper; also catches unsubscribe non-compliance
Typo domain	Traps at domains like yaaho.com, ynail.com, homail.com	Point-of-entry typos; contains real mail too, weighted accordingly; COI at collection prevents these
Dead address	Once-valid addresses an ISP turned off, hard-bounced for a period (often 12+ months), then silently reactivated as traps	Ignoring hard bounces / stale lists
Live	Real users' addresses whose unsolicited mail is used for blocking decisions	Sending unsolicited mail; dangerous when the owner has connections
Domain-registration / role (subset of live)	postmaster@, abuse@, admin@ and WHOIS-published addresses	Harvesting; these should almost never be on a marketing list

Legal context (consult counsel — there are email/data-protection laws in at least 77 countries)

• CAN-SPAM (US): federal; FTC has successfully sued violators.
• CASL (Canada): applies if mail goes to a Canadian domain, a Canadian user, or transits Canada.
• GDPR (EU, in force 2018-05-25): covers EU/EEA residents and data transfer out; severe fines; consent records materially reduce exposure.
• CCPA (California, effective 2020-01-01): rights to know, delete, opt out of sale, and non-discrimination; under-16s need opt-in consent (parental for under-13s).