You send the same monthly invoice run you have sent for two years. This time, part of it never arrives. Nothing in your outbox looks wrong. A few hours later a colleague forwards you a bounce message with a sentence in it you have never had to read before, and a link to a form on a website you have never visited.
Your sending address has been listed on a blocklist. Until it comes off, a meaningful share of the internet will refuse your mail at the door — politely, instantly, and without telling you.
This is one of the few email failures that is both invisible from your side and immediate in its effect. Nothing you control changed. What changed is the answer other mail servers get when they ask about you.
A blacklist is a DNS zone, not a website
An email blacklist — more precisely a DNSBL, a DNS-based blocklist — is not an API or a web page. It is a DNS zone that answers questions about addresses.
When a receiving mail server accepts a connection from 203.0.113.10, it reverses the octets, appends the list's zone name, and makes an ordinary DNS query:
dig +short 10.113.0.203.zen.spamhaus.org
If the reply is NXDOMAIN, the address is not listed. If the reply is an address inside 127.0.0.0/8, it is listed — and the specific value encodes the reason. On Spamhaus, 127.0.0.2 is a different kind of problem from 127.0.0.10. A TXT query at the same name usually returns a human-readable explanation and a removal URL.
The whole exchange takes milliseconds and happens before your message body is ever transmitted. That is why blocklists are so widely used, and why the outcome is so binary: you are either accepted or you are not.
The lists that actually matter
There are hundreds of blocklists. A small number carry most of the weight:
- Spamhaus ZEN (
zen.spamhaus.org) combines several datasets in one lookup: SBL for known spam sources, CSS for snowshoe-style senders, XBL for compromised and exploited machines, and PBL for address space the owner says should not be sending mail directly. - Spamhaus DBL (
dbl.spamhaus.org) lists domains rather than addresses. - SpamCop (
bl.spamcop.net) is driven largely by recipient reports and tends to expire listings automatically. - Barracuda (
b.barracudacentral.org) is widely deployed in front of business mail systems. - SURBL and URIBL list domains that appear in message bodies — so a link to a compromised site in your newsletter can get the message filtered even when your own sending address is clean.
How a clean sender gets listed
Almost nobody gets listed for deliberately sending spam. The usual causes are mundane:
- A compromised mailbox. One weak password on one account, and your mail server starts relaying someone else's campaign at three in the morning. This is the single most common cause.
- A web form with no rate limit. Contact forms and "share this page" features that send mail on behalf of a visitor are abused constantly.
- Forwarding. If you forward mail for staff to an external mailbox, you also forward the spam that reached them — and the receiving system attributes it to your IP, not the original sender.
- A neighbour on a shared IP. On shared hosting or a small VPS range, you inherit the reputation of whoever else sends from that address.
- Buying or importing a list. Even one spam-trap address in an imported list is enough to trigger a listing.
- Policy listings. PBL-style entries are not accusations. They simply record that this address range is meant for end users, not for direct-to-MX sending. If you set up a mail server on a residential or generic cloud IP, you may be listed the day you start.
What breaks without it
If you are not watching your sending addresses, the failure surfaces in the worst possible order: your customers notice before you do.
The visible symptoms are specific. Mail to some recipients bounces with a 5xx response that names the list outright:
550 5.7.1 Service unavailable; Client host [203.0.113.10] blocked
using zen.spamhaus.org; https://check.spamhaus.org/
Mail to other recipients is accepted and silently filed as junk, because many filters treat a listing as a strong signal rather than an absolute block. Password resets stop arriving. Invoices go unpaid because nobody received them. Your support inbox fills with "I never got the email" while your mail server logs look, at a glance, entirely normal.
The second-order damage is worse than the first. Recipients who stop opening your mail because it landed in junk teach their provider's filter that your mail is unwanted — so even after delisting, delivery takes time to recover.
How to check it in 30 seconds
You need to know two things: whether your sending IPs are listed, and whether your domain is listed. Run a Blacklist Check on your domain — it resolves your mail and web addresses and queries them against every enabled list, then checks the domain itself against the domain-based lists.
Read the result in this order:
- Which list. Spamhaus and Barracuda first; everything else is context.
- Which target. A listed MX address affects mail you send through that server. A listed domain affects every message that mentions it, from any server.
- The reason code. A policy listing on dynamic address space is a configuration problem. An exploit listing means a machine of yours is compromised right now.
If your MX is a provider such as Google or Microsoft, note that their inbound addresses are not the addresses you send from. Check the outbound IP your mail actually leaves on — the one in the last Received: header of a message you sent. The Email Header Analyzer will extract it for you.
Fix it
Delisting before fixing the cause is the mistake that turns a one-day problem into a three-week one. Most operators track repeat delisting requests, and repeat offenders are removed more slowly each time.
- Find the source. Check your mail queue for a sudden volume spike and your authentication logs for a mailbox sending at unusual hours.
- Reset the credentials of any account that looks compromised, and force re-authentication on all devices.
- Rate-limit or disable any web form that sends mail, and require a captcha or authentication.
- Stop or filter unconditional forwarding to external mailboxes.
- Purge the queue of anything you did not intend to send, before it drains and re-triggers the listing.
- Confirm your server is not an open relay, and that reverse DNS and mail authentication are correct.
- Use the operator's own form. Every listing in a StatusDNS result links directly to it.
- Say what happened and what you changed. Blank requests are rejected or ignored.
- Request removal once and wait. Do not submit the same address to the same list repeatedly.
- Expect self-expiring listings (SpamCop in particular) to clear on their own once the behaviour stops.
- If you are on a shared IP you do not control, escalate to your provider — you cannot fix a neighbour's behaviour, and they can.
Then keep it that way
Listings are events, not states. The useful question is not "am I listed today" but "will I know within minutes if that changes".
StatusDNS re-checks every monitored domain on a schedule, resolving its mail and web addresses and querying them against every enabled blocklist. When a new listing appears, you get an alert by email — and, on plans that include them, by Slack or webhook — naming the list, the address and the reason code, with the operator's delisting link. When the address comes off the list again, the alert is resolved and you are told that too, so you know when the incident is actually over.
The same run also records the result in your domain's history, so after an incident you can see exactly when the listing appeared and when it cleared. If you want the wider picture of how this fits with the rest of your setup, why checking once is not the same as monitoring covers the reasoning behind the cadence.