Spamhaus Listings Deep Dive — SBL, CSS, PBL, DBL Policy and Delisting

Companion to Blocklists & Spamhaus, which covers DNSBL mechanics, the full zone/return-code tables, and Spamhaus's sender guidance. This article goes deeper per list: what each list's policy actually is, how listings escalate, and the exact delisting workflow for each — the material an operator needs when a shared IP or customer domain gets listed.

SBL — Spamhaus Blocklist (127.0.0.2)

Manually curated by an OSINT research team; the database averages 30,000–40,000 listings. The zone is rebuilt and reloaded every 5 minutes, 24/7, so both new listings and removals propagate fast.

What gets listed

IPs "under the control of, used by, or made available for use by spammers and abusers in unsolicited bulk email or other types of Internet-based abuse":

• Snowshoe spam ranges — "ranges and domains with poor or frequently changing identification."
• Spam hosting — IPs hosting spam-advertised websites or resources used by spam/malware operations (the listing does not require the IP to emit mail).
• Spam services — bulletproof hosting ("explicit or tacit actions not to disconnect customers who spam"), spamware ("software whose main purpose is to aid in the sending of high volume unsolicited bulk email"), address scrapers.
• Security threats — botnet C&C servers, malware-infected sites, phishing pages, ransomware infrastructure.

Informational listings exist alongside blocking listings: "an early warning signal to indicate that the listed IP is displaying poor behavior. Informational listings are indicative, and do not result in IPs being blocked." Treat one as the last warning before a blocking SBL.

Escalation policy

When a network ignores its listings, Spamhaus widens the listing beyond the abusive IPs — to "that network's own infrastructure IP addresses, to extended ranges of that network, or even to that entire network." Triggers:

• ignoring SBL listings for extended periods;
• claiming to remove spammers who repeatedly reappear (churning customers between IPs);
• providing bulletproof hosting;
• persistent spam or security issues.

For an ESP this is the existential risk: tolerating one bad customer can convert a single-IP listing into a listing of the corporate MX, website, or entire allocation.

SBL delisting

Only the ISP/network responsible for the listed IP can request removal — end users and ESP customers cannot; they must go through their provider. The workflow:

1. Read the SBL listing page (linked from the checker) to understand the specific spam problem.
2. Fix it permanently — for a spammer customer, typical remediation Spamhaus expects: terminate/disconnect the server, clear the DNS entries served by the ISP's main DNS servers, clear PTR records, stop MX servers accepting mail for the customer, remove SWIP'd/rWhois entries (i.e., fully deprovision, not just suspend sending).
3. The ISP's abuse/security desk submits a removal request to the SBL Removals Team describing how the problem was solved — an explanation is required, not just "please delist."

There is no published SLA beyond "once the abuse issue has been terminated"; investigations may demand proof of consent and re-permissioning of the offending list (see Blocklists & Spamhaus). Delisting is always free: "Any offer from anyone to remove any Spamhaus listing for a fee is a scam."

CSS — Combined Spam Sources (127.0.0.3)

CSS is the automated component inside the SBL zone, targeting "IP addresses that are involved in sending low-reputation email." It watches SMTP port-25 traffic exclusively. Scale: 2–4 million listings at any time, with 300,000–400,000 new listings every 24 hours — this is the list a legitimate-but-sloppy ESP customer is most likely to hit.

Detection and granularity

Listings result from "multiple events and heuristics" (undisclosed); the named triggers:

• snowshoe operations — static spam emitters spread thin across IPs/domains, not caught by other lists;
• compromised hosts — insecure installations, misconfigured servers, breached accounts, CMS exploits;
• poor list hygiene — unsolicited mail from senders with weak subscriber management.

Granularity: IPv4 /32; IPv6 /64 (per RFC 4291 assignment practice). Larger IPv6 blocks aggregate if many /64s in a network misbehave — a reason ESPs sending over IPv6 must isolate customers by /64 at minimum.

Common causes for ESP infrastructure

• HELO/EHLO not a FQDN (localhost.localdomain, bare mail);
• missing rDNS, or rDNS that does not match forward DNS (PTR → hostname → same IP round-trip required);
• no IP warm-up — cold IPs emitting volume look like snowshoe (see IP Warm-Up);
• single opt-in / unhygienic customer lists hitting traps ("use double opt-in to avoid spam traps");
• control-panel defaults (Plesk/cPanel/DirectAdmin) and load balancers presenting generic identities; wildcard DNS.

CSS expiry and delisting

Auto-expiry: normally three days (72 h) after the last spam detection; "in some cases of chronic abuse, the listings can last longer." Because expiry is automatic, the first decision is whether to wait it out or self-remove.

Self-removal via check.spamhaus.org: "Whatever caused the problem MUST be identified and corrected before removing an IP from CSS." Self-removals are limited in number and re-listing is immediate if the cause persists — burning removals without a root-cause fix converts a 72-hour nuisance into a chronic listing. The checker's CSS flow verifies RFC 5321/5322 basics (rDNS, HELO) before allowing removal.

