Spamhaus Blocklists - SBL, XBL, PBL, CSS, DBL, ZEN

Spamhaus is not one blocklist; it is a family of them, each answering a different question about a piece of mail. Treating “I’m on Spamhaus” as a single condition is the first mistake - the remedy for a PBL listing is the opposite of the remedy for an SBL listing, and the two are not even checked at the same point in the SMTP conversation. This page maps each list to exactly what it catches, the DNS zone you query, its scale, the 127.0.0.x answer it returns, and how you get on and off it. Spamhaus has been at this a long time: “For over 25 years, we have been compiling DNS Blocklists (DNSBLs) to help email administrators filter emails and protect their users,” over a network that “has never been ‘off the air’ or unavailable since its inception in 2001.”

For where blocklists sit in the bigger reputation picture, see the reputation overview and the IP-vs-domain page. For the domain-in-body lists that are not Spamhaus, see SURBL and URIBL; for how the receiving side scores these signals, see spam filtering; and for a wider map of public lists, the DNSBL directory.

The 60-second version

• SBL - manually researched IP sources of spam, snowshoe, and bulletproof hosting. ~30-40K listings. Returns 127.0.0.2.
• CSS - automatically detected low-reputation IP senders; a subset of the SBL zone. 2-4M listings. Returns 127.0.0.3.
• XBL - compromised/exploited IPs (malware, hijacked hosts); built on the CBL. ~2M listings; auto-expires. Returns 127.0.0.4.
• PBL - end-user IP ranges that should never send direct-to-MX. More than 1.4 billion IPv4. Connection-only. Returns 127.0.0.10 (ISP) or 127.0.0.11 (Spamhaus).
• DROP / ASN-DROP - the worst netblocks and ASNs, for firewalls and routers, not just mail. A subset of the SBL; returns 127.0.0.9.
• DBL - domains with poor reputation, used at the content stage. Separate from all the IP lists. Returns 127.0.1.x.
• AuthBL - IPs running bots that abuse stolen or brute-forced SMTP-AUTH credentials; for submission servers. Returns 127.0.0.20.
• ZEN - one query that combines SBL + CSS + XBL + PBL. Does not include DBL.
• Delisting is always free. “Any offer from anyone to remove any Spamhaus listing for a fee is a scam.”

How a DNSBL actually works (RFC 5782)

Every Spamhaus IP list is a DNSBL: a DNS zone where the presence of a record means “listed.” The mechanics are standardised in RFC 5782 (“DNS Blacklists and Whitelists”), and understanding them removes most of the mystery.

To query an IPv4 address, you reverse the octets and append the zone name. To check 192.0.2.99 against zen.spamhaus.org, you look up the A record for 99.2.0.192.zen.spamhaus.org:

# Listed: returns one or more 127.0.0.x answers
$ dig +short 99.2.0.192.zen.spamhaus.org
127.0.0.2

# Not listed: returns NXDOMAIN (the normal case for legitimate mail)
$ dig +short 1.0.0.127.zen.spamhaus.org
# (empty: host not found / NXDOMAIN)

Key rules from RFC 5782 that Spamhaus follows:

• The answer is an A record whose value is a code, not an address. RFC 5782 says the A record “MUST NOT be used as an IP address”; the conventional listed value is 127.0.0.2, and all values “SHOULD be in the 127.0.0.0/8 range.” A TXT record SHOULD carry the human-readable reason and is often used as the SMTP rejection text.
• NXDOMAIN means not listed. “If an IP address is not listed in the DNSxL, there MUST NOT be any records for the address.” So a missing record is a clean result - which is exactly why DNS hijacking and public resolvers break DNSBLs (more below).
• Combined lists pack several sub-lists into one zone. RFC 5782 allows this via bit masks or multiple A records; ZEN uses multiple A records, returning a separate 127.0.0.x answer for each dataset the IP appears on, in a single DNS packet.
• Test entries are mandated. An IPv4 DNSBL “MUST contain an entry for 127.0.0.2” and “MUST NOT contain an entry for 127.0.0.1.” Spamhaus honours this: querying 2.0.0.127.zen.spamhaus.org returns a listing, and 1.0.0.127.zen.spamhaus.org returns NXDOMAIN. Clients SHOULD periodically check these to confirm the zone is live and not wildcarded.
• IPv6 uses 32 reversed nibbles; domain (RHSBL) lists append the domain to the zone (invalid.example.doms.example.net) instead of reversing octets. Spamhaus’s DBL is a domain DNSBL of this kind.

