Blocklist lookup — IP reputation against the DNSBLs that actually matter in 2026
Type an IPv4 address. The browser reverses the octets, queries DNS over HTTPS against each major active DNSBL — Spamhaus ZEN, Barracuda BRBL, SpamCop, plus the Spamhaus sublists SBL, XBL, PBL — and reads the response codes that encode why an IP is listed. You see which lists carry your IP, the meaning of each listing (SBL spam source vs PBL consumer range vs XBL exploit), and a short note on what each result means for deliverability. We do not check lists that have been decommissioned (SORBS in June 2024, NiX Spam in January 2026, WPBL in 2024) — only the lists that real mailbox providers still consult.
Check an IPv4 address
Enter the public IPv4 address of your sending server. Each list is queried via DNS over HTTPS in parallel; results stream in as each blocklist responds.
DNS over HTTPS via cloudflare-dns.com · No data sent to our servers · Use only for IPs you own or have permission to check
A DNSBL is a database of IP addresses, published as DNS records, that mail servers query in real time to decide whether to accept a connection
The mechanism is older than DKIM, older than SPF, and still load-bearing across most of the inbound mail filtering on the internet. When your sending server connects to a recipient's mail server to deliver a message, the receiver takes your IP address, reverses the octets, appends the DNSBL zone name, and queries DNS. A query for the IP 192.0.2.1 against Spamhaus ZEN looks like 1.2.0.192.zen.spamhaus.org. If the receiver gets an A record back — typically in the 127.0.0.0/8 range, with the last octet encoding the reason for listing — your IP is on the list. The connection is rejected or the message routed to spam, depending on receiver policy. The lookup takes a few milliseconds and happens on every inbound connection from every IP, so a DNSBL listing translates directly to large-scale deliverability damage within hours.
The 2026 landscape has consolidated significantly from what it was a decade ago. Three lists carry the majority of practical impact. Spamhaus ZEN (zen.spamhaus.org) is the most consequential — it combines three sublists (SBL for confirmed spam sources, XBL for exploited or compromised IPs, PBL for IP ranges that should not originate mail directly) and protects over three billion mailboxes. Listings on Spamhaus get honored by Gmail, Microsoft Outlook, Yahoo, and most enterprise mail gateways. Barracuda Reputation Block List (b.barracudacentral.org) is widely used in corporate environments running Barracuda email security appliances — which is a lot of mid-market enterprises, particularly in healthcare, legal, financial services, and manufacturing. SpamCop (bl.spamcop.net) auto-delists after 24-48 hours once new spam reports stop, making it the most forgiving of the three; it feeds into multiple downstream filters and matters at the margins.
Several lists that older tutorials still recommend have been decommissioned and should not be checked. SORBS shut down permanently in June 2024 — if your monitoring still queries dnsbl.sorbs.net, remove it. NiX Spam shut down in January 2026. WPBL was retired in 2024 (their own site now reports the list contains no entries). Lashback UBL has been offline since 2021. AUPADS produces near-100% false positive rates and is effectively unusable. The tool above queries only lists that are operationally active in 2026.
Two things make blocklist checking different from the other authentication tools we publish. First, blocklists are reactive — they detect bad sending behavior after it happens, then publish the listing. Unlike SPF or DKIM, you do not configure your way onto or off a blocklist; you get listed because of what your IP sent, and you get delisted by stopping the behavior and submitting a removal request. Second, several major blocklists — Spamhaus most explicitly — restrict commercial-volume querying. Free use for individual checks is fine; running thousands of queries per day from the same IP requires licensing. The tool above is meant for occasional reputation checks against your own IPs, not for productionising automated monitoring at scale.
Each blocklist defines its own response codes. Here is the meaning of each result the tool returns
zen.spamhaus.org Spamhaus ZEN — the aggregate list combining SBL, XBL, and PBL. The most impactful blocklist in the world; listings here meaningfully degrade deliverability across Gmail, Outlook, Yahoo, and corporate mail systems.
127.0.0.2 = SBL spam · 127.0.0.3 = CSS snowshoe · 127.0.0.4-7 = XBL exploit · 127.0.0.10-11 = PBL consumer range
b.barracudacentral.org Barracuda BRBL — the public version of Barracuda's reputation data, used by Barracuda email security appliances and various other commercial filters. Heavily deployed in corporate environments.
127.0.0.2 = generic listing · removal: barracudacentral.org/rbl/removal-request
bl.spamcop.net SpamCop — community-reported spam sources. Feeds into downstream filters including some Cisco IronPort, ProofPoint, and corporate spam scoring. Auto-delists 24-48 hours after reports stop.
127.0.0.2 = generic listing · auto-delist with time
sbl.spamhaus.org Spamhaus SBL — confirmed spam sources, manually verified by Spamhaus researchers. Listings here are serious and require remediation plus delisting request via spamhaus.org/sbl.
127.0.0.2 = SBL · 127.0.0.3 = CSS · removal: spamhaus.org/lookup
xbl.spamhaus.org Spamhaus XBL — exploited and compromised IPs (botnets, open relays, infected servers). XBL listing typically indicates active compromise — fix the underlying issue before requesting delisting.
127.0.0.4-7 = various exploit types · auto-delist after the compromise is fixed and reported
pbl.spamhaus.org Spamhaus PBL — Policy Block List. Not a spam list; lists IP ranges that ISPs have flagged as "should not originate mail directly" (typically consumer broadband). False alarm if you run a legitimate mail server on a dedicated IP — ask your ISP to submit a PBL removal.
127.0.0.10 = ISP-maintained · 127.0.0.11 = Spamhaus-maintained · removal via ISP or self-service
Note on coverage: The tool checks the six lists above because they are the operationally active ones that mailbox providers actually consult in 2026. We deliberately do not check lists that have been decommissioned (SORBS, NiX Spam, WPBL, Lashback UBL), produce high false positive rates (AUPADS), or are dormant despite still appearing in older monitoring tooling.
A listing is the symptom. Diagnosing and fixing the underlying cause is the work — delisting requests without remediation just get you relisted within days
1. Identify the root cause before submitting any removal request
A Spamhaus SBL listing means real reports of spam from your IP — typically a compromised account sending phishing, a misconfigured list import full of spam traps, an open relay attack, or a cold email campaign that hit a honeypot. An XBL listing means your IP is currently part of a botnet or running malware. A PBL listing means your ISP designated the range as non-MTA. None of these get fixed by submitting a removal form. Fix the underlying issue first — disable the compromised account, scrub the list, plug the open relay, talk to the ISP about the PBL designation. Then submit removal.
2. Submit the removal request through each blocklist's official process
Spamhaus: spamhaus.org/lookup — enter the IP, follow the instructions for the specific sublist. SBL listings require a written explanation of what was fixed; expect 24-72 hours for processing. XBL auto-delists once the compromise is resolved and the IP shows clean traffic. PBL is removed via your ISP or self-service. Barracuda: barracudacentral.org/rbl/removal-request — submit once; do not resubmit. First-time removals process within 12-24 hours; repeat listings take longer. If no response in 24 hours, escalate via phone. SpamCop: nothing to submit — listings expire 24-48 hours after the last spam report.
3. Resist the urge to submit repeat removal requests
The fastest way to slow down or block your delisting permanently is to submit the same request three times in a row when you do not hear back within an hour. Blocklist operators are humans triaging real abuse reports; flooding them with duplicate requests pushes you to the bottom of the queue. Submit once, wait the stated timeline, only escalate if the documented window has passed without response.
4. Check the rest of your authentication while you are at it
A blocklist listing rarely arrives in isolation. Run a DMARC check on the affected domain and an SPF lookup count — most teams that get listed also have authentication issues that contributed to the compromise being possible. Fix everything in the same window: rotate any leaked credentials, validate SPF stays under 10 lookups, confirm DKIM signs at 2048-bit, push DMARC toward enforcement.
5. Prevent recurrence with monitoring and list hygiene
Repeat listings are 5-10x harder to remove than first-time ones — Spamhaus in particular keeps repeat offenders for weeks. The way to stay off the list is to not get listed: verify every email address before sending, drop bad addresses from the database, monitor complaint rates below 0.1%, keep volume increases gradual, never send to purchased lists. Spam traps are the most common cause of listings for legitimate-feeling senders; an email verification step before campaigns catches them before they ever land in a send.
Blocklist remediation is one of the parts of deliverability that benefits most from a named operator — speed of escalation and history with the list operators both matter
The lookup runs in seconds. The remediation takes hours to days depending on the list and the root cause. The managed deliverability work we do for customers includes continuous monitoring of every sending IP against the active blocklists, immediate root-cause analysis when a listing appears (compromised account, list hygiene issue, ISP route problem, infrastructure misconfiguration), structured removal requests with the right documentation for each blocklist's process, escalation paths into the blocklist operators we work with regularly, and the post-listing hardening (rotating credentials, scrubbing lists, fixing authentication) that prevents the next listing.
If you are checking your own IP because something is wrong and a tool shows you the listing, the next conversation is what to do about it — and that conversation goes faster with someone who has dealt with the same listing on other customer infrastructure recently. The tool above gives you the data; the operator-level engagement is what turns the data into a recovered sending reputation.
Questions teams ask when running the blocklist lookup for the first time
My IP shows clean on every list. Does that mean my email is delivering?
+
Not by itself. A clean blocklist status is necessary for deliverability but not sufficient. Plenty of legitimately clean IPs land in spam because of authentication failures, low engagement, complaint rates, content patterns, or sending volume curves. Blocklists catch the worst senders; the more nuanced trust signals — DKIM signing, DMARC alignment, Postmaster Tools reputation, complaint rate under 0.1%, engagement-first warmup — are where deliverability is actually won or lost above the blocklist threshold.
Check your DMARC aggregate reports, look at the inbox placement in seed lists like GlockApps or MailGenius, monitor Gmail Postmaster Tools and Microsoft SNDS for the harder-to-see reputation data. A clean blocklist check just means you have not failed the easy test.
I'm on Spamhaus PBL but I run a real mail server. Why?
+
PBL is the Policy Block List — it lists IP ranges that ISPs have designated as "consumer-facing, should not originate direct mail." Cable and fiber broadband IPs land here by default. PBL is not a spam list; it is metadata about the IP range's intended use. If you happen to run a legitimate mail server on an IP your ISP has flagged for PBL (common with self-hosted infrastructure on residential or small-business connections), the listing is correct from the ISP's perspective but wrong for your use case.
Two fixes. First, ask your ISP to submit a PBL removal request for the specific IP — they can do this through their Spamhaus relationship. Second, go through Spamhaus self-service: spamhaus.org/pbl/removal lets you request removal with verification that you intend to send legitimate mail. For production sending infrastructure, the right longer-term answer is to host on dedicated business connectivity that does not land on PBL in the first place.
Why doesn't this tool check 70+ blocklists like some other checkers?
+
Because most of those 70+ lists do not matter. Many are decommissioned (SORBS in June 2024, NiX Spam in January 2026, WPBL in 2024). Some produce near-100% false positive rates (AUPADS). Some are operated by a single person with an opaque listing policy and inconsistent uptime. Some are scraped from already-aggregated sources and add nothing original.
The lists that matter for deliverability in 2026 are Spamhaus ZEN (and its sublists SBL, XBL, PBL), Barracuda BRBL, and SpamCop. Those are the ones Gmail, Microsoft, Yahoo, and enterprise mail systems consult. Listings on lists outside this group do not meaningfully affect your inbox placement. Checking against 70 lists makes a longer report but does not produce more actionable information.
Can I monitor this automatically?
+
For your own IPs, yes — but read the licensing terms first. Spamhaus restricts high-volume programmatic querying without a commercial license; the rough threshold is around 100,000 queries per day from the same IP, though they reserve the right to rate-limit earlier. Barracuda requires registration of querying IPs for production use. SpamCop allows reasonable automated monitoring without registration but rate-limits aggressive querying. For a sending operation monitoring a handful of IPs every hour, that fits comfortably inside the free-tier of every major list. For a SaaS product checking thousands of customer IPs, you need a commercial agreement with each provider.
The other option is using a paid monitoring service like Sendmarc, EasyDMARC, or a hosted DMARC platform — they have the licensing agreements in place and aggregate the data into a single dashboard. For our managed deliverability customers, that monitoring is part of what we run on their behalf.
Does the tool work for IPv6?
+
Not in the current version. IPv6 DNSBL coverage is incomplete — Spamhaus supports IPv6 queries against ZEN, but Barracuda BRBL and SpamCop do not. The IPv6 query format also requires expanding the address to all 32 hex digits, reversing nibble-by-nibble, and appending the zone (e.g. 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.zen.spamhaus.org). The result you get from IPv6 checking is less reliable than IPv4 because of the limited list coverage and because IPv6 reputation tracking at receiving mail systems is still less mature than IPv4. For now, treat IPv4 as the leading indicator.
How fast can I get delisted?
+
Depends on the list and on how clean your removal request is. SpamCop is fastest: 24-48 hours of clean traffic and the listing auto-expires. Barracuda is the fastest manual-process list: first-time removals typically clear in 12-24 hours when the form explains the root cause and the fix. Spamhaus is the most rigorous: XBL auto-clears once compromise is fixed, SBL takes 24-72 hours with a written explanation, repeat offenders or unclear remediation can stretch to weeks. PBL via ISP-led removal is typically 24-48 hours; self-service PBL removal is near-instant if the IP qualifies. Across the board, "fast" means "the same business day at best, several days at worst." A removal request submitted on Friday evening lands on Monday in most operators' queues.