DNSBL Directory - Blocklists and How to Use Them

A DNS-based blocklist (DNSBL) is the closest thing email has to a shared reputation signal: a list of IP addresses or domains, published as a DNS zone, that any receiver can query in milliseconds while a message is still arriving. They are powerful and cheap, which is also the problem - a single list can quietly decide whether your mail is delivered, and the lists differ enormously in quality, scope, and how aggressively they list. This page is a neutral directory of the major reputable lists plus the standard mechanics behind all of them, so you can read a listing correctly instead of panicking at a tool that checks “100+ blocklists” and flags a dead one.

This sits alongside the deep dives on the Spamhaus blocklists, the URI/domain blocklists SURBL and URIBL, and the reputation overview. For the receiver-side filtering these feed into, see the spam-filtering overview; for keeping the list clean enough to stay off them in the first place, see suppression and consent.

The 60-second version

• A DNSBL is just a DNS zone. To check an IP, you reverse its octets, append the list’s zone, and look up an A record. RFC 5782 defines this exactly.
• A listed entry returns an address in 127.0.0.0/8 (conventionally 127.0.0.2); an unlisted entry returns NXDOMAIN. The A value is a code, never a real IP.
• Combined lists pack multiple sublists into one query using bit-masked or distinct 127.x.x.x return codes - one lookup, several possible answers.
• There are domain lists too (RHSBLs / URI lists): the domain is prepended to the zone instead of a reversed IP.
• Lists vary wildly. Some are conservative and manually reviewed; others list whole networks or ASNs and accept “collateral damage.” RFC 6471 says the operator MUST disclose that scope - and it is your job, the user’s, to understand it.
• Use a DNSBL as a score, not a universal hard block. The responsibility for what a listing does is yours, not the list’s.
• Reputable lists never charge to delist. Charging a listee to be removed from a negative list is the behaviour RFC 6471 warns against.

How a DNSBL query works (RFC 5782)

Every IP-based DNSBL uses the same structure, “adapted from that of the rDNS.” To test an IPv4 address you reverse the order of its octets, append the list’s zone name, and query for an A record:

# Is 192.0.2.99 listed in the (example) list bad.example.com?
# Reverse the octets:           99.2.0.192
# Append the zone:              99.2.0.192.bad.example.com
# Look up the A record:
99.2.0.192.bad.example.com   A     127.0.0.2
99.2.0.192.bad.example.com   TXT   "listed: see http://bad.example.com/..."

The rules that matter for reading a result:

• An A record means “listed.” RFC 5782: “A client MUST interpret any returned A record as meaning that an address or domain is listed in a DNSxL.” No record (NXDOMAIN) means not listed.
• The A value is a code, not an address. “The contents of the A record MUST NOT be used as an IP address,” and all values “SHOULD be in the 127.0.0.0/8 range to prevent unwanted network traffic if the value is erroneously used as an IP address.”
• A TXT record usually explains why, and is “often used as the text of an SMTP error response” or as explanatory text in a scoring filter.
• 127.0.0.2 must always be listed; 127.0.0.1 must never be. RFC 5782 requires a live list to contain a test entry for 127.0.0.2 and to not list 127.0.0.1. RFC 6471 adds that a positive answer for 127.0.0.1 “SHOULD indicate that the DNSBL has started listing the world and is non-functional.” Clients “SHOULD periodically check” the test entry and stop using a list that fails it.

IPv6 lists use the same idea with the 32 nibble-reversed hex characters of the address (per IP6.ARPA). Domain lists (“RHSBLs,” for right-hand-side) prepend the domain instead of a reversed IP - invalid.example.doms.example.net - and use the reserved name test as the conventional test point rather than 127.0.0.2.

Combined lists and return codes

To avoid many lookups, a list often folds several sublists into one zone and distinguishes them by the A value, either as bit masks (the answer is the logical OR of each matching sublist’s bit) or as distinct return codes. Spamhaus ZEN is the canonical example: one query to zen.spamhaus.org can return several answers in a single packet, one per dataset the IP is on. RFC 6471 recommends that even when a list packs entries into one zone by return code, it also offer per-type subzones so users can query a single category. The practical rule from RFC 5782: clients “SHOULD be able to use bit masks and value range tests on returned A record values” - if you only test “did I get any A record,” you cannot tell a connection-time list (block) from a policy list (do not block).