How the lists are applied (the order matters)

Spamhaus describes a pipeline from connection to content: “From the initial connection, where you would query the Spamhaus Blocklist (SBL), Policy Blocklist (PBL), and Exploits Blocklist (XBL), through to the content filtering stage, where the Domain Blocklist (DBL) should be used.” On a hit, the receiving administrator has two choices: “(a) Reject the email in real-time, with an appropriate delivery code, or (b) Accept the message and tag it for additional filtering.” Real-time rejection is preferred because it “creates a delivery status notification (DSN) to the sender identifying the cause of the rejection,” and avoids backscatter.

Stage	Lists queried	Identity checked
Initial SMTP connection	SBL, CSS, XBL, PBL (i.e. ZEN)	Connecting IP
Pre-DATA (HELO / Mail From)	DBL	Envelope/HELO domain
Content (post-DATA)	DBL (and SBL/CSS/XBL on URL IPs)	Domains and IPs in the body
Submission (port 587/465)	AuthBL	Connecting/authenticating IP

A hard constraint to internalise before anything else: the PBL must be checked only against the connecting IP at the initial connection. Using it against header or body content “will result in rejecting non-spam mail for most servers.”

The IP blocklists

SBL - Spamhaus Blocklist

The flagship IP list. “The Spamhaus Blocklist contains IP addresses that have been identified as malicious. These IPs are being observed in adversarial activity, e.g. sending spam, snowshoe spamming, hosting malicious content, behaving like a bulletproof hosting company or hijacking IP space. Both individual IPs and IP ranges are provided.”

• Zone: sbl.spamhaus.org · Return code: 127.0.0.2
• Scale: “On average, this dataset contains 30-40 thousand listings.”
• Maintained by: a human OSINT research team (investigators and forensics specialists) - this is a manually curated list, which is what gives an SBL listing its weight.
• Update cadence: the zone refreshes “Every 5 minutes, 24/7,” distributed across “over 80 public DNSBL mirror servers.”
• Definition of spam used: “‘Spam’ is defined as ‘unsolicited bulk email’ (UBE). Spamhaus does not evaluate the content or legality of the contents of an email message, merely whether that message constitutes spam by this definition.”

SBL listing categories include snowshoe spam, spam hosting, bulletproof hosting, spamware, scrapers, botnet controllers, malware/phish/ransomware hosting, and hacking attempts.

Spamhaus also issues informational listings as an early warning: “Informational listings act 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. However, without further action, a SBL listing ‘proper’ could be made.”

And the SBL can escalate. “When a network appears to Spamhaus to be a threat or hazard… Spamhaus may apply escalated SBL listings to that network’s own infrastructure IP addresses, to extended ranges of that network, or even to that entire network or networks related by ASN or RIR assignment.” Triggers include ignoring SBL notifications for a significant period, the repeated re-appearance of removed spammers, and bulletproof-hosting patterns. This escalation is the mechanism behind the DROP lists below.

DROP, ASN-DROP (and the retired eDROP)

DROP is the sharp end of the SBL. “Don’t Route Or Peer (DROP) lists the worst of the worst IP traffic. It is an advisory ‘drop all traffic’” list, and it is “a subset of the Spamhaus Blocklist (SBL), designed for a total protection from all the activity involving the listed networks over all the Internet protocols” - not just mail. It is meant for “Tier-1 and backbone providers in firewalls and routing equipment.”

