Blacklist Check

Test an IP or domain against 15+ DNS-based blocklists (RBLs).

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is Blacklist Check?

DNS-based blocklists (DNSBLs, often called RBLs — Real-time Blackhole Lists) are queryable databases of IPs and domains known for spam, malware, phishing or other abuse. When your mail server tries to deliver to Gmail and gets rejected with 554 5.7.1 Service unavailable; Client host blocked using Spamhaus, you've been flagged by a blocklist. Same mechanism is used for IP reputation scoring at the network edge — bad reputation, lower deliverability.

This tool queries 15+ of the most-trusted public blocklists in parallel against any IP or domain and reports listing status per blocklist with the categorisation (e.g. spam, exploit, dynamic IP space). It's how you find out why your mail bounces or your outbound traffic gets throttled, before the customer complaint escalates.

How it works

DNSBL queries are DNS lookups in disguise:

1Reverse the target IP — For IPv4 1.2.3.4, we query 4.3.2.1.<dnsbl-zone>. For domain blocklists (SURBL, URIBL), we query <domain>.<dnsbl-zone> directly.
2Issue an A record query — Standard A lookup. If the target is listed, the blocklist returns a 127.0.0.x IP where the last octet indicates the listing category (e.g. 127.0.0.2 = spam, 127.0.0.4 = exploit, varies by blocklist).
3Optionally fetch the TXT record — Most blocklists also publish a TXT record at the same name with a human-readable reason and a link to a removal portal.
4Aggregate across blocklists — We run all 15+ queries in parallel and report a unified table: blocklist name, listed yes/no, category code, removal URL, query latency.

Lookup is read-only and zero-impact on the blocklist operators — DNS queries are exactly what these services are designed to handle.

When you'd use it

"My mail is bouncing — am I blacklisted?"

Recipients reject your mail with vague "550 spam" errors. Check your sending IP against major blocklists (Spamhaus SBL/XBL, Barracuda, SORBS). If listed, you'll see the category code — 127.0.0.2 is usually "spam source," 127.0.0.4 is "exploit/compromised." Follow the delisting process for each listed blocklist.

Bought a new IP from a hosting provider

Cloud providers recycle IPs. The one you just got might have been used by a spammer a week ago and be carrying their reputation. Always check fresh IPs against major blocklists before sending real mail from them. Saves a week of "why is our deliverability terrible."

Investigating a domain reputation issue

Customer complains your tracking link domain is blocked. Check the domain against URIBL and SURBL (domain-level blocklists used by spam filters). If listed, find out which blocklist and request review with evidence of legitimate use.

Periodic deliverability audit

Even legitimate senders get listed occasionally — shared infrastructure, compromised customer, snowshoe spam pattern. Quarterly check across major blocklists catches issues before they cause customer-visible delivery failures.

Investigating customer abuse complaints

Your platform forwards a customer's emails. A recipient ISP complains about spam from your IP. Run a blocklist check on your sending IP. If listed, the listing usually shows the spammer's pattern and timeframe — useful for tracing back to which of your customers caused it.

Reading the result

Listed / not listed

Boolean for each blocklist. If listed, the response code from the DNS query indicates why — most use 127.0.0.x where x is the category. Spamhaus, Barracuda, SORBS, Spamcop each have their own coding; the tool decodes them where possible.

Why some blocklists are more important than others

Spamhaus (SBL, XBL, PBL, ZEN) is the de facto standard — most major mail providers consult it. Being on Spamhaus is a serious problem. Smaller blocklists (UCEPROTECT, some regional lists) have less impact — only a few mail providers consult them, so a listing there might still let mail through to most recipients.

Category codes

Vary per blocklist. Spamhaus SBL = static-source spam, XBL = exploit/compromised host, PBL = dynamic IP space that shouldn't send mail directly. Knowing the category matters — getting off PBL ("we found you in a residential IP block") is different from getting off SBL ("you actually sent spam").

Removal URL

Most blocklists publish a delisting form. Spamhaus is automated for low-listing cases; SORBS is harder; some are unresponsive. The TXT record from the listing query usually contains the URL. Process: fix the underlying issue (close open relays, secure compromised hosts, stop sending unsolicited mail), then submit the delisting request.

Common pitfalls

"I'm listed but I'm not sending spam — what now?"

Three usual reasons: (1) Shared IP pool — your cloud provider's IP range is listed because of someone else; you might be collateral damage. (2) Compromised host — something on your network was used to relay spam without your knowledge; investigate logs. (3) PBL listing — your IP is in dynamic/residential space; most mail providers ignore mail from such ranges. Move to a static IP block.

Mail rejected but blocklists show clean

Not all spam filtering is blocklist-based. Major providers use proprietary reputation systems (Gmail's domain reputation, Microsoft's SNDS) that don't appear in public blocklists. Check sender reputation in Google Postmaster Tools and Microsoft SNDS. Public blocklists are one input among many.

Removed from a blocklist but mail still bouncing

Blocklist caches at recipient mail servers. After delisting, recipient mail servers may still have your IP cached as bad for hours-to-days. Wait for cache expiry (usually 24h max) or contact the recipient's postmaster.

Different lookup results for the same IP minutes apart

DNS caching. Your local resolver caches the negative answer; subsequent listing changes won't show up until cache expires. We use cache-bypassed queries, so our results are always current.

Run Blacklist Check on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.

Start free

Frequently asked questions

How many blocklists exist and which ones matter?

Hundreds. The ones that matter for mail deliverability: Spamhaus ZEN (SBL+XBL+PBL composite), Barracuda, Spamcop, Sorbs. For URI blocking: SURBL, URIBL. We query the ~15 that have measurable impact on real-world deliverability and skip the long tail.

How do I get removed from a blocklist?

Each blocklist has its own removal process. Step one: fix the underlying problem (close open relays, kill compromised accounts, stop the spam pattern). Step two: submit a delisting request via the blocklist's portal — URL comes from the TXT record at the listing. Step three: wait. Some are automated (Spamhaus auto-delists within hours of a clean request), some take days, some require human review.

Will being on one blocklist hurt my mail deliverability?

Depends on which one and which recipient. Spamhaus listing = significant impact (most major providers consult Spamhaus). UCEPROTECT listing = minimal impact (few providers use it). Mail delivery uses many signals; a single listing usually hurts but rarely fully blocks.

Can I be blocklisted for sending too much legitimate mail?

Yes — high-volume senders without proper authentication (SPF/DKIM/DMARC) or with sloppy list hygiene (sending to unverified addresses, ignoring unsubscribes) can trigger listing. Volume itself isn't the problem; volume + signals of unwanted mail is.

What's the difference between an IP blocklist and a domain blocklist?

IP blocklists (Spamhaus, Barracuda) list sending IP addresses. Domain blocklists (URIBL, SURBL) list domains found in spam content — they're queried against URLs in the message body, not against the sending server. You can be IP-clean but content-blocked if your tracking domains end up in spam content.

Are blocklists case-sensitive for domains?

No — DNS itself is case-insensitive, so blocklist queries normalise the domain. Listing for EXAMPLE.com and example.COM are the same lookup.

Should I check my domain or my IP?

Both. IP for SMTP-level reputation (the sending server's reputation). Domain for content-level filtering (URLs in your message body). Domain reputation is increasingly important — major providers like Gmail weigh sender domain reputation heavily.

How often should I check my IPs/domains?

Daily for production mail-sending infrastructure. Listings happen suddenly (one customer reports your IP, you're listed within minutes). Catching them early lets you start delisting before they hurt deliverability at scale. Most teams automate this with continuous monitoring.