Blacklist Checker

Query the blocklists a receiving mail server actually consults, and see which ones answer for your address or domain, and what they say about it.

Secure server processingEmailWorkingNo account needed

What this tool does

Blacklist Checker performs the lookup a receiving mail server performs when it decides whether to accept your connection. For an IPv4 address the octets are reversed; for an IPv6 address every nibble is reversed with the same handling that lets an IPv4-mapped address (::ffff:1.2.3.4) resolve as the IPv4 host it actually is; for a domain the name is used as sent. That prefix is queried against each zone in parallel. Any zone that answers with an A record at all is treated as a listing; the tool then asks that same name for its TXT record, which is where a list normally explains the reason and points at its own removal page.

IP addresses are checked against twelve zones: Spamhaus Zen, SpamCop, Barracuda, SORBS (both its main and spam-specific lists), PSBL, UCEPROTECT, the CBL, Mailspike, DroneBL, S5H and the Manitu list. A domain is checked against five: Spamhaus DBL, SURBL, URIBL, NordSpam and SpamEatingMonkey. It is a deliberate set rather than a sweep of every blocklist in existence — these are lists that receiving servers commonly consult — and a clean answer from all of them is not a clean answer from the hundreds that also exist. It is also silent on the reputation systems Gmail and Outlook run internally, which publish nothing and account for a large share of the mail that is refused without ever appearing on a public DNSBL.

Codes are reported as they arrive, not translated. Spamhaus Zen is several lists behind one zone and uses the final octet to say whether the match came from SBL, XBL or PBL; SORBS and the others each document their own numbering. One trap is worth knowing about: answers in the 127.255.255.x range are not listings at all but errors, and usually mean the resolver making the query is one the list declines to serve. Because any answer counts as a hit here, a reply like that is still marked as listed, so read the codes before believing the count.

The lookup happens on the server, because a browser cannot make a DNS query of any kind. The address or domain you type is sent over an encrypted connection and removed, along with the report, when the retention window expires — six hours unless the operator has changed it. Two limits shape how the result should be read. A private or reserved IP address (10.0.0.0/8, 192.168.0.0/16 and the rest) is refused before it ever leaves your browser, since blocklists only track public addresses. And every DNS failure is recorded as not listed: a timeout, a refusal, or a list that answers only resolvers registered with it produces the same line as a genuine all-clear.

How to use it

  1. Enter an IPv4 address, an IPv6 address, or a domain. The field accepts any of the three and detects which one you gave it. An IPv4-mapped IPv6 address is read as the IPv4 host it represents, and a private or reserved address is rejected immediately with the reason, before any query is made.
  2. Run the check. IP addresses are queried against twelve zones, domains against five, all in parallel. A zone that refuses the query, times out, or simply holds no record is recorded the same way as one that answers with nothing.
  3. Read the table. Each row is one blocklist: Listed or Not listed, the A records it returned if any, and the TXT reason if the list published one. A summary line above it gives the count — Listed on N blocklists, or Clean — and rows where the address is listed are highlighted so they are not missed in a long table.
  4. Keep the report if you need it. The underlying JSON — the address, the type detected, and every zone's raw answer — is still available as a download named rbl- followed by the address. It is the kind of thing worth attaching to a delisting request or to a ticket with the host that assigned you the address.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

Mail is bouncing with a reputation notice

Rejection messages that mention reputation usually name the list that caused them. The check shows whether that zone still answers for your address, and the TXT record normally carries the removal URL.

Taking over a new server or a recycled IP

An address reassigned to you can arrive carrying someone else's history. Checking it before the first campaign goes out is cheaper than discovering the inheritance from your bounce rate.

Investigating an address from your logs

One IP hammering a login endpoint is easier to judge with context. A hit on the exploit side of Spamhaus Zen suggests a compromised machine rather than a customer with a forgotten password.

Checking a domain used in a phishing report

A domain-side listing on Spamhaus DBL or SURBL usually means the domain itself — not just an IP behind it — has been used in spam or phishing links, which is a different and often more durable problem than a single address getting caught up in one.

Confirming that a delisting took effect

Removal pages confirm the request, not the result. Re-running the check is how you see the record has actually dropped out of the zone.

Questions

Does this run in my browser?
No. Browsers have no way to make DNS queries, so the address or domain is sent over an encrypted connection to the OmniKitly server, which resolves the zones and returns the report. The job record and the report file are removed together when the retention window expires.
Can I check a domain rather than an IP?
Yes. Enter the domain and it is checked against the domain-side blocklists — Spamhaus DBL, SURBL, URIBL and the others — which track domains and URLs used in spam and phishing, a different signal from an IP's own sending reputation.
Does a clean result mean I am definitely not blocked?
No. It means these blocklists returned nothing for that address or domain. A refusal, a timeout, or a list that only serves resolvers registered with it is indistinguishable here from a genuine all-clear, and hundreds of other lists are never queried. Read it as no evidence of a listing rather than proof of a good reputation.
My address is clean but mail is still rejected — why?
Public lists are only part of what a receiving server weighs. Authentication (SPF, DKIM and DMARC), sending volume, complaint rates and the content itself all feed reputation systems that are internal to the provider and publish nothing a DNSBL lookup can see.
What do the numbers next to a listing mean?
They are the A records the zone returned. Operators answer inside 127.0.0.0/8 and each documents its own scheme, with the last octet typically identifying which sub-list matched. The tool neither checks the range nor interprets the value — it passes back whatever arrived, so the list's own documentation is what reads it.
Can this get an address delisted?
No. Removal is handled by the list operator through the page its TXT record names, and it rarely holds unless the cause — an open relay, a compromised mailbox, a spam trap hit — has been dealt with first.
What about private addresses like 192.168.0.10?
Those are refused before the check ever runs. Blocklists index public addresses only, so there is nothing a query against one could tell you — the tool says so directly rather than sending a query that could only ever come back empty.

Related tools