• What it lists: “netblocks that are leased or stolen by professional spam or cyber-crime operations, and used for dissemination of malware, trojan downloaders, botnet controllers, or other kinds of malicious activity.”
• How a netblock gets there: only “after dedicated investigators and forensics specialists have gathered evidence that they are controlled by cybercrime groups or by ‘bulletproof’ hosters.” False positives are “extremely low, given the high confidence nature of this dataset,” and “IP address space under the control of any legitimate network will never be listed.”
• The files: drop_v4.json, drop_v6.json, and asndrop.json (the JSON format; the legacy text files are being deprecated). ASN-DROP “contains autonomous system numbers (ASNs) that are hijacked or leased by professional spam or cyber-crime operations.”
• eDROP is gone: “eDROP data was combined into the DROP list on 10 April 2024.” Configure for DROP alone; the historical EDROP (sub-allocations not directly allocated) is no longer a separate file.
• In DNS: “All the networks listed in DROP are also listed in the SBL list,” and a 127.0.0.9 answer (returned in addition to 127.0.0.2, a convention in place since 1 June 2016) flags a DROP range on an SBL/ZEN lookup.
• Removal: automatic - “Once the SBL record is removed, the ranges will automatically leave DROP also.”
• Fetch politely: “Please DO NOT auto-fetch the DROP list more than once per hour” - once per day is plenty for most networks, and “excessive downloads may result in your IP being firewalled from the Spamhaus website.”

ROKSO - the Register of Known Spam Operations

ROKSO is not a DNSBL; it is the dossier behind the manual SBL listings. Historically it was a “3 strikes” register of hard-line professional spam operations that had been “thrown off Internet Service Providers 3 times or more for spamming,” used by ISP abuse desks to vet prospective customers and by Spamhaus to follow a gang’s infrastructure as it moves between IPs and ASNs - which is why the DROP FAQ notes that “many of these hijacked netblocks find their way into a ROKSO record.” Important status note: the public register has been retired. Per Spamhaus’s current FAQ, “the Register of Known Spam Operations (ROKSO) is no longer available to the public. However, a new attribution mechanism is under development, which will serve a similar purpose to ROKSO but won’t be a direct replacement.”

CSS - Combined Spam Sources

The automated cousin of the SBL. “The Spamhaus CSS list is an automatically produced dataset of IP addresses that are involved in sending low-reputation email. CSS mostly targets static spam emitters that are not covered in the Policy Blocklist (PBL) or Exploits Blocklist (XBL), such as snowshoe spam operations, but may also include other senders that display a risk to our users, such as compromised hosts.”

• Zone: CSS is a subset of the SBL zone - querying sbl.spamhaus.org also returns CSS listings. · Return code: 127.0.0.3
• Scale: “Normally contains between 2 and 4 million listings, with 300,000 to 400,000 new listings added every 24 hours.”
• Scope: “dedicated to SMTP traffic, only listing port-25 based detections.” Both “IPv4 (/32) and IPv6 (/64) addresses are listed.”
• Triggers: “unsolicited emails, having poor email marketing list hygiene, or sending out malicious emails due to compromised accounts or content management systems (CMS).”

The key difference from SBL: CSS is fully automated, where SBL “proper” is manually researched. A legitimate sender with poor list hygiene is far more likely to land on CSS than on the manually curated SBL - so for ordinary marketing or transactional senders, CSS is the Spamhaus list you are most likely to trip.

XBL - Exploits Blocklist (and the CBL lineage)

Compromised machines, not deliberate spammers. “The Exploits Blocklist contains individual IPv4 and IPv6 addresses exhibiting signs of compromise i.e. IPs that are legitimate but have been hijacked to use by third-party exploits.”

• Zone: xbl.spamhaus.org (also folded into ZEN). · Return code: 127.0.0.4
• The CBL heritage: Spamhaus’s own return-code documentation labels the 127.0.0.4 answer as “CBL Data.” The XBL is built on the Composite Blocking List (CBL) detection engine - the historical automated exploit/botnet list whose data the XBL distributes. (Codes 127.0.0.5 through .7 are reserved to the XBL for future use.)
• Scale: “On average contains 2 million listings, with 650,000 new detections relating to exploited IPs every 24 hours.”
• Auto-expiry: “XBL listings will automatically expire after a period of time once the malicious behavior is no longer detected” - so cleaning the compromise resolves the listing without a manual request.
• Triggers: malware on the device, “free VPN” apps using the device as a proxy, brute-force participation, rapid identity changes while delivering mail, sinkhole connections, and relay attempts using stolen credentials.

