DNS Blacklist Checker
Mail landing in spam starts here more often than anywhere else: a blacklist listing on the sending IP or the domain. This checker resolves your domain, asks ten IP-based lists (Spamhaus ZEN, Barracuda, SpamCop, CBL, PSBL, UCEPROTECT, SORBS and more) about each of its IPv4 addresses, and asks three domain-based lists (Spamhaus DBL, URIBL, SURBL) about the domain itself — from this server, through the server's own resolver, the way a receiving mail server would ask.
Want this watched continuously? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
What the check measures
Blacklists are the internet's shared memory about bad mail. Each list operator watches spam traps, reports and sending behaviour, and publishes the offenders as a DNS zone: to ask "is this sender listed?", a mail server looks up a special name — the sender's IP address reversed, plus the list's zone — and reads the answer. An address returned means listed, and the exact 127.x code often says why (Spamhaus, for example, uses different codes for its spam, exploited-host and policy sub-lists). No answer means not listed. The page calls GET /api/check/dnsbl on sysosx's server, which performs those lookups for nine IP zones per address plus three domain zones, in parallel, and caches the result for ten minutes.
The third answer is the one most checkers hide: error. Lists time out, refuse queries from the wrong resolver, or fail outright — and a checker that folds "no answer because the query failed" into "not listed" is manufacturing clean results. This one does not. Every zone reports listed, not listed, or error, the error keeps its reason (timeout, server failure, or an operator's query-source refusal code), and the summary counts errors separately. A result with errors is a partial picture and is labelled as one: a list that did not answer has no verdict, in either direction.
Reading a result
Weight the listings by the list. A listing on Spamhaus ZEN, Barracuda or SpamCop will affect delivery at a large share of the world's mail servers — treat those as the fire. Listings on smaller or aggressive lists (UCEPROTECT's upper levels, backscatter-only lists) matter less and sometimes reflect a neighbour's behaviour more than yours; read the operator's own explanation before panicking, and note that a Backscatterer listing, specifically, means your server is believed to send bounce messages to forged addresses — a configuration flaw, not a spam operation. If the domain-based lists flag the domain itself, that follows the domain to any IP: changing servers will not help until the domain listing is resolved. And if your mail is sent by a big provider rather than from your own server, expect the IP section to be about your web server — mostly irrelevant — and the domain section to be the part that counts.
The companion check is the email deliverability check: blacklists judge your reputation, SPF/DKIM/DMARC prove your identity, and spam folders are usually the product of both. The full story is in our guide, why your email lands in spam — how the two halves combine at the moment a receiving server decides. For where a name points rather than what the lists say about it, use the DNS propagation checker.
Frequently asked questions
What is a DNSBL, and what does being listed actually mean?
A DNSBL (DNS blacklist) is a list of IP addresses (and, in DBLs, domain names) that its operator believes send or enable spam, published as a special DNS zone. Mail servers consult these lists when mail arrives: a listing is a strong negative signal that can mean rejection or the spam folder, depending on how the receiving server weights that list. Being listed is not a legal judgement and lists differ wildly in how they gather evidence — a listing on Spamhaus ZEN matters almost everywhere; a listing on a small list may matter almost nowhere. This tool reports each list separately for exactly that reason.
Why does the tool check my domain's IP addresses rather than the domain?
Because that is how the lists work: mail is sent from an IP address, and IP-based lists are keyed by that address. This tool resolves your domain to its IPv4 addresses and checks each one. One warning follows: if your website and your mail share an IP (common on small hosting), the address checked is the right one; if your mail is sent by a provider — Google, Microsoft, a newsletter service — the sending IPs are the provider's, not your domain's, and they will not appear here. In that case the domain-based lists (Spamhaus DBL, URIBL, SURBL) are the part of the result that applies to you.
What does a zone "error" mean? Is my domain clean or not?
An error means that list did not answer — a timeout, a server failure, or an operator refusal (Spamhaus, for instance, refuses queries that arrive through public resolvers, and returns a special code saying so). An error is NOT a clean result: the honest reading is "this list's verdict is unknown". The tool never folds an error into "not listed", and the summary counts errors separately so you can see how much of the picture is missing. Try again later; if one zone errors persistently while others answer, treat its absence from the result as a gap, not a pass.
My IP is listed. What do I do?
First, find out why: most lists publish a lookup page explaining the listing — follow the list operator's own link from a search for the zone name and your IP. The usual causes are a compromised account or server sending spam, a vulnerable form or open relay, or inheriting an address a previous owner abused. Fix the cause first; delisting requests made before the fix are usually refused or instantly relisted. Then request removal through the operator's process — reputable lists delist quickly once the traffic stops — and expect some lists to expire entries automatically over days. While you wait, the deeper fix is the one in our guide: working SPF, DKIM and DMARC, which is what receivers fall back on when list data is ambiguous.
Why do the queries go through this server's resolver instead of Google or Cloudflare DNS?
Because major list operators, Spamhaus above all, deliberately refuse queries that arrive via public resolvers — the answer to a blocked query is a special 127.255.255.x code, not listing data. This checker asks through the server's own resolver, the way a real mail server would, so the answers are the answers a receiving server would get. When a zone still refuses, the result says "error" and shows the code rather than dressing the refusal up as data.