The worst time to learn that your IP is on a blocklist is twenty minutes before a send. I know this because it is exactly when I have learned it, more than once. A newsletter is queued, somebody notices that a test message bounced, and the bounce text says something like 550 5.7.1 Service unavailable; client host blocked using zen.spamhaus.org. The campaign is not going anywhere until someone works out what that line means.
Most people don't know, and I don't blame them. Blocklists are one of the oldest pieces of email plumbing still in daily use, they were designed by and for server administrators, and the vocabulary has never been cleaned up. So here is how I explain it to whoever just got that bounce.
What a blocklist actually is
A blocklist (the older word is blacklist, and you will see both) is a DNS zone, and that is the whole trick. Somebody maintains a list of IP addresses they consider bad, and instead of publishing it as a file they publish it as DNS records under a domain they control. A mail server that wants to know whether an address is listed does not download anything. It asks DNS a question, the same way it would look up a website.
The question is built by reversing the octets of the IP and gluing the zone name to the end. For the address 203.0.113.7 and the Spamhaus ZEN zone, the name to look up is 7.113.0.203.zen.spamhaus.org. If that name resolves to an address, the IP is listed, and if DNS answers "no such name", it is not.
You can do this yourself from any terminal.
dig +short 7.113.0.203.zen.spamhaus.orgAn empty answer means not listed, an answer in the 127.0.0.x range means listed, and the last number tells you which sub-list did it. For Spamhaus, 127.0.0.2 is the SBL, 127.0.0.3 is CSS, .4 through .7 are the XBL, and .10 and .11 are the PBL.
Every properly run list answers "listed" for the test address 127.0.0.2, so before you trust a clean result, reverse that and ask.
dig +short 2.0.0.127.zen.spamhaus.orgYou should get several answers back, and if you get nothing, your resolver is the problem rather than the list, and every "clean" answer you see afterwards is worthless. Spamhaus in particular refuses queries that arrive through the big public resolvers, and it says so with a 127.255.255.254 answer instead of a listing. I once watched a monitoring dashboard show a whole fleet as spotless for a month because it was querying through a resolver the list had quietly stopped answering.
The lists that matter
There are hundreds of DNS blocklists, and perhaps five of them decide whether your mail gets through.
Spamhaus ZEN is the one. It is a combined zone that bundles the SBL (addresses Spamhaus staff have listed for sending spam), the XBL (compromised machines, bots, open proxies) and the PBL, which is not about spam at all. The PBL is a policy list of address ranges whose owners have said "nothing here should be sending mail directly", which in practice means home broadband, mobile networks and cloud ranges that were never meant to run an outbound mail server. Landing in the PBL on a freshly rented VPS is common and is not an accusation. The range is presumed to be end-user space, and you fix it by asking your provider or by relaying through a host that is not in it.
SpamCop is driven by user reports. People forward spam to it, it parses the headers, and the sending IP gets listed for a while. Listings expire on their own, usually within a day or two after the reports stop, so a one-off incident clears itself, while a steady trickle of complaints keeps you on it indefinitely with nothing to "delist" in the usual sense.
Barracuda is a reputation list run by the firewall vendor, fed by their appliances and honeypots, and consulted by every organisation that owns one of those appliances, which is a lot of corporate mail. Removal is a form and a wait.
Beyond those three there are lists that specific receivers weigh but that are not universal, some honest and small, some listing entire ranges over one bad neighbour. UCEPROTECT deserves a paragraph, because it comes up constantly and scares people for no reason. Level 1 lists individual IPs that hit its traps, which is fair enough, but Level 2 lists whole allocations and Level 3 lists entire networks by autonomous system, so being on Level 3 means somebody in the same hosting company as you sent spam. Almost no serious receiver uses the higher levels, and the list charges for faster removal, which tells you most of what you need to know.
Then there are the lists that no longer exist. SORBS, a name that sat in every roster for twenty years, shut down in 2024, yet its zones still appear in plenty of checking tools, where they simply answer "not listed" for everyone. I found three SORBS zones in my own roster while writing this and took them out. A clean result from a dead list is not information.
IP lists and domain lists are different animals
Everything above is about the sending IP. There is a second family of lists that judge domains, and they answer a different question.
Spamhaus DBL, SURBL and URIBL do not care where a message came from. They look at the domains that appear inside it, in the links and in the From address, and list the ones seen in spam. A receiver runs every URL in your message through them, so a message can leave a clean IP, carry perfect authentication, and still get blocked because a link in the footer points at a domain that somebody else burned last month. Link shorteners are the classic case, since a shortener domain is shared by everyone who uses the service, spammers included, and once it goes onto a domain list every message containing it pays.
Checking a domain by hand looks almost the same, except that nothing is reversed.
dig +short example.com.dbl.spamhaus.orgAn answer in 127.0.1.x means listed, and Spamhaus publishes what each code means.
Checking with the tester
When I built the blocklist section of Email Spam Tester, two decisions turned out to matter more than the roster itself.
The first is that the report never converts a failed lookup into a clean one. It queries twenty-one IP lists in parallel with a short timeout on each, and a list that times out, refuses the query or answers with a policy code is shown as exactly that. The four lists receivers actually consult are weighted as major, and if one of those did not answer, the check says the IP could not be called clean yet rather than pretending.
The second is that the section covers the connecting IP only, and says so. The links in the message are handled elsewhere in the report, by the two spam engines, which run their own URL lookups. Keeping the two apart matters, because the fix for an IP listing and the fix for a burned link domain have nothing in common. The infrastructure section of the documentation lists what each check reads and what it costs.
When you are listed
The temptation is to go straight to the removal form, and every list I have dealt with says the same thing about that in its own words. Find out why you were listed, fix that, and only then ask to be removed. A listing that is removed and reappears two days later is much harder to get removed the second time.
The causes I keep running into, roughly in order of how often:
- A compromised account or web form, where somebody's password leaked or a contact form got turned into a relay and the server has been quietly sending spam for a week. Check the outbound queue and the logs before anything else.
- A purchased or scraped list, because old addresses on such lists are often spam traps that never signed up for anything and exist only to catch senders who did not ask. One trap hit can be enough for a listing.
- A neighbour, since on a shared IP somebody else's behaviour is your listing.
- Volume from nowhere, as a new IP that goes from zero to a large blast in an afternoon looks exactly like a botnet to a list that watches traffic patterns.
Once the cause is gone, removal is per list, and the procedure varies. Spamhaus has a self-service lookup at its Blocklist Removal Center where you enter the IP, read why it was listed and request removal, and the PBL in particular lets you remove your own address after confirming that you run a real mail server. SpamCop you wait out, and Barracuda has a request form and a manual review. The smaller lists have anything from a form to an email address to nothing at all, and for a list nobody consults, nothing at all is fine.
Write down the date and the reason each time. Six months later, when the same range gets listed again, you will want to know whether this is the same problem.
"Not listed" is not the same as "good"
Here is the part that trips up people who have just cleaned up a listing. They check every list, everything is clean, they send, and the mail lands in spam anyway, because blocklists are public and binary while the reputation systems that decide most of your delivery are neither. Gmail keeps its own view of your domain and your IP, built from complaint rates, engagement and authentication history, and it shows you very little of it. Postmaster Tools gives you a spam rate and a compliance checklist, and its old reputation charts are being retired. Microsoft has its own, with a peek available through its SNDS programme. Neither of them consults Spamhaus to decide whether your newsletter goes to the Promotions tab, the inbox or the junk folder. A public listing is a loud signal that something went badly wrong, while the absence of one says nothing about how the big receivers feel about you this week.
So after a listing you delist, then watch Postmaster Tools for a couple of weeks, and only then trust the numbers.
Shared IPs
If you send through an email service provider, you are almost certainly on a shared IP, one of a pool used by many customers, and this is usually a good thing. The pool has a long history, the provider polices it, and a small sender benefits from reputation it could never build alone. It also means that a listing is often not yours.
There is not much you can do about it beyond telling the provider and waiting. What you can do is find out whether the listing is on the IP or on your domain. If your domain is clean and the IP is listed, it is the pool's problem. If your domain is on the DBL, it is yours, and moving IPs will change nothing.
A dedicated IP fixes the neighbour problem and creates a new one. Now every listing is yours, the history starts from zero, and a blast from a fresh dedicated address with no warm-up is the fastest route onto a blocklist I know of. A sender I worked with insisted on a dedicated address for a modest monthly newsletter, ended up with worse placement than they had in the pool, and needed a slow month of ramping to get back.
If you take one thing from all this, take the dig command. Put your sending IP into it, against zen.spamhaus.org, before you next hit send. It takes four seconds, and it is the check that would have saved every one of those Friday afternoons.