AuthBL - Authentication Blocklist

A specialised XBL subset, aimed not at the inbound MX but at the submission server. AuthBL is a list of “IP addresses known to host bots using stolen credentials or brute-forcing SMTP-AUTH (and other authentication protocols), helping detect and mitigate ongoing abuse from malicious login attempts.”

• Return code: 127.0.0.20 (available via Spamhaus Technology’s Data Query Service; the free DQS tier includes AuthBL and ZRD).
• Where it belongs: “AuthBL is primarily designed for use by anyone operating a submission SMTP server” (ports 587/465). “If one of your customers gets their credentials stolen, AuthBL greatly mitigates the ability of botnets to abuse the account, and keeps your MTAs safe from collateral damage.”
• How to use it carefully: because “AuthBL is a XBL subset,” Spamhaus warns that “outright blocking listed IPs attempting to submit mail may generate false positives.” Either block while monitoring closely and contacting affected customers, or add points in a scoring system.

PBL - Policy Blocklist

The most misunderstood list, because it is not about abuse at all. “The Policy Blocklist is a dataset containing end-user IP address ranges from which email should never be sent directly to the final destination.” And explicitly: “The IPs in this dataset are not necessarily ‘bad’ - simply, they should never be sending email.”

• Zone: pbl.spamhaus.org (also in ZEN). · Return codes: 127.0.0.10 (entry maintained by the ISP) and 127.0.0.11 (entry maintained by Spamhaus).
• Scale: “More than 1.4 billion IPv4s, corresponding to almost 40% of the routable IPv4 space.”
• The rule: mail from a PBL-listed IP “is expected to be submitted - using authentication - to a SMTP server which delivers it to destination.”
• Hard usage constraint: the PBL “MUST be used ONLY against the connecting IP in the initial SMTP connection.” Spamhaus is blunt about the web-application case too: “Do not block users using IP addresses listed on the PBL from accessing Web-based applications. The PBL is not a list of ‘spamming IP addresses’.”
• Data quality: much of it is network-owner-maintained - “Networks directly add and maintain many of these ranges, resulting in strong data efficacy.”

If you are PBL-listed, the fix is not a cleaner IP - it is to send through an authenticated submission server instead of direct-to-MX. End users can self-remove via check.spamhaus.org where their IP’s policy permits it, but the proper architecture avoids the listing entirely. Spamhaus’s own advice to ISPs is to “limit port 25 outbound access to mail servers only” - which “basically achieves the same result of PBL, but in a cleaner way.”

The domain side

DBL - Domain Blocklist

Spamhaus’s domain-based list, and the one that catches what IP lists miss. “The Domain Blocklist covers any domain indicating signs of spam or malicious activity. It includes domains owned by bad actors, or hijacked domains otherwise used for legitimate purposes.” It is “a list of domain names with poor reputation… Domain reputation is calculated from a wide range of observed domain behaviors… including phishing, fraud, malware distribution, and those with poor reputation based on a broad range of heuristics.”

• Zone: dbl.spamhaus.org · Return codes: the 127.0.1.x range (see the table below). “The DBL ONLY lists domains. The DBL should never be used to query for IP addresses” - an IP query returns the error code 127.0.1.255.
• Why it exists: “If you are only filtering email using IP-based data, you are missing a simple, yet highly effective, step to increase your catch rates.” The DBL catches actors who use clean IPs but abusive domains.
• Proactive: “suspicious activity can be identified before being seen in the wild, making this a highly proactive dataset.”
• Where it is applied: against the rDNS domain of the connecting IP at connection; against the HELO string and Mail From domain pre-DATA; and against domains in headers, body URLs, and contact addresses during content inspection. It can also be used as an RHSBL for the right-hand side of email addresses.

ZRD - Zero Reputation Domains

A companion to the DBL that lists domains purely by age. Brand-new domains have no track record, and spammers register them in bulk; ZRD returns a 127.0.2.x code that encodes how recently the domain was first seen (e.g. 127.0.2.2 = first seen 0-2 hours ago, stepping up to 127.0.2.24 = 23-24 hours ago). It is a DQS dataset, included in the free tier, and is queried like the DBL (append the domain, never reverse an IP).