How to use DNSBLs responsibly (RFC 6471)

RFC 6471 is the operator-and-user best-practice companion to RFC 5782, and most of its weight falls on the user - you, the postmaster. Its core point is blunt: “responsibility for filter decisions remains ultimately with you.” A few principles that should shape how any sender or receiver treats these lists:

• Score, don’t reflexively hard-block. A DNSBL user “doesn’t have to use a listing as a pass/fail binary decision - it can use a listing as one factor in email filters that make decisions based on scoring multiple factors together.” This is the single most important defence against false positives. SpamCop says the same of its own list: “strongly consider using the SCBL as part of a scoring system.”
• Understand the list’s intended use before you deploy it. Some IP lists are “appropriate for assessment of only the peer IP address of the machine connecting” and not for IPs in Received: headers or links in the body. Using a connection-time list on body content (or vice versa) produces wrong rejections. Spamhaus’s PBL is the textbook case - it must be used only against the connecting IP.
• Read the scope and aggressiveness, because the operator must publish it. RFC 6471 requires that “listing policies MUST include statements as to the scope and aggressiveness of listings” - including whether listings are meant for scoring and whether the list deliberately accepts “collateral damage” (listing some non-abusive mail to catch a range or ASN). A list that lists whole networks is not “wrong,” but you must know that is what you adopted.
• Test the list periodically and expect it to be temporary. Lists “can, and have, ceased operation without notice”; users “SHOULD periodically check the correct operation of the DNSBL” and stop using ones that misbehave. Listings themselves “SHOULD be considered temporary” and expire when the cause clears.
• Be suspicious of pay-to-delist. Charging for access (a commercial list) is fine; charging a listee to be removed from a negative list “steers perilously close to notions of extortion,” and RFC 6471 recommends such lists “not be used.” Spamhaus states it plainly for its own lists: “Any offer from anyone to remove any Spamhaus listing for a fee is a scam.”

What this means for a sender

You are usually the subject of these lists, not the operator, so the practical workflow is:

1. Check your own sending IPs and domains against the major lists - but read your mail-server logs first. A listing only matters if it is actually causing bounces; many lists “have no meaningful impact on email delivery.”
2. Fix the cause before requesting delisting. Trap hits, complaints, and compromise are what put you there; suppressing one symptom invites re-listing. See suppression and consent.
3. Weight lists by reach, not by count. A listing on a high-reach list (Spamhaus ZEN, Barracuda) is worth acting on; an obscure or defunct list usually is not. A high-reach but aggressive list (SpamCop) is worth investigating, but remember many receivers score it rather than block on it.

The directory

The lists below are grouped by how you should use them, not alphabetically - because the grade (hard-reject vs. tag-only vs. policy) matters more than the name. Every entry is taken from the operator’s own current documentation; where the operator does not publish a field (a return code, an exact removal SLA), it is left blank rather than guessed. Verify the live specifics on each operator’s site before deploying, because zones and codes do change.

Hard-reject grade (high-reach, low false-positive, conservative)

These are the lists whose data is reliable and high-reach enough that many operators reject on them at connection time. Even here, “reject” is a deployment choice you own - read each list’s scope first.

List	Query zone	Type	What it lists	Listed return code(s)	Delisting
Spamhaus ZEN	zen.spamhaus.org	IP (v4+v6)	SBL+CSS+XBL+PBL combined	127.0.0.2/.3 (SBL/CSS), 127.0.0.4 (XBL), 127.0.0.9 (DROP), 127.0.0.10/.11 (PBL), 127.0.0.30 (BCL)	Free, via check.spamhaus.org; cause-dependent per sublist
Barracuda BRBL	b.barracudacentral.org	IP	Manually verified poor-reputation IPs + appliance/spamtrap data	127.0.0.2	Free removal form, typically within ~12h after fixing cause; must register your querying DNS server IP
Mailspike	bl.mailspike.net (combines z.mailspike.net + worst levels of rep.mailspike.net)	IP	Distributed spam-wave participants (zero-hour) plus worst reputation levels	127.0.0.2 (zero-hour) or 127.0.0.10-127.0.0.12 (reputation levels L5-L3)	Self-service delist form; automatic within 6h-36h

