Your IP is on a blocklist: how to check it in 5 minutes and what actually gets you delisted

Mail starts bouncing, a partner's firewall stops answering, or a website shows your server a captcha wall. Someone says "your IP is blacklisted", and the first instinct is to ask for a new one. Usually that's the wrong first step. Here's how to find out what's actually going on, in about five minutes, and what fixes it for good.

What a "blocklist" actually is

The word covers three different things, and they're fixed in different ways.

1. DNS blocklists (DNSBLs). Public lists of addresses that sent spam or showed signs of compromise. Mail servers query them for every incoming connection. This is what "blacklisted" usually means, and it's the fixable kind.
2. Private reputation at big mailbox providers. Large webmail services keep their own scores and don't publish them. You see the effect (mail lands in spam or is deferred) but there's no list to check, only their postmaster tools.
3. Network classification. Many websites and fraud systems treat every data-centre address as "hosting" and challenge or block it. That isn't a listing and can't be removed; it describes what kind of network the address belongs to.

The rest of this article is mostly about the first kind, because it's the one you can check and fix yourself.

The lists worth checking

• Spamhaus is the one most mail servers use. Its combined zone, ZEN, includes the SBL (known spam sources), XBL (machines infected or exploited, fed by the CBL), PBL (ranges that shouldn't send mail directly) and CSS (low-volume "snowshoe" spam).
• Barracuda runs its own list, used by many corporate mail gateways.
• SpamCop lists addresses reported by users; listings expire on their own about 24 hours after the last report.
• UCEPROTECT has three levels. Level 1 is individual addresses and expires automatically after seven days without new spam. Levels 2 and 3 list whole allocations and networks for the behaviour of neighbours, and they sell "express" removal. Major mail providers rarely rely on levels 2 and 3.

The check

DNS blocklists are queried by reversing the address's octets and looking it up under the list's zone. From any Linux server:

IP=203.0.113.7
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')
for BL in zen.spamhaus.org b.barracudacentral.org bl.spamcop.net; do
  echo "$BL: $(dig +short "$REV.$BL" A | tr '\n' ' ')"
done

No answer means not listed. An answer in the 127.0.0.x range means listed, and for Spamhaus the last number tells you which part of ZEN:

That last row trips up a lot of people. Spamhaus doesn't answer queries that arrive through big public DNS resolvers, and returns an error code instead. If every check looks odd, run it from a server using its own resolver, or use the lookup page on each list's website. Some lists also ask heavy users to register before querying them over DNS.

Fix the cause first

A delisting request without a fix buys you a day or two before the next listing, and repeat listings take longer to clear. So work out where the listing came from:

• Was the address listed before you got it? Check the listing date against when your server was created. An old listing with no new activity is the easy case: go straight to the delisting form.
• XBL or CBL listing: the list saw traffic typical of malware or a botnet from your address. Look for processes you don't recognise, unexpected outbound connections on port 25, new cron entries and unknown SSH keys. A compromised web app or a weak password is the usual entry point. If you're not sure the machine is clean, rebuild it.
• SBL or CSS listing: mail from your address looked like spam. Check contact forms that send mail without a captcha, scripts that send newsletters, and any SMTP service listening on the public interface.
• You're sending mail at all? On many hosts, outbound ports 25 and 465 are closed by default; mail should go through a mail provider on port 587. If you never send mail and you're still listed, something else on the server is.

If you run untrusted code on the same machine that sends your mail, this is the moment to separate them. A sandbox or a second server for the risky work keeps its reputation problems away from your mail address; isolation levels for untrusted code compares the options.

Then delist

• Spamhaus: use the lookup page, which links to the right removal process for that zone. XBL/CBL and PBL removals are self-service once the cause is gone; PBL removal makes sense only if you really run a mail server with matching reverse DNS.
• Barracuda: submit the removal form with a short explanation of what you fixed. Expect up to a day or so.
• SpamCop: nothing to do; the listing expires on its own about a day after reports stop.
• UCEPROTECT: level 1 expires after seven days without new spam. Ignore levels 2 and 3, and don't pay for removal.

After delisting, set up the basics that keep you off lists: a reverse DNS name that matches your server's hostname, SPF, DKIM and DMARC for your domain, and a weekly cron job that runs the check above and emails you if anything changes.

When a new address is the right answer

Sometimes it is: for example, the address carries an old SBL listing you can't get removed, or you need a clean reputation for a fresh project. With us, a different address means a new server: order it, move your data, then cancel the old one; changing your IP address walks through all the options. If you believe a listing on your current address is wrong, open a ticket with the list name and a link. We look at each case, but we don't swap addresses on request.

Two last points. If reputation matters at all (mail, partner allowlists, API keys tied to an address), use a plan with its own IPv4, such as Small-IP: on a NAT plan the outbound address isn't your own, so your sender reputation can't be built on it. And if a website blocks you because you're in a data centre, no list and no new data-centre address will change that; network & ports explains what each plan exposes.