The mechanism is a DNS-based blocklist, usually written DNSBL, and it is one of the oldest pieces of anti-abuse infrastructure still in daily use. It has an elegant design, an unglamorous job, and a governance situation that most people who depend on email have never had cause to look at.
The query is a DNS lookup, and that is the whole trick
A mail server accepts a TCP connection from 203.0.113.45. Before deciding whether to continue the conversation, it wants to know whether that address has a reputation. Rather than invent a protocol, DNSBLs encode the question as a hostname.
Reverse the octets, append the list's zone, and ask for an A record:
45.113.0.203.zen.spamhaus.org
If the answer is NXDOMAIN, the address is not listed. If a record comes back, it is an address in 127.0.0.0/8, and the final octet is a code identifying why. A companion TXT record carries a human-readable explanation and usually a URL. The listing reason matters, because lists are not monolithic.
The design has properties that explain its longevity. Every mail server already speaks DNS. Answers are cacheable, so a busy server queries the same address once and reuses the result. The list operator publishes through the existing DNS hierarchy and never has to run an API. And the query happens during the SMTP handshake, so a listed sender is rejected with a 5xx code before the DATA command, which means the receiving server never spends bandwidth or filtering cost on the message body.
Content analysis is expensive per message and unbounded in effort. A connection-time reputation check is one cached DNS answer per source address, and it disposes of the overwhelming majority of abusive volume at the cheapest possible point. That economics is why the technique survived every predicted replacement.
Not all listings mean the same thing
Treating "blocklisted" as a single accusation is the most common misunderstanding, and it makes the difference between a problem you can fix in an hour and one you cannot fix at all.
| Kind of list | What it asserts | What it means for you |
|---|---|---|
| Spam source | Abusive mail was observed from this address. | Something on that address sent spam, possibly a compromised account rather than you. |
| Exploited or compromised host | The machine shows signs of infection, an open proxy, or an open relay. | A security problem to fix first. Delisting before fixing produces a relisting. |
| Policy list | This address belongs to a range whose operator says it should not send mail directly, typically residential or dynamic space. | No accusation at all. It is a statement about the address range, and the fix is to send through a designated relay or use address space intended for mail. |
| Domain and URI lists | A domain appearing in the message, often in a link, is associated with abuse. | Independent of your IP. A single bad link in a newsletter can cause it, including a shortener someone else abused. |
The policy-list row is the one that surprises people. A residential connection listed in a policy zone has not done anything wrong, and no amount of good behaviour will remove it, because the listing is about what kind of address it is. For anyone hoping to run a mail server at home, that single row is usually the end of the story.
The part the public lists do not decide
The public lists are also the least important part of the answer.
The largest mailbox providers run their own reputation systems, and those matter more to your deliverability than any public list. They score sending addresses and domains continuously using signals nobody else has: how many recipients open a sender's mail, how many mark it as spam, how many messages go to nonexistent addresses, how the volume from a given source changes over time. Public DNSBLs are one input among many, and for the largest providers they may not be a decisive one.
This is why a sender can be listed nowhere and still land in a spam folder, and why a sender can clear every public list and see no improvement. The public lists are the visible, checkable layer. The consequential layer is private, and each provider exposes only a partial view of it through its own postmaster tooling.
You can check whether you are on a public blocklist. You cannot check what the receiving provider thinks of you. Only one of those is the thing that decides.
Delisting, and the criticism that follows the model
Reputable lists offer self-service removal for the common cases. You look up the address, read the reason, fix it, and request delisting. Listings for transient compromise typically expire on their own once the source stops sending abuse.
The model attracts two persistent criticisms, and both are fair.
The first is collateral damage. Lists frequently escalate from an individual address to a larger block when abuse from a range is sustained and the range's operator is unresponsive. That is a rational lever against a negligent provider, and it means innocent customers who share the range are refused. If you are one of them, you have no relationship with the list operator, and the actual remedy is to pressure your provider or move.
The second is accountability. A DNSBL is a private organisation whose decisions are enforced by thousands of independent mail servers that chose to consult it. There is no appeal beyond the operator, no regulator, and no obligation to explain. Most established lists have earned their reputation through years of consistent behaviour. Some have not, and the practice of offering paid expedited removal, which a handful of lists have used, has drawn sustained criticism for the incentive it creates.
The check against all of this is voluntary consultation. A list that produces too many false positives gets dropped by the administrators who use it, and its influence decays. That is a real corrective, and it operates on a timescale of months while your mail is bouncing today.
What this means for running your own mail
People often conclude that self-hosted email is hard because the software is hard. The software is not the hard part. Postfix has been well documented for twenty years.
The hard part is that a new sender has no reputation, and in an anti-abuse system, no reputation is treated as suspicious rather than neutral. A brand-new address in clean space still has to earn a history before large providers extend it much trust. Meanwhile everything must be right: SPF, DKIM and DMARC aligned, forward and reverse DNS matching, TLS presented correctly, and a relay configuration that cannot be abused. The single most damaging failure is an open relay, because it converts your address into a spam source within hours and the resulting listings are both immediate and deserved.
Practical guidance for anyone in this position:
- Check your address before you need to. A lookup against the major lists takes seconds, and the reason code in the TXT record is more informative than the fact of the listing.
- Read the actual rejection. A 5xx refusal at connection time almost always names the list and gives a URL. Our guide to reading email headers covers where the bounce records this.
- Fix the cause before requesting removal. Delisting a still-compromised host produces a relisting and a worse standing.
- Use address space intended for mail. Consumer and dynamic ranges are policy-listed on purpose. This is not a rule you can be exempted from.
- Watch domain reputation separately. Your IP can be spotless while a link in your footer is listed on a URI blocklist.
Where encryption sits in this picture
Blocklists operate on connection metadata: the source address, the envelope, the domains in the message. They have nothing to do with whether the body is encrypted, and end-to-end encrypted mail is neither advantaged nor penalised by them.
What the encryption does change is the layer below. If a receiving server decides whether to accept a message at connection time, it never needs the contents, which is a mild but genuine argument that reputation-based filtering and content privacy are compatible in a way that content-scanning filtering is not. The trade-off between spam filtering and privacy is real, and it lives in the content layer, not this one.
Haven's mail path is subject to exactly the same reputation system as everyone else's, which is one of the reasons we treat outbound sending hygiene as a security property rather than an operations chore. A provider that lets its sending addresses be abused is not just inconveniencing itself. It is spending its users' ability to be heard.