ZEN - the combined query

ZEN exists for efficiency. “ZEN is the combination of all Spamhaus’ free IP-based DNSBLs into one single powerful and comprehensive blocklist to make querying faster and simpler. It contains the SBL, CSS, XBL, and PBL blocklists.” A single ZEN query returns one DNS packet with a distinct return code per dataset the IP appears on. Spamhaus: “If you are using ZEN, in most configurations there is no need, or additional benefit, to also query other Spamhaus IP blocklists,” and “the subzones of Zen (SBL, XBL, PBL) should not be queried separately.”

So a query for one IP can return several answers at once. Spamhaus’s documented example for a heavily abusive IP returns four A records - 127.0.0.2 (SBL), 127.0.0.3 (CSS), 127.0.0.9 (DROP range), and 127.0.0.4 (XBL/CBL) - meaning your filter must be able to parse multiple 127.0.0.x codes, not just test for “any record.”

The trap to avoid: ZEN does not include the DBL. “Due to its IP nature, ZEN does not provide any protection against malicious or suspicious domains.” The DBL must be queried separately. (Fun fact from Spamhaus: ZEN “was named after Spamhaus’ founder, Steve Linford’s German Shepherd, Zen.”)

The return codes (127.0.0.x and beyond)

Spamhaus encodes which dataset matched in the A record value, following a simple block convention:

Range	Meaning
127.0.0.0/24	Spamhaus IP blocklists
127.0.1.0/24	Spamhaus domain blocklists (DBL)
127.0.2.0/24	Zero Reputation Domains (ZRD)
127.255.255.0/24	Errors - never a “listed” answer

The IP-zone codes (returned by zen.spamhaus.org and its subzones):

Code	Zone	Meaning
127.0.0.2	SBL	Listed in the SBL
127.0.0.3	SBL	Listed in CSS (a subset of SBL)
127.0.0.4	XBL	Listed in the XBL (CBL data)
127.0.0.9	SBL	In a DROP range (returned in addition to 127.0.0.2)
127.0.0.10	PBL	PBL entry maintained by the ISP
127.0.0.11	PBL	PBL entry maintained by Spamhaus
127.0.0.20	AuthBL	Listed in AuthBL (DQS)
127.0.0.30	BCL	Listed in the Botnet Controller List (DQS)

The DBL domain codes (dbl.spamhaus.org, 127.0.1.x):

Code	Meaning
127.0.1.2	Low-reputation domain
127.0.1.4	Phishing-related domain
127.0.1.5	Malware-related domain
127.0.1.6	Botnet C&C domain
127.0.1.102	Abused legitimate domain
127.0.1.103	Abused redirector
127.0.1.104	Abused domain used in phishing
127.0.1.105	Abused domain used by malware
127.0.1.106	Abused domain hosting C&C
127.0.1.255	ERROR - IP queries are not allowed against the DBL

The error codes (these mean your query is broken, not that the target is listed - filters must treat them as “not listed”):

Code	Meaning
127.255.255.252	Typing error in the DNSBL zone name
127.255.255.254	Query came via a public/open resolver (you are blocked)
127.255.255.255	Excessive number of queries

If you ever see an answer outside 127.0.0.0/8, something - usually a hijacking resolver - is interfering with DNS; that reply “must be discarded.”

Summary table