Score / tag-only IP reputation

Use these to add to a spam score, not to hard-block on their own. Many are automated, regionally focused, or list things other than spam (login attacks, dynamic ranges, proxies). They are useful signals; treated as a binary reject they generate false positives.

List	Query zone	Type	What it lists	Listed return code(s)	Delisting
SpamCop SCBL	bl.spamcop.net	IP	Reported mail + spamtrap hits, freshness-weighted	127.0.0.2	Free; auto-delists ~24h after reports stop. Operator-described as aggressive - scoring use preferred
PSBL	psbl.surriel.com	IP	Sent to a spamtrap, not seen as legitimate, not a known mail server	Conventional listed A record	Instant, no-questions self-removal by anyone
blocklist.de	bl.blocklist.de (per-service sub-zones, e.g. mail., ssh.)	IP	Hosts that attacked fail2ban-protected services in the last 48h (SSH, mail logins, web, etc.) - explicitly not general spam	127.0.0.2-127.0.0.22 by attack type (127.0.0.9 = mail)	Self-service delist link; 48h rolling auto-expiry
SpamRATS	dyna./noptr./spam./auth./all.spamrats.com (query key prefix required)	IP	RATS-Dyna (dynamic/residential), RATS-NoPtr (no valid rDNS), RATS-Spam (spam sources), RATS-Auth (auth/BEC attacks)	127.0.0.36 (Dyna), .37 (NoPtr), .38 (Spam), .43 (Auth)	Manual removal via contact form, proof of ownership required. Do not use RATS-Auth for inbound mail
DroneBL	dnsbl.dronebl.org	IP	Drones, bots, open/abused proxies, brute-forcers (IRC-oriented, not a spam list)	127.0.0.X by abuse type (e.g. .3 IRC drone, .8 SOCKS proxy, .9 HTTP proxy, .13 brute-force, .17 botnet)	Self-service lookup/removal; reporting needs an RPC key
Spam Eating Monkey (SEM-BLACK)	bl.spameatingmonkey.net	IP	IPs over a spamtrap threshold plus policy listings; goal of zero false positives	127.0.0.2	Lookup-and-remove form; spamtrap listings auto-expire ~7-15 days, policy listings manual
SEM-NETBLACK	netbl.spameatingmonkey.net	IP (networks)	Low-reputation networks	127.0.0.2	Manual; does not auto-expire
SEM-BACKSCATTER	backscatter.spameatingmonkey.net	IP	IPs that sent a null sender (MAIL FROM: <>) to a spamtrap (backscatter)	127.0.0.2	Auto-expires ~15 days after activity stops
0spam	bl.0spam.org (also rbl., nbl., dbl.0spam.org)	IP	Spamtrap hits + ML framework; nbl. is whole-Class-C and “should be used with caution”	Not stated on the public page	Account-based self-removal, 1 IP per 3h; free up to 4000 queries / 5s
s5h	all.s5h.net	IP (v4+v6)	Aggregate of abusive hosts / spam sources hitting their servers (RFC 5782 compliant)	Conventional listed A record	Self-service: request from the listed IP for immediate removal
Fabel Spamsources	spamsources.fabel.dk	IP	IPs that sent spam to their network/users; may list a netblock when whois abuse contact is bad	Conventional listed A record	Self-service delist form; DNS updates within ~20 min
abuse.ro	rbl.abuse.ro (also pbl.abuse.ro)	IP	Romania-focused: spam-sending IPs/classes; pbl. = residential end-user blocks	127.0.0.2 (spam IP), .3 (abused/infected), .4 (spam class); pbl. .9 (residential)	Operator process; small regional list - score, don’t block
RV-SOFT	dnsbl.rv-soft.info	IP	Reported mail + submissions (SpamCop-style, time-based)	Conventional listed A record	Automatic delist when reports stop. Small, low-reach list - scoring only
ImproWare (swinog)	spamrbl.swinog.ch, dnsrbl.swinog.ch	IP	IPs from caught spam mails / spamtrap-assembled realtime list	Conventional listed A record	Free self-service removal, processed within ~48h, once per IP per week
invaluement	subscriber-assigned hostname (no fixed public zone)	IP + domain	ivmSIP/ivmSIP/24 (IP), ivmURI (domain) - spam Spamhaus misses	Not publicly documented (commercial)	Delist form on invaluement.com; free 7-day trial
UCEPROTECT	dnsbl-1/2/3.uceprotect.net	IP, networks, ASNs	Level 1 = individual IPs; Level 2/3 escalate to networks/ASNs (deliberate collateral damage)	Per level (verify on uceprotect.net)	Free 7-day auto-expiry; paid express delisting - the pay-to-delist pattern RFC 6471 warns about

