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

When a shared IP address or a customer domain on your platform is listed by Spamhaus, you need to know that list's actual policy, how the listing can escalate, and the exact steps to get it removed. The sections below cover each list in turn.

Blocklists & Spamhaus covers how DNS blocklists (DNSBLs) work, the full tables of zones and return codes, and Spamhaus's guidance for senders.

SBL — Spamhaus Blocklist (127.0.0.2)

A research team working from open-source intelligence (OSINT) maintains the SBL by hand, and 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 take effect quickly.

What gets listed

The SBL lists IP addresses "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: IP addresses that host websites advertised in spam, or resources used by spam and malware operations. The IP address does not need to send mail to be listed.
• 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"), and address scrapers.
• Security threats: command-and-control (C&C) servers for botnets, sites infected with malware, phishing pages, and ransomware infrastructure.

Informational listings exist alongside blocking listings. Spamhaus describes them as "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 listing.

Escalation policy

When a network ignores its listings, Spamhaus extends the listing beyond the abusive IP addresses, to "that network's own infrastructure IP addresses, to extended ranges of that network, or even to that entire network." The triggers are:

• ignoring SBL listings for long periods;
• claiming to remove spammers who keep coming back (moving customers from one IP address to another);
• providing bulletproof hosting;
• persistent spam or security problems.

For an ESP, this is the risk that threatens the whole business. Tolerating one bad customer can turn a listing of a single IP address into a listing of the company's own MX servers, its website, or its entire allocation.

SBL delisting

Only the ISP or network responsible for the listed IP address can ask for removal. End users and ESP customers cannot, and 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, Spamhaus typically expects the provider to terminate or disconnect the server, clear the DNS entries served by the ISP's main DNS servers, clear PTR records, stop MX servers from accepting mail for the customer, and remove the SWIP and rWhois entries. In other words, fully deprovision the customer rather than only suspending its sending.
3. The ISP's abuse or security desk sends a removal request to the SBL Removals Team that describes how the problem was solved. An explanation is required, not just "please delist."

