How a DNSBL check actually works
A DNS blocklist (DNSBL, sometimes RBL) is not a database you query over an API. It is an ordinary DNS zone. To ask whether 198.51.100.10 is listed on bl.example.net, you reverse the octets to 10.100.51.198, prepend that to the zone, and resolve 10.100.51.198.bl.example.net as an A record. If the zone returns an address inside 127.0.0.0/8, the IP is listed and the last octet is a coded reason. If it returns NXDOMAIN, the IP is not listed. That is the whole protocol, and it is why a blocklist lookup costs a receiving mail server almost nothing.
The return code carries meaning that varies by operator. SpamCop only ever answers 127.0.0.2. SpamRats uses 127.0.0.36 for missing rDNS and 127.0.0.38 for dynamic-looking rDNS. UCEPROTECT uses 127.0.0.2 for Level 1 (the single IP) and different zones for Level 2 and 3 (the netblock and the ASN). Many zones also publish a TXT record at the same name containing a human-readable reason and a delisting URL, which this tool fetches whenever a listing is found.
Which lists this tool checks — and which it deliberately does not
Ten zones are queried on every run, chosen because they are widely consulted by real receivers and because their operators permit public query traffic:
Read the full explanation of email blacklist check results ↓Show less ↑
| Zone | What it lists | Delisting |
|---|---|---|
| b.barracudacentral.org | Barracuda Reputation Block List — spam observed by Barracuda appliances | Free web form, usually fast |
| bl.spamcop.net | IPs reported by SpamCop users; entries age out automatically | Self-service, expires in ~24h if reports stop |
| dnsbl.sorbs.net | SORBS aggregate zone (open relays, proxies, spam sources) | Web form |
| spam.dnsbl.sorbs.net | SORBS spam-source-only subset | Web form |
| dnsbl-1.uceprotect.net | UCEPROTECT Level 1 — the individual IP | Free after 7 quiet days, or paid express |
| dyna.spamrats.com | IPs whose rDNS looks like a dynamic/residential pool | Fix rDNS, then request removal |
| noptr.spamrats.com | IPs with no PTR record at all | Publish a PTR, then request removal |
| all.s5h.net | s5h.net aggregate spam and abuse sources | Email request |
| psbl.surriel.com | Passive Spam Block List — spamtrap hits only | Self-service, immediate |
| bl.blocklist.de | IPs reported for SSH/mail/web brute force in the last 48h | Self-service, auto-expires |
Two other honesty notes. First, a zone that answers SERVFAIL, REFUSED, or times out is shown as no answer, never as "not listed" — several operators throttle busy resolvers, and treating a refusal as a pass would be a lie. Second, SORBS has been largely dormant since 2024; it stays in the list for historical continuity but rarely returns a listing today.
How to read your result
- Not listed on all ten — good, but not a clean bill of health. Gmail, Microsoft, and Proofpoint run their own internal reputation systems that no public list exposes. If mail is still being deferred, the cause is content, volume, authentication, or a private reputation score.
- Listed on one aggressive list (UCEPROTECT Level 1, blocklist.de) — usually low impact. Few large receivers consult these. Fix the underlying cause, but do not panic.
- Listed on Barracuda, SpamCop, or PSBL — act today. These are consulted by a large number of corporate gateways, and PSBL listings mean a spamtrap address received mail from you.
- Listed on noptr.spamrats.com — you have no PTR record. That is a five-minute fix with your hosting provider and it also fixes rejections from Microsoft and Yahoo independently of the listing.
- Listed on several lists at once — assume compromise. A hacked CMS, a leaked SMTP credential, or a forwarding loop is sending through you. Find and stop the source before requesting any delisting; relisting after a premature removal is slower to reverse.
Common causes, in the order you should check them
- A compromised account. Check your mail queue and your MTA logs for a single authenticated user sending thousands of messages. Rotate the password, then flush the queue.
- A vulnerable web application. PHP
mail()calls from a compromised contact form are the classic cause on shared hosting. Look for messages whose envelope sender is the webserver user. - A shared or recycled IP. If you moved to a VPS or a new cloud instance, you inherited whatever the previous tenant did. This is common enough that reputable providers will re-assign an address on request.
- Missing or generic rDNS.
203-0-113-10.dsl.example.netreads as a residential connection to every filter on the internet. Set a PTR that matches your HELO name — see the reverse DNS lookup tool. - A forwarding loop or mailing list. Forwarded spam is still spam from your IP's perspective. Deploy SRS or stop forwarding unfiltered mail.
- Legitimate bulk mail without consent. Purchased lists hit spamtraps. A PSBL listing is nearly always this.
The delisting procedure that actually works
Fix the cause first and verify it is fixed — most lists will refuse a second removal request within a cooling-off window, and some (notably UCEPROTECT) charge for expedited removal after a repeat listing. Then submit the removal form linked next to each listing above. Expect self-service lists (SpamCop, PSBL, blocklist.de) to clear within minutes to 24 hours, Barracuda within a business day, and SORBS/UCEPROTECT to take longer.
Do not stop at delisting. A listing is a symptom; large receivers keep their own memory of your IP for weeks after the public list clears. Warm the address back up with low, consistent volume to engaged recipients, and confirm your authentication is intact with the deliverability snapshot before resuming normal sending.
Doing the same check from your terminal
Every query this tool makes is a plain dig. To check 198.51.100.10 against Barracuda, reverse the octets and resolve:
# Is 198.51.100.10 listed? Reverse the octets, append the zone.
dig +short 10.100.51.198.b.barracudacentral.org A
# An answer in 127.0.0.0/8 means listed; empty output means not listed.
# Fetch the operator's reason when a listing is returned:
dig +short 10.100.51.198.b.barracudacentral.org TXT
# RFC 5782 self-test — every conformant zone MUST list 127.0.0.2
# and MUST NOT list 127.0.0.1. Use this to prove your query path works:
dig +short 2.0.0.127.bl.spamcop.net A # expect 127.0.0.2
dig +short 1.0.0.127.bl.spamcop.net A # expect no outputThat RFC 5782 pair is worth remembering. If 2.0.0.127.<zone> returns nothing, your query is not reaching the zone at all — you are probably behind a resolver the operator blocks — and any "not listed" result you got is meaningless. This tool runs its own queries through the system resolver for exactly that reason: several DNSBLs return REFUSED to queries arriving from 8.8.8.8 and 1.1.1.1.
Where blacklists fit in the wider picture
Blocklists are a coarse, IP-level signal. They answer "has this address behaved badly recently", nothing more. Modern filtering weighs domain reputation, authentication alignment, engagement, and content far more heavily. If you are diagnosing a delivery problem, run the full deliverability snapshot first — a missing DMARC record or an SPF PermError explains far more rejections than a UCEPROTECT listing ever will. Then confirm the server is reachable with the SMTP connection test and that your MX records point where you think they do.