URI / RHSBL / domain lists (content/domain checks, not the client IP)

These judge the domains and links inside a message, not the connecting IP. You query them by prepending the domain to the zone (RHSBL style), so they catch a spammy link sent from a clean IP. They are scoring inputs for body/content analysis.

List	Query zone	Type	What it lists	Listed return code(s)	Delisting
Spamhaus DBL	dbl.spamhaus.org	Domain	Poor-reputation / abused domains	127.0.1.2 spam, .4 phish, .5 malware, .6 botnet C&C, .102-.106 abused-legit; 127.0.1.255 = IP query rejected	Free, automatic expiry or via reputation checker
SURBL multi	multi.surbl.org	Domain (+ IP)	Bitmasked: abuse/spam, phishing, malware, cracked, click-trackers, disposable-mail	Bitmask in last octet: 4 DM, 8 PH, 16 MW, 32 CT, 64 ABUSE, 128 CR (127.0.0.1 = your access is blocked)	Removal form via the SURBL lookup page
URIBL	multi.uribl.com (also black./grey./red.uribl.com)	Domain (+ IP)	Domains that appear in spam (tags mail, does not block)	Bitmask: 2 black, 4 grey, 8 red (127.0.0.1 = query blocked)	Login + submit a delist request on uribl.com
SEM-URI	uribl.spameatingmonkey.net	Domain	Domains/URIs seen in spamtrap mail	127.0.0.2	Lookup-and-remove form; auto-expires ~30 days after activity stops
ImproWare URIBL	uribl.swinog.ch	Domain	Realtime URI list built from spamtrap sources	Conventional listed A record	Free self-service removal, processed within ~48h
Suomispam DBL	dbl.suomispam.net (sibling of bl./gl./ebl.suomispam.net)	Domain	Finland-focused: domains related to / used in spam (senders, redirectors, target sites)	127.0.0.2 spam source, .3 escalation, .4 target site, .5 suspicious, .99 other	Email-based request to suomispam@suomispam.net
ZapBL RHSBL	rhsbl.zapbl.net (IP sibling dnsbl.zapbl.net)	Domain	Domains the operators do not want mail from (“a list of opinions”; does not block)	Conventional listed A record	Per the operator’s listing/delisting policy
abuse.ro URI/DBL	uribl.abuse.ro, dbl.abuse.ro	Domain	uribl. = spamvertized domains; dbl. = confirmed spam-sending sender domains (RHSBL)	uribl. 127.0.0.2 heavily spamvertized, .4 spamvertized, .9 dynamic	Operator process; small regional list - score, don’t block

Infrastructure policy lists (network properties, NOT spam reputation)

These do not measure whether an IP sends spam. They flag a network property - a reserved/unallocated address, or an anonymity-network exit. Used deliberately they are useful (you may not want direct-to-MX mail from a Tor exit, or any traffic from a bogon); used as if they were spam lists they reject legitimate mail. Label them clearly in your config and decide each one on purpose.

List	Query zone	Type	What it lists	Listed return code(s)	Notes
Team Cymru bogons	bogons.cymru.com	Policy (IP)	Traditional bogons: martian/reserved prefixes and unallocated /8 space	127.0.0.2 (TXT = the matching bogon prefix)	These should never appear as a legitimate source on the public internet
Team Cymru fullbogons	v4.fullbogons.cymru.com (v6.fullbogons.cymru.com for IPv6)	Policy (IP)	Bogons plus space allocated to RIRs but not yet assigned - changes frequently	127.0.0.2 (TXT = prefix)	Up to ~250k prefixes; keep current or risk blocking newly-assigned legitimate space
Tor (dan.me.uk)	tor.dan.me.uk (all nodes), torexit.dan.me.uk (exit only)	Policy (IP)	Live Tor nodes; the torexit zone is exit nodes only	127.0.0.100 (TXT carries node flags)	Auto-removed within ~1h of the node leaving the Tor network; no manual delist
Tor (EFnet)	tor.efnet.org	Policy (IP)	Scanned Tor exit nodes (IRC-oriented; mirror rbl.efnetrbl.org carries proxies/drones too)	127.0.0.1 (= TOR in the EFnet reply scheme)	Tor nodes listed ~10 days; use the rbl.efnetrbl.org mirror in configs

