How IP blocklists actually work: DNSBLs, listings and delisting

A blocklist is a DNS zone

The classic blocklist is a DNSBL, a DNS-based blocklist, and the mechanism is elegant. To ask whether 203.0.113.10 is listed, a mail server reverses the octets and queries 10.113.0.203.<zone> as an ordinary DNS name. If the name resolves, typically to an address in the 127.0.0.x range whose last octet encodes which sub-list matched, the IP is listed; if the query returns no record, it is not. A TXT record alongside often carries the reason and a URL.

DNS is the delivery mechanism because it is fast, cached and universally available: a mail server can afford one extra lookup per connection, and the list operator can serve enormous query volumes without bespoke infrastructure. The elegance has a consequence worth knowing: an answer is a present-tense fact about the zone at query time. The protocol carries no history, which is why the dates behind a listing have to come from somewhere else.

The list families

Lists differ mainly in how an entry gets created, and the families behave very differently. Spamhaus, whose lists are the ones bounce messages cite most, is the clearest example of the split.

• Investigation lists (Spamhaus SBL is the model) carry entries a human or a research process created deliberately, often covering whole ranges tied to a spam operation. Serious to be on, slow to change, and usually accompanied by a written reason.
• Automated compromise lists (the XBL shape) list single addresses observed behaving badly, typically infected or abused machines caught by traps and telemetry. High volume, machine-created, and entries age out once the behaviour stops.
• Policy lists (the PBL shape) are not accusations at all: they enumerate space that should never send mail directly, such as dynamic consumer ranges, marked either by the network that holds it or by the list operator's own research. Being on one is normal for a home connection and only a problem if you try to run a mail server from space marked that way.
• Routing lists (the DROP shape) name hijacked or criminal-controlled ranges and are consumed by networks rather than mail servers, dropping traffic wholesale.

The families answer the question a bounce never does: what kind of problem you have. A policy listing is a configuration mismatch, an automated listing is a behaviour that needs to stop, and an investigation listing is a relationship with a list operator you are going to have to work through.

How addresses get on

Entries come from traps and telemetry, from complaint volume, from pattern detection, and from human investigation, in whatever mix a list's operator has built. Two properties of listings matter more than the trigger.

First, granularity: listings are frequently applied at range level, a whole /24 or an entire allocation, because operators know spammers rotate through adjacent addresses. That is why one bad tenant can list a block for everyone, why your clean address can be listed for a neighbour's sins, and why checking one address and finding it clear tells you almost nothing about a range. Second, inheritance: entries attach to addresses, not holders, so a listing created before you acquired the space is still there after, which is the whole story of transferred ranges arriving blocked.

How addresses come off

Depends entirely on the family. Automated entries decay on their own once the triggering behaviour stops, on timescales from hours to weeks; the fastest fix is genuinely to stop the behaviour and wait. Investigation entries come off through the operator's process: a delisting request that explains what changed, made after the cause is actually fixed, and, for inherited entries, the single most effective sentence is the dated one, that the listing predates your acquisition of the space. Policy entries are more often routed around than removed, with mail from such space going out through a smarthost, but they can be lifted: the netblock operator can update the policy data for space that has legitimately changed character, and on the Spamhaus PBL the holder of a static address running a mail server can exclude that single address themselves, an exclusion that lapses after a year.

Two cautions. Paying for expedited delisting is only worth it if the receivers you care about actually consult that list, which the bounce messages will tell you. And a list that has shut down cannot delist anyone, while cached copies of it keep answering elsewhere, which is one more way the past outlives its cause.

Who actually consumes them

Mail servers check lists at connection time and either reject outright or feed the answer into a score alongside content and authentication signals; a listing that scores rather than blocks explains mail that arrives but lands in spam. Beyond mail, blocklist answers feed firewalls, fraud scoring and security products, which is why a listed range can also see API calls rate-limited or signups declined with no bounce message to explain it. Consumption is uneven: nobody checks every list, so a listing on an obscure zone may cost you nothing while a listing on a widely consulted one costs you everything, and effort should follow consumption, not alphabetical order.

Reading listings like evidence

A listing is a claim by one operator, at one granularity, at one moment. Read it with all three qualifiers attached. Which list, because the family determines what it means. What granularity, because a range entry indicts neighbours and a single-address entry does not. And when, because a listing's date against your tenancy decides whether it is your problem to explain or your predecessor's to disclaim. That last reading needs history rather than a point-in-time check: what carried listings before you, what has been flagged since, and on which dates, is exactly the record worth reading before space becomes yours and worth watching after. One listing among clean answers is a detail; the same listing beside a year of dated flags is a verdict, and only the dated record tells you which one you are looking at.