Getting an IP Delisted: Fix the Cause Before You Fill In the Form

Mail that used to arrive starts bouncing. The rejection message names a blocklist, you look the address up, and there it is. The next instinct is almost always the same one: find the removal form, fill it in, get back to work.

That instinct is why plenty of addresses get listed twice in a week. Removal is a paperwork step. It does not change a single thing about the server, and the detection that listed you the first time is still running.

Why the form is the last step#

A blocklist listing is a symptom. Something observable happened from your address: mail hit a spamtrap, recipients clicked a report button, a scanner saw an open relay. Delisting removes the record of that observation. It does nothing about the compromised mailbox still sending, the web form still being abused, or the marketing list still generating complaints.

Delist first and investigate second, and the usual outcome is a second listing within hours, on the same list, for the same reason. You have spent a removal on an address that was about to re-offend, and taught the list that removals from your organisation do not stick.

The order that works is the boring one. Confirm the listing, read what it says, find and stop the cause, then ask for removal if the list has not already cleared you.

Which list, and whether it matters#

Listings are not interchangeable. An address on a list that large mail providers consult during the SMTP conversation is a delivery emergency. The same address on a niche list used by a handful of IRC networks is information, and possibly not even bad news.

Our IP blacklist check takes one IPv4 address and queries seven lists, then splits the answer on purpose. SpamCop drives the headline verdict. The other six, PSBL, DroneBL, GBUdb Truncate, SpamEatingMonkey, Interserver RBL and JustSpam, are reported as supporting signal. If the only hits are in that second group, the result is labelled informational rather than listed, because that is the honest reading: something noticed you, but not the list the verdict turns on.

Worth knowing what that checker does not cover: it does not query Spamhaus or Barracuda. Both were dropped in a licensing review, Spamhaus because its free query service is licensed for non-commercial use and this is an ad-supported site, Barracuda because it requires registering the resolver doing the querying, which a shared public resolver cannot do. The practical consequence: if mail is being rejected and our result comes back clean, that is not a complete answer. Check those lists directly on their own sites.

The same tool refuses private and reserved addresses rather than pretending to check them: no public blocklist can describe 192.168.1.10, and a confident "clean" there would be worse than no answer. If you are not sure which address your mail leaves from, the IP lookup reports it.

What the answer actually says#

A DNSBL is a DNS zone, and a lookup against one is an ordinary A record query. RFC 5782 writes the convention down: the entry name is built by reversing the octets of the address and appending the list's domain. The RFC's own example is the address 192.0.2.99 on bad.example.com, which becomes 99.2.0.192.bad.example.com.

Two answers matter. If the address is not listed, the RFC requires that there be no records for it at all, which is why a lookup for a clean address comes back with nothing. If it is listed, you get an A record in 127.0.0.0/8. The RFC says the value is conventionally 127.0.0.2 but may be something else in that range, and lists use those other values to encode why you were listed. That final octet is the closest thing to a reason code you get for free.

There is usually more detail available, and most checkers skip it. RFC 5782 notes that lists often publish a TXT record alongside the A record, and that the reason it carries "often includes the URL of a web page where more information is available". Client software is required to check the A record and only permitted to check the TXT one, so many tools, ours included, read the A record alone. When you need the specific reason and the right removal page, query it yourself:

dig +short TXT 99.2.0.192.bl.example.net

One more answer is easy to misread. Some lists reply to queries they are refusing with an address in the 127.255.255.0/24 range, a throttling signal rather than a statement about you, and it happens a lot when queries arrive through big shared resolvers. A checker that treats any answer as a listing will tell you that you are blocked when the list has simply declined to talk. Ours classifies those replies as rate limited and keeps them out of the verdict.

How to check if an IP is on a blacklist covers the checking side in full; this piece picks up where it leaves off.

Fix the cause first#

For a server that was fine until recently, the cause is usually one of a short list.