Spamhaus ZEN, DBL, and DROP

Spamhaus is the highest-reach operator and has its own field guide; the directory entries above are the query-level summary. ZEN (zen.spamhaus.org) is the recommended IP query and combines SBL, CSS, XBL, and PBL, with distinct return codes so you can tell, for example, a manually-researched SBL listing (127.0.0.2) from policy space that should not send direct-to-MX (PBL, 127.0.0.10/127.0.0.11). DBL (dbl.spamhaus.org) is the domain list and is queried separately - “Zen is an IP address DNSBL zone… it does not include the DBL” - with its own return codes in 127.0.1.0/24 (127.0.1.2 spam, 127.0.1.4 phish, and so on; an IP query against DBL wrongly returns 127.0.1.255, “IP queries prohibited”). DROP is a tiny, very conservative subset of the SBL listing hijacked and criminal netblocks (and ASN-DROP for ASNs), published as JSON for firewalls and routers, and surfaced as 127.0.0.9 inside SBL/ZEN. All Spamhaus delisting is free; a range leaves DROP automatically once its SBL record is removed.

SpamCop SCBL (bl.spamcop.net) - score, do not hard-block

SpamCop’s list is fast, automated, and openly described by SpamCop itself as aggressive, which is exactly why it belongs in the tag-only column rather than the hard-reject one. It lists “IP addresses which have transmitted reported email to SpamCop users,” weighting reports by freshness (the most recent reports count 4:1, reports older than 48 hours 1:1, and reports older than a week are ignored) and by spamtrap hits. Its great virtue for senders is that it auto-delists: “without any additional reports, a reported address stays on the SCBL for only 24 hours.” SpamCop explicitly recommends using the SCBL “as part of a scoring system” and to “explicitly allowlist wanted email senders,” precisely because an aggressive, fast-moving list used as a hard block will catch wanted mail. Treat it as a strong scoring signal, paired with an allowlist - not a reject-on-sight rule. A query returns 127.0.0.2 when listed.

Barracuda BRBL (b.barracudacentral.org)

The Barracuda Reputation Block List is a free IP list whose data comes largely from Barracuda’s installed base of anti-spam appliances plus spamtraps, with poor-reputation IPs “manually verified.” Two operational details matter: it returns 127.0.0.2 when listed, and you must register the IP of the DNS server that will query it - unregistered queries “may be blocked, rate controlled or otherwise denied access without warning.” Delisting is a removal form on barracudacentral.org, “typically investigated and processed within 12 hours,” and only after you have fixed the underlying cause, or it will relist.

Mailspike (bl.mailspike.net)

Mailspike is a free, automated IP-reputation service with two data sets. rep.mailspike.net encodes an over-time reputation level in the last octet - 127.0.0.10 through 127.0.0.14 for the worst-to-bad levels (L5-L1) and 127.0.0.16 through 127.0.0.20 for neutral-to-excellent reputations - so it can also be read as a positive signal. z.mailspike.net is the zero-hour list of IPs “seen participating in a distributed spam wave,” returning 127.0.0.2. bl.mailspike.net is the combined block zone: it folds in z. plus the worst reputation levels (L3-L5) so a single query answers “should I block this?”, returning 127.0.0.2 or the matching reputation code. Mailspike only delists its own zones; a self-service form clears a listing automatically within 6h-36h once the cause is mitigated.

blocklist.de, SpamRATS, DroneBL - useful, but not spam lists

Three of the score-only IP lists are easy to misuse because their names suggest “spam” when they list something narrower:

• blocklist.de (bl.blocklist.de) is a fail2ban reporting service: it lists IPs that attacked SSH, mail logins, web apps and similar services in the last 48 hours, and it states it is “comparable with spamcop.net for attacks of any nature, with an exception for spam.” Use the mail.bl.blocklist.de sub-zone if you specifically want mail-login attackers. Return codes run 127.0.0.2-127.0.0.22 by attack type.
• SpamRATS (*.spamrats.com) now requires a per-user query key prefixed to the zone. RATS-Dyna and RATS-NoPtr list dynamic/residential and missing-rDNS space (policy-style signals), RATS-Spam lists spam sources, and RATS-Auth lists authentication/BEC attackers - and the operator is explicit that RATS-Auth must not be used to filter inbound email. Codes are 127.0.0.36/.37/.38/.43.
• DroneBL (dnsbl.dronebl.org) is an IRC-oriented list of drones, bots, and open/abused proxies, with a return code per abuse type. It is excellent for what it lists and a poor fit as a general inbound-mail spam reject.

Spam Eating Monkey (SEM)

SpamEatingMonkey publishes several free zones. bl.spameatingmonkey.net (SEM-BLACK) lists IPs over a spamtrap threshold plus policy listings, with a stated goal of zero false positives; spamtrap listings auto-expire after ~7-15 days, while policy listings need a manual request. netbl.spameatingmonkey.net (SEM-NETBLACK) lists low-reputation networks and does not auto-expire. backscatter.spameatingmonkey.net lists IPs that sent a null sender (MAIL FROM: <>) to a spamtrap. All three return 127.0.0.2. The domain-side uribl.spameatingmonkey.net (SEM-URI) belongs in the URI section above. Removal is via the lookup-and-remove form on spameatingmonkey.com. (Note: the older badnets.spameatingmonkey.net zone has been deprecated and empty since 2010 - do not use it.)

s5h, Fabel, abuse.ro, RV-SOFT, ImproWare, Suomispam, ZapBL - smaller verified lists

These are genuine, currently-operating lists with public operator documentation, but each is small, regional, or narrow - they belong in a score, never a standalone reject:

• s5h (all.s5h.net) is an RFC 5782-compliant aggregate of hosts that hit the operator’s servers; delisting is immediate and self-service (make a request from the listed IP).
• Fabel Spamsources (spamsources.fabel.dk) is a Danish IP list with a self-service delist form that propagates within ~20 minutes; it lists only IPs, never domains.
• abuse.ro publishes rbl.abuse.ro (IP, codes 127.0.0.2/.3/.4), pbl.abuse.ro (residential), and the domain lists uribl.abuse.ro/dbl.abuse.ro. It is Romania-focused and small.
• RV-SOFT (dnsbl.rv-soft.info) is a small Czech SpamCop-style list with time-based automatic delisting and very low reach.
• ImproWare AG (Switzerland) runs the swinog.ch zones - spamrbl.swinog.ch and dnsrbl.swinog.ch (IP) and uribl.swinog.ch (domain) - with a free self-service removal processed within ~48h. (The older spamrbl.imp.ch / wormrbl.imp.ch hostnames are legacy; the operator documents the swinog.ch zones today.)
• Suomispam (bl./gl./dbl./ebl.suomispam.net) is a Finland-language reputation service; its gl. (gray) list is for scoring only by design.
• ZapBL (dnsbl.zapbl.net IP, rhsbl.zapbl.net domain) describes itself as “a list of opinions” that “does NOT block email.”

invaluement and UCEPROTECT

invaluement is a commercial set of lists (ivmSIP, ivmSIP/24, ivmURI) designed to catch what Spamhaus misses while keeping false positives very low. Because it is a subscription service, there is no fixed public query zone - the operator assigns each subscriber a hostname - so this page does not publish one; start from a free trial and the delist form on invaluement.com.

UCEPROTECT is the clearest example of an aggressive, escalating list, and its reputation is correspondingly controversial. Level 1 (dnsbl-1.uceprotect.net) lists individual offending IPs; Level 2 lists larger network allocations once listings in a range exceed a threshold; and Level 3 lists entire ASNs. That escalation is the point - it pressures providers by listing their neighbours - but Level 2 and 3 list large amounts of non-abusive mail by design (textbook “collateral damage”). Listings expire free “7 days after the LAST abuse is detected,” but an optional paid express delisting exists, and the existence of any pay-to-delist option on a negative list is exactly what RFC 6471 cautions against. A listing on a UCEPROTECT-style aggressive list is often not actionable: treat it as a scoring signal at most, and check whether a given receiver even uses it before reacting.