No service level is published beyond "once the abuse issue has been terminated". Investigations may require proof of consent and re-permissioning of the list at fault (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 part of the SBL zone. It targets "IP addresses that are involved in sending low-reputation email", and it watches only SMTP traffic on port 25. It holds 2–4 million listings at any time, with 300,000–400,000 new listings every 24 hours. This is the list that a legitimate but careless ESP customer is most likely to hit.

Detection and granularity

Listings result from "multiple events and heuristics", which Spamhaus does not disclose. The triggers it names are:

• snowshoe operations: static sources of spam spread thinly across IP addresses and domains, which other lists do not catch;
• compromised hosts: insecure installations, misconfigured servers, breached accounts, and exploited content management systems (CMS);
• poor list hygiene: unsolicited mail from senders who manage their subscribers badly.

Granularity: IPv4 /32; IPv6 /64 (following the assignment practice in RFC 4291). Listings of larger IPv6 blocks are aggregated if many /64s in a network misbehave, which is why ESPs that send over IPv6 must separate customers by /64 at a minimum.

Common causes for ESP infrastructure

• a HELO or EHLO name that is not a FQDN (localhost.localdomain, a bare mail);
• missing rDNS, or rDNS that does not match forward DNS (the PTR record must give a hostname that resolves back to the same IP address);
• no IP warm-up, so that cold IP addresses sending volume look like snowshoe senders (see IP Warm-Up);
• customer lists built with single opt-in or kept without hygiene, which hit traps ("use double opt-in to avoid spam traps");
• default settings of control panels (Plesk, cPanel, DirectAdmin) and load balancers that present generic identities, and wildcard DNS.

CSS expiry and delisting

A listing normally expires automatically three days (72 h) after spam was last detected. "In some cases of chronic abuse, the listings can last longer." Because expiry is automatic, the first decision is whether to wait for it or to remove the listing yourself.

Self-removal is done through check.spamhaus.org: "Whatever caused the problem MUST be identified and corrected before removing an IP from CSS." The number of self-removals is limited, and the IP address is listed again immediately if the cause persists. Using up removals without fixing the root cause turns a 72-hour nuisance into a chronic listing. The checker's CSS flow checks the basics from RFC 5321 and 5322 (rDNS, HELO) before it allows removal.

PBL — Policy Blocklist (127.0.0.10 / 127.0.0.11)

The PBL is about policy, not abuse. It lists "end-user IP address ranges which should not be attempting to directly deliver unauthenticated SMTP email to any Internet mail server." A PBL listing does not accuse anyone of spamming. It contains over 1.4 billion IPv4 addresses, roughly 40% of routable IPv4 space, mostly ISP ranges for broadband and dial-up, plus some IPv6 CIDR blocks. The zone is rebuilt every 15 minutes.

The data comes from two sources, told apart by the return code:

Self-service removal

The operator of a mail server on an IP address listed on the PBL can remove a single IP address through the Reputation Checker, if all of these are true:

• the IP address is static (dynamic IP addresses should relay through the ISP's smarthost instead);
• an outbound mail server actually runs on it;
• forward (A) and reverse (PTR) DNS are configured correctly;
• the IP address is assigned to the person or company asking for removal. Requests from freemail addresses (Gmail, Hotmail, Yahoo) are refused, and the request must come from an address on a domain that matches the mail server.

Removal takes effect in about 15 minutes. Exclusions expire after one year, and they are reversed immediately if spam is detected. Removing many IP addresses one at a time gets the exclusions reversed and access revoked, so removals of several ranges must be done by the ISP that owns the space. This matters when an ESP acquires a range that sits inside a PBL block of an access network: ask the upstream provider to exclude the range in its PBL account, instead of removing IP addresses one by one.

For end users behind the PBL, the right fix is not removal at all, but authenticated submission on port 587 or 465 to their provider's smarthost. The PBL affects only delivery made directly to MX servers on port 25.

ISP PBL accounts

Networks manage their own address space with a PBL account. To be eligible, a network needs at least one IPv4 /24 or IPv6 /48 allocation, a primary domain that can be verified in IP-Whois, rWhois or rDNS, a working abuse@ address, and a work email address on the primary domain (or a related one). An account contains Master Ranges (the full allocation), which in turn contain PBL zone listings (the parts actually listed). Changes take effect within 15 minutes. An ESP that runs its own allocation should hold a PBL account, if only to make sure its transactional and sending ranges are excluded, and to list any customer access space it operates.

DBL — Domain Blocklist (127.0.1.x)

The DBL lists domains only: "No IP addresses are listed in the DBL." It has more than about 80 mirrors worldwide. Listings are mostly automated, with manual intervention when needed, and expire automatically once the domain no longer meets the listing criteria. The full table of return codes is in Blocklists & Spamhaus. The key distinction is between codes 127.0.1.2–.6, where the domain itself is bad (spam, phishing, malware, botnet C&C), and codes 127.0.1.102–.106, for abused-legit domains, which are legitimate domains that were compromised and abused.

Listing causes

Spamhaus deliberately does not disclose its criteria ("We do not discuss the specific criteria we use"), but it states these principles of reputation:

• An unknown reputation counts as a poor one. "Reputations are built over time, and building a good reputation takes longer than building a bad one." New sending domains start at a disadvantage (and see ZRD for the first 24 h).
• Anonymity harms reputation (anonymized WHOIS records, hidden operators).
• Domain and IP reputations affect each other. Clean hosting with correct rDNS matters to the domain.
• Snowshoe rotation of domains: many domains that change often are in themselves the signal. "Legitimate mailers invest in durable, long-term infrastructure."
• SPF, DKIM and DMARC do not protect against listing. Spammers authenticate too, and 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)

These are compromised legitimate sites: an outdated CMS or plugins, weak credentials, or poor server security. Where possible, listings target hostnames rather than the whole domain, to avoid blocking the legitimate site. The removal steps Spamhaus prescribes are: take the site offline while you fix it, remove infected files, update the CMS and all plugins and extensions, audit server security, and change all passwords and turn on two-factor authentication (2FA). For an ESP, this is the family of codes to check when the domain of a customer's own website (used in links) is listed but the customer's mail practices look clean.

Query mechanics receivers must respect

• Never query IP addresses against the DBL. An IP query always returns a listing (127.0.1.255), by design, so that a misconfigured filter that rejects mail with links to IP literals fails visibly.
• Wildcarding: the DBL lists domains at the registered-domain level, and every hostname or subdomain under a listed domain returns a listing (www.bank.phish.example.tld matches a listing of example.tld). Lookalike variations of the domain do not match.
• Check at three stages: the rDNS domain of the connecting IP address at connection; the HELO and MAIL FROM domains before DATA; and URLs, header domains and contact addresses when the content is inspected.
• Test points: test.dbl.spamhaus.org returns 127.0.1.2 (the operational test from RFC 5782), dbltest.com.dbl.spamhaus.org returns 127.0.1.2, and anything not listed returns NXDOMAIN.
• Validate the range of the response: only answers within 127.0.1.0/24 are DBL listings. This matters in China, where traffic manipulation by the Golden Shield can alter DNS answers. Any other value means the domain is not listed. (Spamhaus's mirrors in China serve the DBL for IP queries only, so users in China get domain answers from outside the country.)
• The DBL works in RPZ ("DNS firewall") deployments and for filtering spam in blog comments. Microsoft Exchange has no built-in support for domain DNSBLs (third-party products are required).

DBL delisting

• Automatic: most listings expire on their own after the activity that triggered them stops. For a short-lived listing, fixing the cause and waiting is often the whole workflow.
• Manual: use the form in the Reputation Checker. "Using the form does not guarantee removal," and people who ask for removal too often get blocked. Approved removals are processed immediately, within minutes at Spamhaus, but receivers' local copies may lag by up to 24 hours (contact Spamhaus if the domain is still listed 24 h after approval).
• Listing again is automatic if the problem is detected again, so a delisting without a fix to the root cause does not last.
• Delisting is always free.

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

Spamhaus advises these services to check every destination domain against the DBL before creating a short link, and to check again later (after about 1 day and about 1 week). Reject destinations whose A records are on the SBL (and optionally the XBL). Never allow the destination URL to change after the link is created, and do not chain links through other shorteners. Suspend abusive links with a 404 or 410 response (not an interstitial page). Require a CAPTCHA or other bot prevention to create links, consider ZRD to filter out domains that were just registered, and run abuse@ and postmaster@ addresses and feedback loops for the service. An ESP whose shared click-tracking domain is listed on the DBL has usually ignored several of these at once.

Querying the zones correctly (DNSBL usage FAQ)

A receiver, including an ESP that filters its own inbound mail or mail on its platform, must follow these rules:

• Query only ZEN for IP checks: "The subzones of Zen (SBL, XBL, PBL) should not be queried separately," and never combine ZEN queries with queries to the SBL, XBL or PBL. One ZEN answer already carries every code that applies.
• Do not apply DNSBLs to outbound mail, "particularly PBL", because your own smarthost customers legitimately sit in PBL space. Policing outbound mail needs different tools (see Reputation Monitoring).
• Never query through public resolvers (8.8.8.8, Cloudflare, Quad9, resolvers shared by ISP customers) unless the resolver supports EDNS Client Subnet (ECS). The originating network must be identifiable. Queries through anonymous resolvers get the answer 127.255.255.254. Queries from large shared-hosting environments are refused.
• Treat error codes as "do not block": 127.255.255.254 (a query through an anonymous or public resolver), 127.255.255.255 (query volume exceeded) and 127.255.255.252 (a typo in the zone name). A filter that treats these as listings rejects all mail.
• Test from the mail server's own network: dig 2.0.0.127.zen.spamhaus.org +short must return 127.0.0.x, and dig 1.0.0.127.zen.spamhaus.org +short must return NXDOMAIN. The Blocklist Tester at blt.spamhaus.com checks the whole chain by sending test emails.
• Access tiers: the free public mirrors are for small and medium non-commercial organizations within fair use. The DNSBL fair-use policy publishes no hard number, and commercial spam-filter services and ISPs must subscribe whatever their volume. The free DQS tier is limited to "not consistently exceed 100,000 queries per day," for non-commercial use. Above that, use paid DQS or the rsync Data Feed (a local zone transfer, which requires running your own resolver). DQS also carries some datasets available only through it, such as ZRD, HBL and AuthBL.
• Do not automate lookups against check.spamhaus.org. The web checker is for manual use, and automated use gets the querying IP address firewalled.

Delisting workflow summary

All checks and requests start at the IP & Domain Reputation Checker. It is free, needs no account for checking, and automatically evaluates the IP address you visit it from. The live tool is a JavaScript application behind bot protection, and nothing beyond its landing text could be captured ("Do you have problems sending email? … Relax, you're in the right place", from a Wayback snapshot dated 2026-07-09). Its behavior as described above comes from Spamhaus's official blocklist and FAQ pages.

Removal from a Spamhaus zone does not immediately unblock delivery. Receivers refresh their copies on their own schedule (within minutes for users of DQS or ZEN, and up to 24 h for the slowest), and the damage to your reputation at each receiver fades separately.