Check Domain on Email Blacklists (40+ DNSBLs)

Your newsletter was hitting inboxes last week. Today it’s going straight to Junk, open rates have collapsed, and your support queue is filling up with “did you send me something?” replies. The first question any experienced email admin asks is not “what changed in the template?” but “are we listed on a DNSBL?” A single listing on the wrong blacklist — Spamhaus ZEN, SpamCop, Barracuda — can tank deliverability for days. At IntoDNS.ai we check more than 40 public DNSBLs on every scan, and we see the same story weekly: a compromised WordPress install, a forgotten cron job sending newsletters, a shared-hosting neighbour, and suddenly your domain or sending IP is blocked by millions of mail servers. This guide walks through exactly how blacklists work, which ones matter, and how to get off them without making the problem worse.

What is a DNSBL, really?

A DNS-based blocklist (DNSBL) — sometimes called an RBL, for “real-time blackhole list” — is a distributed database of IP addresses or domains that have exhibited spam-like behaviour, published over ordinary DNS so that any mail server can query it in milliseconds during the SMTP handshake. When an email arrives, the receiving MTA (Postfix, Exim, Exchange, Mimecast-class gateways) takes the connecting IP, reverses it, appends the DNSBL zone, and issues a standard A query:

$ dig +short 25.2.0.192.zen.spamhaus.org A
127.0.0.2

$ dig +short 25.2.0.192.zen.spamhaus.org TXT
"https://www.spamhaus.org/query/ip/192.0.2.25"

Any response in the 127.0.0.0/8 range indicates a listing, and the specific last octet encodes the sub-list (e.g. Spamhaus ZEN returns 127.0.0.2 for SBL, 127.0.0.4 for XBL/CBL, 127.0.0.10 for PBL). NXDOMAIN means “not listed.” The same mechanism works for domain-based blocklists (URIBLs) by querying the hostname instead of the reversed IP. The protocol is described in RFC 5782.

The two kinds of listings that actually matter

Not all blacklists are created equal. A listing on an obscure community DNSBL from 2008 is a cosmetic concern; a listing on Spamhaus is a business emergency. Broadly there are two categories you should monitor.

IP-based blacklists (for your sending IPs)

These are the heavyweights of the industry and are used by a large share of corporate mail gateways and hosted filters. The high-impact zones we check on every scan include:

Spamhaus ZEN — the single most-queried DNSBL; combines SBL, XBL, PBL, DROP
Spamhaus SBL — known spam sources, manually curated
Spamhaus XBL — compromised machines, botnets, open proxies
Spamhaus PBL — end-user IPs that should never speak SMTP directly
SpamCop — community-driven, responds to individual reports
Barracuda Reputation Block List — widely used by Barracuda filtering appliances
SORBS — multiple sub-zones including DUHL and SPAM
UCEPROTECT Level 1/2/3 — aggressive, controversial, still consulted
Invaluement IVMURI / IVMSIP — premium commercial zone
Mailspike — combined reputation and bl.mailspike.net
PSBL — passive spam block list
0spam.org

Domain-based blacklists (for your domain and its links)

These target the From: domain, Reply-To, or any hostname found in the email body. Even if your sending IP is squeaky clean, a listed domain will tank your delivery:

Spamhaus DBL — the authoritative domain blocklist
SURBL multi — phishing, malware, and abusive domains
URIBL black/grey/red — widely consulted in ClamAV/SpamAssassin
Abuse.ch URLhaus — known malware distribution domains
Google Safe Browsing — not a DNSBL, but equivalent impact on links

A mature DNSBL check consults 40+ zones across both categories. Querying only Spamhaus and declaring victory misses roughly a third of real-world listings.

How listings actually happen

Most admins assume a listing means “someone reported my marketing email.” The reality is usually more mundane and more technical.

Compromised endpoints on your network

A compromised WordPress site with a vulnerable plugin starts sending phishing from your VPS. Within 24 hours the IP hits Spamhaus XBL — not because Spamhaus got a complaint, but because their spam traps observed traffic. The malware doesn’t care that you also run a legitimate mailbox on the same box.

Shared-hosting neighbours

On a shared IP at a budget VPS provider, your reputation is partly your neighbours’ reputation. If the other tenant gets owned, aggressive blocklists like UCEPROTECT Level 2 (“guilt by AS-number”) and Level 3 (“guilt by entire network”) will list you too. This is why quality-conscious senders insist on dedicated IPs or reputable ESPs.

Spam-trap hits

Spam traps are email addresses that should never receive legitimate mail: recycled abandoned accounts, addresses harvested from web pages and never subscribed, or pristine addresses that only ever appeared in leaked databases. Hitting one proves either (a) you bought a list or (b) your hygiene process is broken. Spam traps are the fastest path to a Spamhaus SBL listing.

Authentication failures at scale

Since the Gmail & Yahoo bulk-sender enforcement of February 2024, high-volume senders without valid SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) generate complaint rates above 0.3% and trigger Mailspike, Barracuda, and ultimately Spamhaus. Fix authentication before you chase delisting.

Snowshoe and domain-based patterns

Rotating through many cheap domains, registering them days before first use, or spreading volume thinly across IPs (“snowshoeing”) is a heuristic spammer tactic that list operators actively hunt for. Spamhaus DBL and SURBL pattern-match on this behaviour across thousands of domains simultaneously, so a legitimate launch of a new brand domain with a warm-up period that looks artificially fast can get listed simply because it looks statistically suspicious. Mitigate by warming new sending domains slowly over two to four weeks, keeping early volume low, and ensuring the new domain has a complete SPF/DKIM/DMARC stack before the first campaign.