Decommissioned lists (do not query)

Monitoring tools that brag about checking “80+ blocklists” routinely still query lists that no longer hold data - a dead zone can even “list the world” and report a false positive on every IP. If any of these are still configured in a mail server or filter, remove them, and ignore any tool that still “lists” you on them.

• SORBS (*.sorbs.net) - decommissioned by its owner Proofpoint on 5 June 2024; all zones are empty.
• NixSPAM (ix.dnsbl.manitu.net) - shut down 16 January 2025.
• CBL (cbl.abuseat.org, bl.abuseat.org) - the Composite Blocking List was retired in 2021; its data moved into the Spamhaus XBL/ZEN, so query Spamhaus ZEN instead.
• WPBL (db.wpbl.info) - the Weighted Private Block List shut down in 2024.
• dnsbl.inps.de and ubl.unsubscore.com - both carry public shutdown/offline notices and should be removed.
• abuse.ch DNSBLs (dnsbl./spam./combined./drone./httpbl.abuse.ch) - abuse.ch retired its free DNSBL/blocklist feeds (now part of Spamhaus); these zones no longer return live data.
• RBL.JP (virus.rbl.jp, url.rbl.jp) - the service shut down on 30 September 2017.
• sectoor.de Tor lists (tor.dnsbl.sectoor.de, exitnodes.tor.dnsbl.sectoor.de) - offline since June 2018 (domain expired); use dan.me.uk or EFnet for Tor data instead.
• dnsbl.net.ua - no new listings since January 2022 and the RFC 5782 test entry no longer resolves; treat as defunct.

Allowlists (DNSWLs) and why “whitelisting” is not a backdoor

The same DNS structure serves allowlists (DNSWLs): “Network managers typically use DNSBLs to block traffic and DNSWLs to preferentially accept traffic,” and “the structure of a DNSBL and DNSWL are the same.” A name-based DNSWL can even encode a 0-100 or 0-255 reputation score in the A record. Public allowlists exist (for example DNSWL.org, referenced by PSBL for permanent whitelisting), but being on one is a minor positive signal a receiver may weight - not an inbox guarantee. Major mailbox providers do not offer sender allow-listing that bypasses filtering; as the reputation overview notes, “the days of ‘whitelisting’ are long gone.”

Common confusion

• “A blocklist blocked my mail.” A DNSBL blocks nothing on its own. A receiver chose to query it and act on the result - RFC 6471: “A DNSBL without DNSBL users does not block… email.” The decision, and the false positive, belong to the receiver’s configuration.
• “I’m on 12 blocklists, I’m in trouble.” Count is not reach. One listing on a widely-used list matters; a dozen listings on obscure or dead lists usually do not. Read your bounce logs.
• “Any A record means I’m blocked.” Only if the receiver treats it that way. The return code carries meaning - policy space (127.0.0.10), an error condition (127.255.255.254, a query through a public resolver), or a real listing are all different answers.
• “I should pay to get delisted faster.” On a reputable list, delisting is free; on a negative list, pay-to-delist is a red flag (RFC 6471) and, for Spamhaus, an outright scam.
• “My monitoring tool says SORBS lists me.” SORBS has been off since June 2024 and holds no data. That is phantom output.
• “A clean IP is enough.” IP lists are only half of it - domain and URI lists (SURBL/URIBL, Spamhaus DBL) judge the domains in your mail regardless of the sending IP.

What this means for you, and what Egressif does

DNSBLs reward the same discipline everything else in deliverability does: send wanted mail from infrastructure that is supposed to send it, keep the list clean enough to avoid traps, and keep every domain you reference clean too. There is no list you can pay your way off of that was worth being on.

Egressif operates owned IP space built for sending rather than transient or end-user ranges, and we monitor listings across the major, high-reach lists - the Spamhaus zones, Barracuda, SpamCop, and the domain/URI lists - so a listing surfaces as an alert we work, weighted by the list’s actual reach, rather than a silent placement drop. When something does list us, we fix the underlying cause before requesting the (always free) delisting, because aggressive lists relist fast and conservative ones require the problem to be genuinely solved. We treat every list as a score and a signal, not an oracle - and we do not chase phantom listings on lists that no longer exist.