PBL — Policy Blocklist (127.0.0.10 / 127.0.0.11)

The PBL is policy, not abuse: "end-user IP address ranges which should not be attempting to directly deliver unauthenticated SMTP email to any Internet mail server." A PBL listing is not an accusation of spamming. It contains over 1.4 billion IPv4 addresses — roughly 40% of routable IPv4 space — mostly ISP broadband/dial-up ranges, plus some IPv6 CIDRs. Zone rebuild: every 15 minutes.

Two data sources, distinguished by return code:

Code	Who listed the range
127.0.0.10	The ISP itself, via a PBL account (authoritative statement about its own space)
127.0.0.11	Spamhaus research — end-user space with high concentrations of botnet zombies

Self-service removal

A mail-server operator on a PBL-listed IP can remove a single IP via the Reputation Checker, if all of:

• the IP is static (dynamic IPs should relay through the ISP smarthost instead);
• an outbound mail server actually runs on it;
• forward (A) and reverse (PTR) DNS are properly configured;
• the IP is assigned to the person/company requesting removal — requests from freemail addresses (Gmail/Hotmail/Yahoo) are refused; the request must come from an address on a domain matching the mail server.

Propagation after removal: ~15 minutes. Constraints: exclusions expire after one year; they are reversed immediately if spam is detected; removing many IPs individually gets the exclusions reversed and access revoked — multi-range removals must be done by the ISP that owns the space (relevant when an ESP acquires a range that sits inside an access-network PBL block: get the upstream to carve it out of their PBL account, don't click through per-IP removals).

The correct fix for end users behind PBL is not removal at all: authenticated submission on port 587/465 to their provider's smarthost. PBL only affects direct-to-MX port-25 delivery.

ISP PBL accounts

Networks manage their own space with a PBL account. Eligibility: at least one IPv4 /24 or IPv6 /48 allocation; a verifiable primary domain in IP-Whois/rWhois/rDNS; a functional abuse@ address; a work email on the primary (or related) domain. Structure: Master Ranges (the full allocation) containing PBL zone listings (the subsets actually listed); edits take effect within 15 minutes. An ESP running its own allocation should hold a PBL account if only to guarantee its transactional/sending ranges are excluded and to list any customer-access space it operates.

DBL — Domain Blocklist (127.0.1.x)

Domains only — "No IP addresses are listed in the DBL." ~80+ mirrors worldwide; listings are mostly automated with manual intervention when needed, and expire automatically once the domain stops matching listing criteria. Full return-code table in Blocklists & Spamhaus; the key split is codes 127.0.1.2–.6 (the domain itself is bad: spam / phish / malware / botnet C&C) versus 127.0.1.102–.106 (abused-legit: a legitimate domain compromised and abused).

Listing causes

Criteria are deliberately undisclosed ("We do not discuss the specific criteria we use"), but the stated reputation principles:

• Unknown reputation defaults to poor — "reputations are built over time, and building a good reputation takes longer than building a bad one." New sending domains start with a handicap (and see ZRD for the first 24 h).
• Anonymity harms reputation (anonymized WHOIS, hidden operators).
• Domain and IP reputations affect each other — clean hosting with proper rDNS matters to the domain.
• Snowshoe domain rotation — many frequently-changing domains is itself the signal; "legitimate mailers invest in durable, long-term infrastructure."
• SPF/DKIM/DMARC do not protect against listing — spammers authenticate too; authentication records alone never justify delisting.
• Spamhaus does not scan websites; listings come from observed traffic — "when we see those signs it means for certain that the website or server is insecure, infected or compromised."

Abused-legit (127.0.1.102–.106)

Compromised legitimate sites: outdated CMS/plugins, weak credentials, poor server security. Listings target hostnames rather than the whole domain where possible, to avoid blocking the legitimate site. Removal steps Spamhaus prescribes: take the site offline while fixing; remove infected files; update CMS and all plugins/extensions; audit server security; change all passwords and enable 2FA. For an ESP this is the code family to check when a customer's own website domain (used in links) is listed but their mail practices look clean.

Query mechanics receivers must respect

• Never query IPs against the DBL — an IP query always returns listed (127.0.1.255), by design, so that a misconfigured filter rejecting mail with IP-literal links fails visibly.
• Wildcarding: DBL lists at the registered-domain level and every hostname/subdomain under it returns listed (www.bank.phish.example.tld matches a listing of example.tld). Lookalike variations of the domain do not match.
• Apply at three stages: connecting IP's rDNS domain at connect; HELO and MAIL FROM domain pre-DATA; URLs, header domains, and contact addresses at content inspection.
• Test points: test.dbl.spamhaus.org → 127.0.1.2 (RFC 5782 operational test); dbltest.com.dbl.spamhaus.org → 127.0.1.2; anything unlisted → NXDOMAIN.
• Validate response ranges: only answers within 127.0.1.0/24 are DBL listings. This matters in China, where Golden Shield traffic manipulation can alter DNS answers — any other value means not listed. (DBL is served IP-query-only from Spamhaus's China mirrors; Chinese users get domain answers from outside.)
• Works in RPZ/"DNS firewall" deployments and for blog-comment spam filtering. Microsoft Exchange has no native domain-DNSBL support (third-party products required).

DBL delisting

• Automatic: most listings expire on their own after the triggering activity stops — for transient listings, fixing the cause and waiting is often the whole workflow.
• Manual: via the Reputation Checker form; "using the form does not guarantee removal," and excessive removal requesters get blocked. Approved removals process immediately — minutes at Spamhaus, but receivers' local copies may lag up to 24 hours (contact Spamhaus if still listed after 24 h post-approval).
• Re-listing is automatic on re-detection; a delisting without a root-cause fix does not stick.
• Free, always.

DBL guidance for URL shorteners / redirectors (ESP click-tracking domains behave identically)

Check every destination domain against the DBL before creating a short link, and re-check later (at ~1 day and ~1 week); reject destinations whose A records sit on SBL (optionally XBL); never allow the destination URL to change after creation; don't chain through other shorteners; suspend abusive links with 404/410 (not an interstitial); gate creation with CAPTCHA/bot prevention; consider ZRD to filter brand-new domains; run abuse@/postmaster@ and feedback loops on the service. An ESP whose shared click-tracking domain gets DBL-listed has usually violated several of these at once.

Querying the zones correctly (DNSBL usage FAQ)

Rules a receiver — including an ESP filtering its own inbound or on-platform mail — must follow:

• Query ZEN only for IP checks: "The subzones of Zen (SBL, XBL, PBL) should not be queried separately," and never combine ZEN with SBL/XBL/PBL queries — one ZEN answer already carries every applicable code.
• Do not apply DNSBLs to outbound mail — "particularly PBL": your own smarthost customers legitimately sit in PBL space. Outbound policing needs different tooling (see Reputation Monitoring).
• Never query via public resolvers (8.8.8.8, Cloudflare, Quad9, ISP shared resolvers) unless the resolver supports ECS; the originating network must be identifiable. Anonymous-resolver queries answer 127.255.255.254. Queries from large shared-hosting environments are refused.
• Handle error codes as "do not block": 127.255.255.254 (anonymous/public-resolver query), 127.255.255.255 (query volume exceeded), 127.255.255.252 (zone-name typo) — a filter that treats these as listings rejects all mail.
• Testing from the mail server's own network: dig 2.0.0.127.zen.spamhaus.org +short must return 127.0.0.x; dig 1.0.0.127.zen.spamhaus.org +short must return NXDOMAIN. The Blocklist Tester at blt.spamhaus.com validates end-to-end by sending test emails.
• Access tiers: free public mirrors are for non-commercial small/medium organizations within fair use (no hard number published in the DNSBL fair-use policy — commercial spam-filter services and ISPs must subscribe regardless of volume). The free DQS tier is capped at "not consistently exceed 100,000 queries per day," non-commercial. Above that: paid DQS or the rsync Data Feed (local zone transfer, requires running your own resolver; DQS additionally carries some exclusive datasets such as ZRD/HBL/AuthBL).
• No automated lookups against check.spamhaus.org — the web checker is for manual use; automation gets the querying IP firewalled.

Delisting workflow summary

List	Code	Who can delist	Mechanism	Timing
SBL	127.0.0.2	The responsible ISP/network only	Fix permanently, then abuse desk writes to SBL Removals Team explaining the fix; proof of consent may be demanded	Zone reloads every 5 min once approved; investigation time varies
CSS	127.0.0.3	Self-service (limited uses)	Fix cause (rDNS/HELO/hygiene), then checker; or wait	Auto-expires ~72 h after last detection; instant re-list if unfixed
XBL	127.0.0.4	Self-service	Remediate malware/compromise, then checker	Fast re-list if infection persists
PBL	127.0.0.10/.11	IP assignee (single IP) or owning ISP (ranges)	Checker (static IP + mail server + matching DNS + non-freemail requester); ISPs via PBL account	~15 min; exclusion expires after 1 year, reversed on spam
DBL	127.0.1.x	Domain owner	Auto-expiry, or checker form (no guarantee)	Immediate on approval; receivers lag up to 24 h

All checks and requests start at the IP & Domain Reputation Checker (free, no account to check; auto-evaluates the visiting IP). The live tool is a JavaScript app behind bot protection and could not be captured beyond its landing copy ("Do you have problems sending email? … Relax, you're in the right place" — via a 2026-07-09 Wayback snapshot); its behavior above is documented from Spamhaus's official blocklist and FAQ pages.

Remember that removal from a Spamhaus zone does not instantly unblock delivery: receivers refresh their copies on their own schedule (minutes for DQS/ZEN users, up to 24 h for laggards), and receiver-side reputation damage decays separately.