Running the check yourself

You can query DNSBLs directly with dig. For an IPv4 address you reverse the octets and append the zone:

# Is 192.0.2.25 listed on Spamhaus ZEN?
$ dig +short 25.2.0.192.zen.spamhaus.org A

# And on SpamCop?
$ dig +short 25.2.0.192.bl.spamcop.net A

# IPv6 (reverse the nibbles and use the v6 zone if supported):
$ dig +short 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.dnsbl.example.org A

For domain blacklists, query the hostname directly:

# Is example.com listed on Spamhaus DBL?
$ dig +short example.com.dbl.spamhaus.org A

# And on SURBL?
$ dig +short example.com.multi.surbl.org A

Any 127.0.0.x response means listed; NXDOMAIN means clean. For production monitoring you should never hit the public servers directly at volume — Spamhaus will rate-limit open resolvers and commercial zones require paid data feeds. Use your own recursive resolver with a reasonable TTL cache.

What to do when you find a listing

Delisting is not “click the button.” Most DNSBL operators will un-list only after they see the underlying problem resolved. The sequence that works:

1. Identify the root cause before requesting removal

Check outbound mail queues (postqueue -p on Postfix, exim -bp on Exim) for anything you don’t recognise. Review web-server access logs for POST requests to old uploader or contact scripts. Run a malware scan on the host. If it’s a shared server, demand logs from your provider or migrate to a dedicated IP.

2. Fix your authentication stack

A listed IP with broken SPF, unsigned DKIM, and no DMARC record will be re-listed within a week of delisting. Before requesting removal, verify:

$ dig +short txt yourdomain.com | grep spf1
"v=spf1 include:_spf.google.com -all"

$ dig +short txt default._domainkey.yourdomain.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBi..."

$ dig +short txt _dmarc.yourdomain.com
"v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s"

3. Use the operator’s official delisting form

Each DNSBL has a specific process. Spamhaus uses its own Blocklist Removal Center and will ask you to confirm the underlying issue is resolved. SpamCop will auto-expire listings in 24–48 hours if no new reports arrive. UCEPROTECT charges for expedited removal of Level 2/3 listings — a practice many administrators find ethically dubious, but the only alternative is to wait out the expiry window (typically 7 days).

4. Never use a “delisting service” that promises same-day removal from Spamhaus

They don’t work. Spamhaus does not negotiate, and the only thing that gets an IP off SBL is a verifiable fix of the underlying behaviour.

Staying off the lists long-term

The domains and IPs that never get listed have a few things in common. All of them are boring operational hygiene, not clever tricks:

Tight list hygiene — confirmed opt-in only, immediate suppression of hard bounces, re-confirm inactive subscribers every 6–12 months. A clean list has complaint rates below 0.1%.
Dedicated sending IPs for volume mail — never share reputation with unknown parties. Warm up new IPs gradually over 2–4 weeks.
Full authentication stack — SPF with -all, DKIM signing on every outbound message, DMARC p=reject with aggregate reporting.
Egress firewall on port 25 — only your authorised mail servers should be able to talk SMTP outbound. Block everyone else at the edge and the botnet on your admin’s laptop never gets you listed.
Reverse DNS (PTR) records that match your HELO — a missing or generic PTR (1-2-3-4.cloud.example.com) is a soft deliverability signal many filters use.
MTA-STS and TLS-RPT — not DNSBL-related directly, but required by modern receivers; RFC 8461 defines MTA-STS and its absence correlates with weaker reputation scoring.
Active monitoring — scan your sending IPs and domains daily and alert on any 127.0.0.x response.

Monitoring patterns that work

Two monitoring patterns consistently catch listings before they become customer-facing incidents; both are cheap to implement.

Outbound queue-depth alerting

A sudden spike in queued mail on your MTA is often the first symptom of a listing: receivers start issuing 4xx greylisting responses or 5xx rejects, and messages accumulate in the queue. Alert on any sustained queue-depth above your baseline and your team will frequently learn about a DNSBL listing before the listing becomes visible externally. On Postfix this is a single Prometheus exporter; on Exim a cron job parsing exim -bp into a metric.

Seed-mailbox delivery testing

Maintain a small set of real mailboxes at every major receiver — Gmail, Outlook, Yahoo, iCloud, Proton, plus one or two regional providers for your market — and send a scheduled test message from each of your sending IPs every hour. Parse the Authentication-Results header, track placement (inbox vs spam vs rejected), and alert on any regression. Seed mailboxes detect the silent “delivered to spam” failure mode that a pure DNSBL check will miss entirely, because plenty of providers throttle or filter reputation-poor senders without listing them on any public zone.

Scan once a day, sleep easier

The difference between a 4-hour deliverability incident and a 4-day one is detection speed. A listing that you notice within an hour can be resolved before most of your subscribers ever see a delayed newsletter; a listing you find out about from a customer complaint has already cost you a week of engagement.

IntoDNS.ai runs a 40+ DNSBL sweep on every scan, covering all the major Spamhaus zones, SpamCop, Barracuda, SORBS, Mailspike, SURBL, URIBL and the long tail of community lists, and flags the listings that actually move deliverability. Scan your domain right now, bookmark the result, and re-run it on a schedule. It takes fifteen seconds and it’s the single highest-ROI monitoring you can put in place on your email stack in 2026.