How to check if an IP is on a blacklist

If your outgoing emails are mysteriously failing to arrive, if your home connection has suddenly stopped reaching certain websites, or if a server of yours is being rejected by a service it used to talk to fine — there's a decent chance your IP address is on a blacklist somewhere.

These lists are how the internet polices abuse at scale. They're imperfect, sometimes maddeningly so, and they affect millions of IPs at any given moment, often without their owners' knowledge. If you operate any kind of server — or if you ever try to send mail from a non-standard connection — knowing how blacklists work and how to check them is part of the job.

What a blacklist actually is

A blacklist in this context is a published list of IP addresses flagged as sources of unwanted traffic. The categories vary by list: spam, mail abuse, malware-infected hosts, brute-force login attempts, automated bot behaviour, open proxies, compromised devices.

Some lists are run by major anti-abuse organisations — Spamhaus and Barracuda are the names you'll see most often, with millions of mail servers consulting them in real time. Others, like SORBS, have shut down in recent years; the zones may still resolve, but the data is stale. Some lists are run by individual hosting providers and email operators who maintain their own internal lists for their own systems. Some are crowdsourced from honeypots and abuse reports submitted by the wider community.

There's no single authoritative blacklist, and no central registry. Each list has its own criteria for inclusion, its own delisting process, and its own reputation among the operators who consult it. Being listed on Spamhaus's main list is a serious problem; being listed on some obscure forum's pet blocklist may have no real-world consequences at all.

The technical mechanism — RBLs

The mechanism that makes these lists work at internet scale is called an RBL — depending on who you ask, that stands for Real-time Blackhole List, Real-time Blocklist, DNS Blocklist (DNSBL), or DNS Blackhole List. They're all the same thing.

The clever part is that RBLs are delivered over DNS. To check whether an IP is on Spamhaus's list, you don't download the list (which would be enormous and constantly changing). Instead, you ask DNS a question — and the answer tells you whether the IP is listed.

The trick is the same backwards-IP-with-suffix encoding that the reverse DNS guide covered. To check 192.0.2.50 against a list hosted at example-rbl.org, you query the DNS for 50.2.0.192.example-rbl.org. The four octets are reversed and appended to the list's domain. If the IP is listed, the DNS server returns an answer — typically an IP starting with 127.0.0.x, where the last octet encodes which sub-list or category the entry belongs to. If the IP is not listed, the DNS server returns NXDOMAIN — the standard "no such name" response.

This means a mail server checking incoming connections can do an RBL lookup in the same time it takes to do any DNS query — a few milliseconds. The list operator doesn't have to send anyone a multi-gigabyte file; they just publish the relevant entries as DNS records and let the existing DNS infrastructure handle distribution and caching.

Why your IP might be listed

There are five common reasons an IP ends up on a blacklist, and most of them have nothing to do with whoever currently uses the address.

A compromised device on your network. The most common cause for residential users. A malware-infected laptop, an unpatched IoT camera, a router with default credentials — any of these can quietly send spam or attack other hosts in the background. The traffic appears to come from your public IP because everything behind your router shares it (the public vs private IP guide covers why). The list operator sees abuse from your IP and lists it. You see your email bouncing and have no idea why.

Shared or rotating ISP IPs. Residential ISPs frequently reassign IPs between customers. The IP you got assigned today might have been listed yesterday for behaviour by the previous occupant. This is especially common with mobile network IPs, which rotate aggressively. Not your fault, still your problem — and very hard to delist when you don't actually own the IP.

VPN and proxy ranges. Many commercial VPNs run on a handful of well-known data-centre Autonomous Systems. Mail providers and access-control systems often blacklist these ranges by default, on the assumption that any traffic from a hosting-provider ASN to a residential service is suspicious. Legitimate VPN users get punished by association.

A misconfigured email server. If you self-host email — running your own postfix or exim or whatever — a misconfigured SPF/DKIM/DMARC setup, an unintentionally open relay, or even a single compromised user account that briefly sent spam can land your server on a list. The window between mistake and listing is sometimes hours.

Cloud server ranges. AWS, DigitalOcean, Linode, Hetzner, OVH — some blacklists list entire cloud-provider IP ranges by default, on the not-unreasonable theory that a meaningful share of cloud VMs are either compromised or being used for spam at any given moment. If you spin up a fresh cloud server and try to send mail from it, your IP may already be listed before you've sent your first message. This is one of the biggest reasons "send transactional email from your own server" has become genuinely difficult.