List	Focus	Type	Scale	Zone	Code	Curation	Used at
SBL	Spam sources, snowshoe, bulletproof hosts	IP (v4+v6 ranges)	~30-40K	sbl.spamhaus.org	127.0.0.2	Manual (OSINT)	Connection + content
CSS	Automated low-reputation senders	IP (/32, /64)	2-4M; +300-400K/day	Subset of SBL zone	127.0.0.3	Automated	Connection + content
XBL	Compromised / exploited devices (CBL)	IP (individual)	~2M; +650K/day	xbl.spamhaus.org	127.0.0.4	Automated (auto-expiry)	Connection + headers + body
PBL	End-user IPs that shouldn’t send direct-to-MX	IP (CIDR)	More than 1.4B IPv4 (~40%)	pbl.spamhaus.org	127.0.0.10/.11	ISP + Spamhaus	Connection ONLY
DROP	Worst netblocks (firewall/router)	IP (CIDR) + ASN	small, high-confidence	JSON files / SBL	127.0.0.9	Manual (subset of SBL)	Network layer + mail
AuthBL	Bots abusing SMTP-AUTH credentials	IP (individual)	XBL subset	DQS	127.0.0.20	Automated	Submission (587/465)
DBL	Domains in spam/malicious mail	Domain	not stated	dbl.spamhaus.org	127.0.1.x	Automated heuristics	SMTP txn + content
ZRD	Brand-new domains (by age)	Domain	not stated	DQS	127.0.2.x	Automated	SMTP txn + content
ZEN	SBL + CSS + XBL + PBL combined	IP (combined)	all of the above	zen.spamhaus.org	multiple	Combined	Connection (replaces the four)

Query mechanics, usage rules, and why volume needs a paid plan

The Spamhaus public zones are free, but only under specific conditions - and getting this wrong is one of the most common ways senders and admins “break” Spamhaus on themselves.

Free public use requires both: “(1) Use of the Spamhaus DNSBLs is non-commercial, and (2) Queries are not being made from a public resolver or an IP with generic rDNS.” That second condition matters in practice: a query routed through Google (8.8.8.8), Cloudflare, Quad9, or any large public/open resolver typically returns either a wrong “not listed” answer or the 127.255.255.254 “query via public resolver” error. Spamhaus’s guidance is to “set up your own DNS resolver” rather than rely on a public one.

Higher volume requires a subscription. “Use of the Spamhaus DNSBLs by ISPs, corporations and networks with high email traffic, or commercial spam filter companies requires a subscription to either the dedicated Data Feed Service (rsync) or to DQS (Data Query Service).” The two paid options:

• Data Query Service (DQS): real-time DNS queries against Spamhaus Technology’s network, “ensur[ing] easy mail server configuration” with no local DNS server to run. DQS also unlocks data not in the free zones (AuthBL, ZRD, and on paid tiers the Hash Blocklist). DQS queries prepend a key to the zone, e.g. <reversed-ip>.<key>.zen.dq.spamhaus.net.
• Datafeed rsync: “transfers the Spamhaus DNSBL zones to a local DNS server on your network and keeps the zones synchronised every few minutes” - for operators who prefer to answer queries locally at scale.

This is why “I just point my mail server at zen.spamhaus.org” stops working once you have real volume or a commercial product: the free tier is explicitly for low-volume, non-commercial use, and abusing it (or querying from a public resolver) gets you rate-limited or firewalled. Never query the web lookup form programmatically either - “Any perceived use of automated tools to access the web lookup system will result in firewalling.”

How listings happen, and how delisting works

Listings are behaviour-driven, and the removal model is consistent across the IP lists, with one principle above all: it is always free. From the SBL guidance:

• No fee, ever. “There is never any charge or fee associated with removing any Spamhaus listing.” And: “Any offer from anyone to remove any Spamhaus listing for a fee is a scam.”
• Fix the cause first. You must demonstrate the problem is “solved permanently” before requesting removal. Removing the symptom while the underlying issue persists invites re-listing and escalation.
• Right party, right list, different timelines:
  • SBL removals are the network owner’s / ISP’s responsibility - “end users must contact their ISP/ESP.” There is no fixed clock; removal follows proof the abuse has stopped.
  • CSS is automated; the fix is to stop the low-reputation sending pattern, after which it clears (and re-lists if the behaviour returns).
  • XBL removals are automated via check.spamhaus.org, tied to the compromise ceasing - and XBL listings also auto-expire once the malicious behaviour is no longer detected.
  • PBL self-removal is via check.spamhaus.org where the IP’s policy permits, but the real fix is to stop sending direct-to-MX.
  • DROP / ASN-DROP clear automatically when the underlying SBL record is removed.

Before you act on any “listing,” confirm it is actually affecting you: Spamhaus’s first question is “Is this listing affecting delivery?” - “Check your mail server logs before taking any action! If there are no bounces, there is no problem.”