• A compromised account. One stolen mailbox password, and your legitimate server becomes a legitimate-looking spam source. Check outbound queue depth and per-account send rates before anything else.
• An open relay or an abusable form. A contact form that will send arbitrary text to arbitrary recipients is a spam gateway with your address on it.
• Inherited history. Cloud addresses get recycled. A new instance can arrive already listed for something its previous tenant did.
• Policy, not fault. Some lists catalogue ranges that are not supposed to originate mail at all, such as residential broadband. Nothing is broken; the address is simply the wrong one to send from.
• Complaints about real mail. Recipients reporting messages they genuinely subscribed to still counts, and this one is a content and consent problem rather than a security incident.

While you are in there, check the things receivers look at alongside the listing. Publishing SPF, DKIM and DMARC will not keep you off a blocklist, but it lets a receiver tell your mail apart from mail forged in your name, which matters enormously once you are asking for the benefit of the doubt. SPF, DKIM, and DMARC explained covers how the three fit together. It is also standard practice for a sending address to have working reverse DNS, and the reverse DNS lookup shows what yours resolves to.

Lists that clear themselves#

Here is the part that saves the most time: several lists will remove you without being asked, and filing a request is simply unnecessary.

SpamCop is the clearest case. Its documentation states that without additional reports, a reported address stays on the list for only 24 hours. Stop the reports and the listing lapses by itself within a day. That reframes the whole exercise. On the list that drives our headline verdict, the work is entirely in stopping whatever is generating reports, and there is no form to chase.

PSBL goes the other way and makes removal trivial: it says removal can be done by anyone and is instantaneous. Free, immediate, no negotiation.

Read each list's own policy before assuming you are in for a fight. Some expire, some remove in seconds, and a few are genuinely difficult.

Why a removal takes time to show#

You delist, re-send a test message, and it bounces again. Nothing has gone wrong.

Blocklist answers are DNS answers, and DNS answers get cached. PSBL says this plainly about its own instant removals: the removal takes effect at once, but it takes time to propagate to nameservers across the internet. Every receiving mail server that looked your address up recently is holding the old answer until it expires, and each of them is on its own clock.

So after a removal, expect a lag measured in hours rather than seconds, and do not read a continued bounce as a failed request. Re-filing achieves nothing except annoying the list operator. Our own result is cached for five minutes as well, so give it at least that long before re-checking and believing the answer.

What a good request says#

When a list does want a request, the ones that get actioned quickly all look alike. State the address and that you are responsible for it. Say what the cause was, specifically, naming the compromised account or the misconfigured form. Say what you changed and when you changed it. Then stop.

What does not help: arguing that the listing was unfair, explaining that you are a legitimate business, or asking for an exception because a campaign goes out tomorrow. Operators read a great many of those. A short note describing a fixed root cause reads as credible, because it is the only one giving them a reason to believe the address will behave differently.

File once. Then wait.

The reputation that does not reset#

Getting delisted removes you from a list. It does not reset how the large mailbox providers feel about your address, and those are separate systems that no blocklist operator controls. They keep their own per-address and per-domain history, and that history does not have a removal form.

In practice, delivery recovers gradually rather than snapping back. Sending a large volume immediately after a delisting is the fastest way to get filtered again, because a sudden spike from an address with a recent incident is exactly the pattern these systems watch for. Ramp back up, watch what happens, and check where you stand with the IP reputation check. What is IP reputation goes into how that scoring works and why it moves slowly in both directions.

When the address is not yours#

Plenty of people reading a listing cannot do anything about the address, and recognising that early saves real effort.

If you send through a hosting provider's shared outbound address, the listing belongs to the provider. You cannot delist it and should not try: a removal filed by someone with no control over the traffic is the kind that gets reversed. Open a ticket with the rejection message and timestamps, and let them work it.

If you are on a cloud instance with a recycled address, the listing may predate you entirely. Providers generally have a route for this, and requesting a different address is sometimes faster than clearing the old one.

If your office address is listed and nobody there runs a mail server, the cause is on the local network rather than in any form: a workstation infected with something that sends, or a device quietly acting as an open proxy. Find and clean the machine. The listing follows.

The common thread: delisting is the last step, and its job is only to record that something upstream has already been fixed.