Checking by hand

The manual way to check an IP against an RBL uses dig or nslookup. Take an IP — say 192.0.2.50, a documentation-reserved address from RFC 5737 — and reverse the octets so 192.0.2.50 becomes 50.2.0.192. Then append the RBL's domain. Most major lists use a domain like zen.spamhaus.org, b.barracudacentral.org, or similar.

The query looks like:

dig 50.2.0.192.zen.spamhaus.org

If the IP is listed, you'll get an answer record with an IP starting 127.0.0.x — the response format is the same across DNSBLs, even though each list assigns its own meaning to the final octet. Spamhaus's combined zone, for example, returns 127.0.0.2 for its main block list and 127.0.0.10 for policy listings (dynamic or residential IPs that shouldn't be sending mail directly). Because the codes differ from list to list, a checker's job is to interpret them per list rather than just report “listed.”

If the IP is not listed, you'll get NXDOMAIN:

;; ANSWER SECTION:
;; (no answer)

;; AUTHORITY SECTION:
zen.spamhaus.org.   ...   SOA   ...

;; status: NXDOMAIN

That's the all-clear from that particular list — though dozens of other lists exist, each with its own domain and its own criteria. Checking by hand against every relevant list is tedious enough that aggregator tools have built a whole category around it.

Checking the easy way

Several third-party services exist that check an IP against dozens of major blacklists in parallel and present the results in one view. They're useful for triage when you suspect a problem and want fast coverage.

The IP Blacklist Check tool does exactly this — it queries a curated set of DNSBLs in parallel from the edge and groups results by tier so you can see at a glance which lists are most likely to affect deliverability. Plug your IPv4 address in there, or hit the "My IP" button to auto-detect, and you'll get the full picture in a second or two.

What to do if your IP is listed

Three steps, in order. Don't skip step one.

Identify the cause first. Before you request delisting, figure out why you got listed. Was a device on your network compromised? Did your mail server briefly misconfigure itself? Is your provider's range routinely listed? Most lists will re-add you within hours if the abusive behaviour continues, and repeated listings make the second and third delisting harder than the first. Fix the source, then ask for the listing to be removed — not the other way around.

Contact the list operator. Each list has its own delisting process. Spamhaus and most other major lists have well-documented forms; you fill in your IP, check a few boxes confirming you've fixed the underlying issue, and most legitimate cases are reviewed within a day or two. Some smaller, more poorly maintained lists are harder — sometimes there's no working contact at all, and the list outlives the people who originally maintained it.

Wait it out. Many lists auto-expire entries after a set period — 24 hours, 7 days, 30 days — if no further abuse is detected. If you've fixed the underlying problem and the list operator's process is slow, sometimes the fastest path is patience. This is especially true for transient listings caused by a brief incident rather than ongoing abuse.

The IPv6 footnote

Blacklisting IPv6 is harder than blacklisting IPv4. The address space is so vast that listing individual /128 addresses is mostly pointless — abusers can rotate through addresses faster than the list updates. The (IPv6 explainer covers exactly how vast: a single /64 subnet contains more addresses than the entire IPv4 internet several times over.)

Most RBLs that handle IPv6 list at the prefix level — typically a /64 or larger — which catches the abuser but also broadly punishes everyone else assigned an address from the same prefix. This is one of several reasons IPv6 email reputation is still messier than IPv4: the granularity is wrong for individual-host policy, and the alternatives all involve trade-offs. The space is too big to list individuals, but listing prefixes hurts innocents. Most of the industry is still working out what good IPv6 reputation looks like.

One last thing

Blacklists are imperfect tools. They produce false positives, they're inconsistently maintained, and some of them survive long after their useful life. If you've been wrongly listed, the experience can be genuinely frustrating — especially when the listing is on some obscure list with a broken contact form.

But they're also one of the few mechanisms that scale to internet-sized abuse problems. The alternative — every mail server reasoning about every incoming IP from scratch — doesn't work at the volumes the modern internet produces. Knowing that lists exist, knowing how to check them, and knowing what to do if your IP is on one is part of being a competent internet citizen, especially if you run any kind of server.