How to check if a mail server IP is blacklisted: DNSBL queries, the lists that matter and continuous monitoring

To check if a mail server IP is blacklisted, reverse the octets of your sending IP, append the blacklist's zone and run a DNS lookup such as dig +short 25.113.0.203.zen.spamhaus.org. An answer in the 127.0.0.x range means the IP is listed, and an empty answer (NXDOMAIN) means it is not. Because listings appear and expire without notice, a single manual lookup only tells you about this moment, so production senders should run the same query on a schedule and alert on changes.

How DNS blacklists work

A DNSBL (DNS-based blocklist) is a DNS zone where each listed IP exists as a record. Receiving mail servers query the zone for every incoming connection and reject or score the message if a record exists. Using DNS makes the lookup fast, cacheable and easy to integrate into any MTA.

The query format is always the same. The IP 203.0.113.25 becomes 25.113.0.203, and the list zone is appended. The A record tells you whether and why the IP is listed, and many lists also publish a TXT record with a reason and a link to the lookup page.

Since the whole mechanism runs on DNS, it inherits DNS behaviour: caching, resolver policies and occasional timeouts. If you want the broader picture of how DNS problems surface in monitoring, the guide on which DNS failures take sites down and how to alert on them covers the resolver side in more depth.

Which IP should you check?

The IP that matters is the one that connects to the recipient's server, not necessarily the one in your MX record. MX records describe where you receive mail. Outbound mail may leave through a different host, a relay, a NAT gateway or a cloud provider's egress address.

• Send a test message to an external mailbox and read the topmost Received: header added by the recipient. The IP there is your real sending IP.
• On the server itself, find its public egress address with dig +short myip.opendns.com @resolver1.opendns.com.
• If your application sends through a separate transactional relay, check that relay's IPs too, or rely on the relay operator to do it.

While you are at it, confirm reverse DNS: dig +short -x 203.0.113.25 should return a hostname that resolves back to the same IP. Missing or generic PTR records do not cause DNSBL listings directly, but they hurt deliverability in the same way.

How to check if a mail server IP is blacklisted with dig

The manual check takes a minute and needs nothing but dig.

1. Reverse the IP: 203.0.113.25 becomes 25.113.0.203.
2. Query the A record against the list zone: dig +short 25.113.0.203.zen.spamhaus.org A.
3. If you get an answer, query the TXT record for the reason: dig +short 25.113.0.203.zen.spamhaus.org TXT.
4. Verify that your query path works by checking the list's test entry 127.0.0.2, which DNSBLs keep permanently listed: dig +short 2.0.0.127.zen.spamhaus.org. An empty answer here means your resolver is not getting real results.
5. Repeat for each list you care about.

A small script for several lists

A loop saves typing and gives you something you can later run from cron.

#!/usr/bin/env bash
# usage: ./dnsbl-check.sh 203.0.113.25
IP="$1"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')
LISTS="zen.spamhaus.org b.barracudacentral.org bl.spamcop.net"
STATUS=0
for L in $LISTS; do
  R=$(dig +short +time=3 +tries=2 "$REV.$L" A)
  if [ -n "$R" ]; then
    echo "LISTED  $L  $R  $(dig +short "$REV.$L" TXT | head -n1)"
    STATUS=1
  else
    echo "clean   $L"
  fi
done
exit $STATUS

The non-zero exit code on a listing makes it easy to hook into whatever alerting you already have.

Which blacklists actually matter for deliverability

Hundreds of DNSBLs exist, and many multi-list lookup sites check all of them. Most of those lists are used by almost nobody. Chasing every entry wastes time, so prioritise by how many receivers actually reject mail based on a list.

• Spamhaus ZEN (zen.spamhaus.org): the combined Spamhaus zone and the most widely used list for outright rejection. A listing here has immediate, visible impact.
• Barracuda (b.barracudacentral.org): used by Barracuda appliances and a number of mail filters. Querying may require registering the resolver you query from.
• SpamCop (bl.spamcop.net): driven by user reports. Listings expire automatically once reports stop, so a listing usually signals an ongoing problem.
• UCEPROTECT: levels 2 and 3 list whole provider ranges, so you can be listed for a neighbour's behaviour. Few large receivers reject on it. Do not pay for express delisting.

Large mailbox providers such as Gmail and Microsoft rely mostly on their own internal reputation data rather than public DNSBLs. A clean DNSBL result does not mean those providers accept your mail. Use Google Postmaster Tools and Microsoft SNDS for that side, and Microsoft's own delisting portal if Outlook.com rejects you.

Reading the result: return codes and false results

The returned address tells you which sub-list matched. For Spamhaus ZEN the common codes are:

• 127.0.0.2: SBL, a manually maintained spam source listing.
• 127.0.0.3: CSS, automated listing for low-reputation sending patterns.
• 127.0.0.4 to 127.0.0.7: XBL, usually a compromised host or malware on that IP.
• 127.0.0.10 and 127.0.0.11: PBL, a policy listing for IPs that should not send mail directly, such as dynamic or residential ranges.

A PBL hit on a dedicated server is not a spam accusation. It usually means your provider flagged the range as non-sending, and you can request a removal for that single IP once it has proper reverse DNS.

Watch for the most common false result: open resolver blocking. Spamhaus refuses queries arriving through large public resolvers and answers with error codes in the 127.255.255.x range instead of real data. If your script runs on a host that uses a public resolver, every check can look listed or clean regardless of reality. Run your own recursive resolver (for example unbound on localhost) for these lookups, and treat any 127.255.255.x answer as a check error, not a listing. Heavier or commercial use of Spamhaus data falls under their Data Query Service terms.

Why a one-off blacklist check is not enough

Most people check blacklists after something has already gone wrong: a customer says your password reset never arrived, or the mail log fills with bounces like 554 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org. By then mail has been failing for hours or days.

Listings are event-driven. A reused password on one mailbox, a contact form without rate limiting or a compromised dependency in a web app can turn a clean IP into a spam source overnight. Some lists remove entries automatically after a quiet period, so a check you ran last week says nothing about today.

Treat blacklist status like uptime: check it on a schedule, alert on the transition from clean to listed, and investigate the cause before you ask for removal.

What to do after a listing

Requesting removal first and investigating later is the fastest way to get relisted, often with a longer cooldown. Work in this order:

1. Identify the list and code. The return code and TXT record tell you whether it is a policy listing, a compromised host or a spam source.
2. Stop the source. Inspect the queue (postqueue -p or mailq), look for unusual senders, check authentication logs for logins from unexpected locations and look at application logs for forms or scripts sending in bulk.
3. Fix the root cause. Reset compromised credentials, add rate limits and CAPTCHAs to forms, close any open relay and make sure only authenticated clients can submit mail.
4. Verify the basics. Correct PTR record, SPF, DKIM and DMARC alignment. These do not remove listings, but they help reputation recover.
5. Request delisting through the list's own lookup page. Never pay a third party for removal.
6. Confirm recovery with the same dig query, keeping DNS caching in mind, and keep watching for relisting over the following days.

Setting up continuous blacklist monitoring

Continuous monitoring is the scripted check above, run regularly, with alerting on changes. A few practical guidelines:

• Interval: every hour or two is enough for most senders. Querying every minute adds load on volunteer-run lists, can get you rate limited and does not change how fast you can react.
• Scope: every IP that sends mail to the outside world, including relays, backup MX hosts that send bounces and application servers that send directly.
• Alert on transitions: notify on clean to listed and on listed to clean, not on every run while listed.
• Separate errors from listings: a timeout or a 127.255.255.x response is a broken check, not a blacklisting. Route those differently.
• Routing: a listing rarely justifies waking someone at night unless transactional mail is critical to your product. Send it to the team channel and email, and escalate during working hours.

If you run the check from cron, the script itself can silently stop running. Wrapping it with a ping to a push-based monitor closes that gap, as described in the guide on heartbeat monitoring for cron jobs.

Blacklist monitoring with m0nitor

If you prefer not to maintain the script and resolver yourself, m0nitor includes an IP blacklist (DNSBL) check among its monitor types, available on the Business plan. It runs on a fixed interval alongside HTTP, DNS and SSL checks, so mail server reputation shows up in the same place as the rest of your infrastructure.

Alerts can go to email, Slack, Microsoft Teams, Telegram and the other supported alert channels. With alert workflows you can react to a listing automatically, for example by notifying a channel, opening an incident or calling a webhook that pauses outbound campaigns.

FAQ

Can I check if a mail server IP is blacklisted without a website?

Yes. Reverse the IP octets, append the list zone and query it with dig or nslookup, for example dig +short 25.113.0.203.zen.spamhaus.org. An answer in 127.0.0.x means listed, no answer means not listed. Use your own resolver, because some lists block queries from public resolvers.

How long does it take to get removed from a blacklist?

It depends on the list. Some remove entries automatically once the abuse stops, others process removal requests after you fix the cause. DNS caching can delay the visible change on receiving servers, so verify with a direct query against the list after delisting.

Why does my IP show up as listed on dozens of lookup sites?

Multi-list lookup sites check many lists that almost no receiver uses, and some list entire provider ranges. Focus on lists that actually cause rejections, such as Spamhaus, Barracuda and SpamCop, and check your bounce logs to see which list receivers cite.

Does a clean blacklist check mean my mail reaches the inbox?

No. Large mailbox providers rely heavily on their own reputation systems, authentication results and user engagement. A clean DNSBL result only rules out one cause, so also check SPF, DKIM, DMARC, reverse DNS and the providers' own postmaster tools.