Checking whether an IP is blacklisted is a lookup you can run yourself in a few seconds, once you know how the lists actually answer. The blocklists are not a website you visit, they are DNS zones you query, and the same reversed-address trick works against almost all of them. We check our own pool against these lists as part of keeping it clean, so this walks the exact method, how to read what comes back, and the two traps that make a check lie to you.
The fast way and the real way
The fast way is a checker tool: paste an address, and it queries dozens of blocklists at once and shows you which, if any, hold it. That is the right tool for a quick answer, and our proxy checker plus a fraud lookup through FFraud cover the network and reputation side of the same question.
The real way, worth knowing because it shows you what the tool is doing and lets you script it, is a direct DNS query. Understanding it also stops you trusting a tool that is reading a dead list or querying through the wrong resolver, both of which are common.
How a DNSBL lookup works
A DNS blocklist, or DNSBL, answers questions through ordinary DNS. To ask whether an address is listed, you do three things: reverse the order of the four octets, append the blocklist's zone name, and look up the result as an A record.
Take the address 203.0.113.5 and the Spamhaus Zen zone. Reverse the octets to 5.113.0.203, append the zone, and query:
# Listed? A 127.0.0.x answer means yes; no answer (NXDOMAIN) means no.
dig +short 5.113.0.203.zen.spamhaus.org
# Some lists publish a reason for a listing as a TXT record:
dig +short 5.113.0.203.zen.spamhaus.org TXT
If the address is listed, the query returns an address in the 127.0.0.x block, and the last number tells you which list inside the zone flagged it. If it is not listed, the lookup returns nothing, which in DNS terms is NXDOMAIN. That is the whole mechanism, and it is why a tool can check a hundred lists in the time a page takes to load: each one is a single DNS query.
Reading the return codes
The 127.0.0.x answer is not one thing. Spamhaus Zen bundles several separate lists, and the final octet says which one, which matters because they do not all mean the same thing.
| Return code | List | What it signals |
|---|---|---|
| 127.0.0.2 | SBL | The address is a known spam source |
| 127.0.0.3 | CSS | Part of the SBL for snowshoe and low-volume spam |
| 127.0.0.4 to 127.0.0.7 | XBL | An infected or compromised machine, or an open proxy |
| 127.0.0.9 | DROP | A hijacked or leased range operators are told to refuse outright |
| 127.0.0.10, 127.0.0.11 | PBL | End-user or dynamic space that should not send mail directly |
The distinction that trips people up is the PBL. A PBL entry is not a mark against the address, it is the internet provider stating the range is for ordinary customers, so on a home line or a residential proxy it is expected and even reassuring. The listings that actually mean a dirty address are the abuse ones, SBL, CSS, and XBL, and above all DROP, which means operators are null-routing the whole range. When you read a result, separate the abuse listings from the PBL rather than treating any 127.0.0.x as bad news.
The two traps that fake a result
A blacklist check is only as honest as the way you run it, and two mistakes quietly ruin one.
The first is the resolver. Spamhaus and several other lists refuse queries that arrive through large public resolvers such as Google's 8.8.8.8 or Cloudflare's 1.1.1.1, because those carry far too much volume to answer for free. Instead of a real result they return an error code in the 127.255.255.x range. If your lookup goes through one of those resolvers, every address returns the same error and you cannot tell listed from clean. Query through your own provider's resolver, or a resolver tied to a registered blocklist account, and the results become real.
The second is a dead list. Blocklists come and go, and a retired one does not announce itself, it simply answers every query as not-listed. SORBS, for years a standard list, shut down in 2024, so any address checked against it now comes back clean, which is worthless information dressed as a pass. This is why a green result from an unfamiliar list means little on its own. Trust the lists that are still maintained, and treat a clean result from a defunct one as no result at all. It is also the reason we run a positive control when we audit our own pool, checking an address we know is listed, so a "clean" run that is really a dead list gets caught.
What to do with a listing
Finding a listing tells you the address has a problem, and the fix depends on which kind you found.
If the address is one you control and the listing is on an abuse list, work out the cause before you request removal, because a delisting without a fix just relists. An open mail relay, a malware infection, or a compromised app on the connection are the usual reasons, and most lists publish a removal form once the cause is gone. If the listing is a DROP or a range entry, the address is dirty because of neighbors you do not own, and no removal form will help. That address is not salvageable for you, and the honest fix is a different one from a clean range. On our side that is the entire point of monitoring: an address that picks up an abuse listing leaves the rotation rather than reaching a customer, which is part of what keeps a pool clean.
When you just need a clean address
If you are checking a proxy exit rather than your own mail server, the goal is usually simpler: an address that reads clean to the site you are about to use. Check the exit first with the proxy checker for its network and country and FFraud for its fraud score, and if it is listed on an abuse list or reads as a hosting range, do not use it. Our residential proxies route through real consumer ISPs and are monitored against these lists, so they start clean rather than needing a delisting, and they run $0.44/GB pay-as-you-go with a balance that does not expire. Reading the address first is always cheaper than discovering the listing when a site refuses you.
Sources
- Spamhaus, "Understanding DNSBL return codes": the 127.0.0.x codes for the SBL, CSS, XBL, PBL, and DROP zones, and the public-resolver restriction.
- Spamhaus, "The Policy Block List (PBL)": why a PBL entry marks end-user space rather than abuse.
- The Spamhaus Project, "DNSBL usage and query methods": the reversed-octet query format used across DNS blocklists.