DNSBL blacklists: how to check and how to get delisted

DNSBL blacklists can stop your sending within minutes, and they usually do it without warning. We run our own fleet of sending servers, so we see listings on a regular basis. Sometimes it is the customer’s fault, sometimes a neighbour in the same address pool, sometimes a hijacked mailbox. This article explains what these lists really are, how to check your IP address and domain, what an effective delisting request looks like and what to do so you do not end up back on the list. No scare tactics and no promises of getting around filters.

What a DNSBL is and what exactly gets listed

A DNSBL is a set of IP addresses and domains published over ordinary DNS. The receiving server asks about an entry during the SMTP session, before the message is even accepted. The answer comes back in a fraction of a second. That is why the mechanism is so widespread across the email world.

There are several kinds, and mixing them up leads to the wrong diagnosis:

• IP lists - these cover the sending server address, the one that opens the SMTP connection.
• Domain lists (URIBL) - these cover the Return-Path domain and the domains of links inside the message, including shorteners and tracking domains.
• Reputation systems - they do not publish entries. You cannot query them with a lookup, yet they still decide your deliverability.

A listing is not the same as a block. Some filters treat it as points in the message score, so a single list at most raises the risk of landing in spam. Others drop the connection immediately and return a 5xx code with the name of the list. It all depends on the recipient’s configuration, not on the listing itself.

The largest mailbox providers are a separate story. They build their own reputation models from recipient behaviour: opens, deletes without reading, spam complaints, replies. You will not check those scores with any public query. You can only infer them from your sending data and from sender panels.

How to check whether you are on a blacklist

Before you fire up any tool, decide what you are actually checking. Four things can be listed independently: the sending server IP address, the Return-Path domain, the domains of links in the content and the PTR record. Checking only the IP when the problem is a URIBL is a waste of time.

1. Read the IP address from the Received header of a message you sent. That is the address the recipient sees, not the address of your office.
2. Reverse the octets and append the list suffix, for example for 198.51.100.7 you query 7.100.51.198.example-list.org.
3. Run the query: dig +short 7.100.51.198.example-list.org A and the same with TXT.
4. Read the return code from the A record. Usually 127.0.0.x, where the last number tells you the reason for the listing. The TXT record holds a description and often a link to the form.

The console is entirely enough: dig and host show you the raw answer. Aggregators that query dozens of lists at once give you a quick overview, but they can be out of date and they mix serious lists with dead ones. Always confirm the result at the source.

The most useful information, though, sits in the headers of the rejected message and in the bounce text. You will find the SMTP code there, the name of the specific list and the delisting page address. An aggregator will not tell you that.

Tip: save the full bounce text together with the date, the time and the recipient address. List operators expect evidence, and without it your request usually goes in the bin.

A lookup has its limits. It will not reveal throttled connections, mail landing in the spam folder or your score in the sender panels run by the big providers. That data is read from MTA logs and sending reports, and at higher volumes from the built-in deliverability reports on the sending platform side.

Which lists to take seriously and which to ignore

There are hundreds of public lists, and only a handful have any real effect. We judge their weight by four things: who actually uses the list, what the delisting process looks like, whether the operator shows evidence and whether it asks for money.

A list used by large corporate filters and hosting providers can cut you off from half of your business recipients. A list run by one person that no serious filter queries will not change a thing in your statistics. Both look identical in an aggregator report. And that is the main trap with such tools.

Signs that tell you a list is not worth your attention:

• A fee for removing the entry, especially with time pressure. Serious operators delist without an invoice.
• No reason given: no sample, no timestamp, no trap address.
• No working contact or form, but a visible offer of “protection”.
• Listing criteria described in vague terms, or covering whole address ranges with no connection to mail traffic.

Your reaction should be proportionate. A listing on a marginal list does not call for an all-nighter. Check what the data says: did bounces go up, did opens go down, did complaints appear, do the logs show rejections naming that list. If none of those numbers moved, there is no problem to solve.

Why IP addresses and domains end up on lists

The reasons repeat themselves over and over, and you can almost always name them.

Spam traps and an old list

List operators maintain addresses that never belonged to a human being, plus abandoned mailboxes turned into traps after years of disuse. Hitting the first kind means a list you bought or scraped from websites. Hitting the second is the result of mailing contacts collected long ago and never cleaned. One message sent to such an address is enough to get listed.