Spam traps - how the system gets its signal

A large part of what feeds these lists is spam traps: addresses that should never receive mail. Reaching one is direct evidence of a permission or hygiene failure. Spamhaus’s eBook names five trap types:

Trap type	What it is	What hitting it indicates
Classic / Pristine	Address never given to a user or published; sometimes a wildcard domain catch-all	List purchasing, harvesting, or address-space probing
Seeded	Deliberately scattered online where only scrapers find them	Scraping addresses or buying scraped lists
Typo domain	Look-alike of a common domain (yaaho.com, homail.com)	No address validation at collection; single opt-in
Dead / recycled	Once-valid address, hard-bounced for 12+ months, then reactivated as a trap	Old lists, poor bounce handling, no engagement pruning
Live (incl. role/WHOIS)	A real user’s address used to monitor unsolicited mail; includes postmaster@, abuse@, admin@	Harvesting, including from WHOIS

Two Spamhaus principles to internalise. First, don’t hunt traps - fix collection. “We strongly urge people to view spamtraps as proof of a data collection or hygiene issue and not be misled into conducting a hunt for spamtraps. Attempting to locate and remove traps only treats the symptom and not the underlying problem.” Second, you will never be told which address was the trap. “Spamtraps are never revealed by their owners,” partly because secrecy is part of their value and partly because senders would otherwise just suppress the one address and skip the real cleanup. Note too that non-existent domains can be traps: “sending to outdated lists increases the chances of sending to non-existent domains. This can be dangerous as non-existent domains can be spamtraps.” The defence is upstream, in suppression and consent discipline, not in trap-hunting.

Common mistakes

• “I’m on Spamhaus” is not one thing. A PBL listing (wrong architecture) and an SBL listing (identified spam source) have opposite remedies, and CSS - the automated low-reputation list - is the one ordinary senders trip most.
• ZEN covers everything. It does not. ZEN is IP-only; the DBL (and ZRD) are queried separately.
• CSS and SBL are different zones. CSS is a subset of the SBL zone; a query to sbl.spamhaus.org returns CSS hits too.
• Testing for “any record.” ZEN returns multiple codes; parse the specific 127.0.0.x values, and never treat a 127.255.255.x error as a listing.
• Querying through a public resolver. Google/Cloudflare/Quad9 resolvers return wrong or error answers (127.255.255.254); run your own resolver, or use DQS/rsync.
• Using the free zone at commercial volume. That is exactly what DQS and the rsync Datafeed are for; the free tier is low-volume, non-commercial only.
• Pointing the DBL at an IP, or the PBL at body/header content. The DBL lists only domains (127.0.1.255 error on an IP query); the PBL must be checked only against the connecting IP.
• Paying a “delisting service.” Never. Spamhaus removal is free; paid “removal” offers are scams.
• Suppressing the trap address. It hides one symptom. The trap signalled a collection failure that is still on your list.

What this means for you, and what Egressif does

The Spamhaus lists reward boring competence: send from infrastructure that is supposed to send mail (never PBL space), keep machines uncompromised (XBL/AuthBL), keep list hygiene clean enough to avoid traps (CSS, SBL, DBL), and keep your linked domains clean (DBL/ZRD). There is no paid shortcut off any of them, and the one list ordinary senders actually trip - CSS - is driven entirely by sending patterns and hygiene you control.

Egressif sends from owned IP space built for sending - not end-user ranges that belong on the PBL - and monitors the Spamhaus lists (the IP lists via ZEN-style checks against our connecting addresses, the DBL separately against our domains, and AuthBL on submission) so a listing is an alert we work, not a silent delivery cliff. We parse the actual 127.0.0.x return code so we know whether we are looking at a CSS hygiene signal, an XBL compromise, or a PBL architecture mismatch, and respond accordingly. When something does surface, we fix the underlying cause before requesting removal, because Spamhaus requires the problem be “solved permanently” and will escalate on repeat offenders. And because trap hits trace back to list quality, we handle complaints and suppression as a standing discipline rather than a clean-up after a listing. We never pay a “delisting” service - there is no such legitimate thing.