Complaints and bounces

The spam button is the shortest route into a reputation system. The recipient does not have to remember signing up. It is enough that they do not recognise the sender. Sending to non-existent mailboxes works the same way: a run of hard bounces is a clear sign that the sender has lost control of the list, and the difference between hard and soft bounces decides which address to remove straight away and which one to watch.

Compromise and infrastructure

A hijacked mailbox, a contact form with no limits, an open relay, an infected workstation on the company network - each of these generates traffic you never ordered. A separate case is a sudden volume spike from a new IP address with no warm-up. Filters read that as a classic abuse pattern.

Then there is the neighbourhood. When you send from a shared pool, the behaviour of other senders weighs on your reputation. That is why in our fleet we split transactional and marketing traffic across separate addresses, and keep senders with different profiles well apart.

The delisting procedure step by step

The order matters more than the speed. Cause first, request second. Removing the entry before you fix the source ends with a return to the list, and a second listing tends to be harder to lift and comes with a longer cooling-off period.

1. Stop sending from the listed address. A queue growing during rejections makes things worse.
2. Find the source in the MTA logs. Look for unusual senders, volume spikes and runs of 5xx rejections from a single account.
3. Clean the list: remove hard bounces, unsubscribe contacts with no reaction for many months, cut off segments of unknown origin.
4. Fix authentication and DNS configuration.
5. File a delisting request on the list operator’s site.
6. Watch the logs and the metrics for a few days before you go back to normal sending.

Tip: before you send the request, check SPF, DKIM, DMARC, the PTR record and whether the Return-Path domain matches the sender domain. Gaps in those settings are the most common reason for refusal, no matter how nicely you described the fix.

Fill in the form itself briefly and factually: what happened, what was changed, since when. No excuses, no emotion, no resubmitting every hour. Repeated requests can be treated as spam and only drag the process out.

Some lists expire entries automatically if no new traffic reaches the traps from that address. Others need a human decision, and then the quality of your description counts. After delisting, come back gradually: the most active segments first, then the rest. If you are looking for infrastructure with separated address pools, take a look at our newsletter sending platform.

How to stay off the lists: prevention on the technical side and in your database

Authentication is a precondition, not an advantage. SPF has to stay within the DNS lookup limit, because once you go over it the record stops working and the check ends with an error. Sign DKIM with a separate selector for each sending channel, so a problem with one does not poison the rest. Set DMARC with a real policy and reporting turned on - without it you will not see who is impersonating your domain.

Set up monitoring so that it speaks up on its own: an alert on a bounce spike, constant tracking of complaints, a regular lookup of your own addresses and domains. A problem caught the same day costs a few hours. Caught after two weeks, it costs your domain reputation.

List hygiene comes down to a few habits: double opt-in, automatic removal of hard bounces, sunsetting contacts who never react, an unsubscribe that is visible and works in one click. Warm up a new IP address and a new domain: small volumes, the most active segments first, growth spread over weeks. Keep sign-up and opt-out data in one place, and if your list lives in a CRM or a shop, connect it with a ready-made sending platform integration instead of uploading files by hand.

Consent here is a technical element, not only a legal one. GDPR and article 398 of the Polish Electronic Communications Law require it in B2B contacts too, and a register with proof of sign-up saves you when a complaint arrives. To be straight about the limits: automatic list queries for all customer domains are on our roadmap, today we do it on the fleet side. Signals from the sender panels of the big providers are connected separately, on their side, and that is standard practice in the industry.

Summary

A listing is a symptom. The illness sits in the address list, the server configuration or the way you send. Lifting entries without touching the cause is running in circles, and each round costs more.

The order of actions fits in five words: diagnose, stop, fix, request, ramp volume back up slowly. Diagnosis from logs and headers, not from a hunch. The fix before the request, not after it.

No provider will get around spam filters, and anyone who promises that is not telling the truth. What you can get is predictable infrastructure, separated address pools, correct authentication and order in your data. The rest depends on what you send and to whom.

Do you have a specific deliverability problem, or a listing you cannot lift? Write to us with a description of the situation and the text of the bounce message. We will answer with what the logs show.