Skip to content
Guide

What a blocklist listing means, and what to do about it

A blacklist is a DNS zone that answers one question about one address, and receivers weigh the answer differently. Understanding how the query works is what separates a listing that explains a delivery problem from one that explains nothing at all.

Updated 5 August 2026 8 minute read

How a DNSBL query works

A DNS blocklist — the mechanism is the same whether the list calls itself a blacklist, a blocklist or a DNSBL — publishes its data as an ordinary DNS zone. To ask whether an IPv4 address is listed, a receiver reverses the four octets, appends the zone name, and looks up an address record. An answer means listed; NXDOMAIN means not listed.

That design is the reason the check is cheap enough to run on every connection. There is no API, no authentication and no rate negotiation in the protocol itself: it is a cached DNS lookup, answered in the time any other lookup takes, which is why a receiving server can consult several lists before it has finished the greeting.

RFC 5782 documents the convention, including two test entries every well-behaved list is expected to carry: 127.0.0.2 must always be listed, and 127.0.0.1 must never be. Querying both is how a checker distinguishes a list that says no from a list that is not answering.

The octets of the address are reversed and the zone appended. The address record encodes the reason; the TXT record explains it.
; is 192.0.2.25 listed in dnsbl.example.net?
25.2.0.192.dnsbl.example.net. IN A

;; ANSWER
25.2.0.192.dnsbl.example.net. 300 IN A   127.0.0.4
25.2.0.192.dnsbl.example.net. 300 IN TXT "listed: spam trap hits 2026-08-01"

What the answer encodes

The address returned is always inside 127.0.0.0/8, and the final octet is a code the list defines for itself. One list may use 127.0.0.2 for direct spam sources and 127.0.0.4 for trap hits; another uses an entirely different mapping, and a composite zone that merges several sub-lists uses the code to say which one matched.

The accompanying TXT record is the human-readable explanation, and usually the delisting URL. Any checker worth using reports both — a listing without its code is not actionable, because the code is what tells you whether you are looking at a spam observation, a policy listing for a dynamic address range, or an entry inherited from the block your provider allocated you from.

IP lists and domain lists

An IP list is about the machine that connected. It answers whether this address has been seen sending unwanted mail, and it is consulted at connection time, before the message exists. A listing here is why a connection is refused outright.

A domain list is about names found inside the message: the sending domain, the domains in links, sometimes the domain of the reply address. The query is the domain with the zone appended, with no reversal, and it is evaluated after the message has been accepted for inspection.

The distinction matters when you are diagnosing. An IP listing affects everything sent from that address regardless of content. A domain listing follows the name, so it affects mail sent through any provider and survives changing your sending platform entirely — and it can be caused by a link in your message pointing at somebody else's compromised site.

Why a listing happens

  • Mail reached a spam trap: an address that has never opted in, either one seeded deliberately or an abandoned mailbox recycled into a trap. Old purchased lists and never-cleaned lists are the usual route.
  • A compromised account or web application began sending through your server. This is the most common cause of a sudden listing on an address with years of clean history.
  • Complaint rates from a mailbox provider's feedback loop crossed a threshold.
  • The address is inside a range listed by policy — dynamic or residential allocations, or ranges an operator has declared should not be sending mail directly.
  • An open relay, an open proxy or an unauthenticated submission port was found by a scan.
  • Reputation inherited from neighbours on shared infrastructure, where the listing is of the range rather than of you.
  • Sudden volume from an address with no sending history, which several lists treat as a signal in its own right.

Checking a listing properly

Check the address that actually connects to the recipient, which is the address on the outbound interface of your sending host, not the address of your website and not the MX target. Where mail leaves through several hosts, all of them need checking.

Check the sending domain and the domains you link to separately against domain lists, because a clean IP address and a listed link domain produce a delivery problem that no amount of IP investigation will explain.

Treat a checker that reports only listed or not listed as incomplete. You want the response code, the TXT explanation and the identity of the zone, because the next step depends entirely on which list and which reason.

A listing is a point-in-time answer with a TTL on it. Re-check after any change rather than assuming propagation, and remember that receivers cache these answers for as long as the zone permits.

How delisting works

Nearly every list operates the same way: fix the cause, then request removal, and expect the request to be refused or immediately re-listed if the cause is still active. Some lists expire entries automatically after a quiet period and have no removal form at all, which is by design rather than an oversight.

Before requesting removal, establish what sent the mail. That means reading the outbound logs for the period the listing names, finding the account or application responsible, closing it, and confirming the queue is clear. A delisting request submitted while a compromised script is still running teaches the list that your removals are not to be trusted.

Self-service removal is normally available once per listing. Repeated use is itself a signal, and some operators reduce or withdraw it for addresses that keep returning. Where a listing covers your provider's range rather than your address, the request has to come from the provider.

What a listing does and does not mean

A listing is one receiver-side input among many. Every receiving operator chooses which zones to consult, whether a hit rejects the connection or merely adds to a spam score, and how much weight to give each list. Two lists reporting the same address can have entirely different consequences, and a listing on a zone almost nobody queries may have no effect on delivery whatsoever.

It also does not mean you sent spam. Policy listings describe the type of address rather than its behaviour, range listings describe your neighbours, and trap hits sometimes describe an address on a list you bought from somebody who described it as opted in.

What a listing does mean is that something is worth checking, and that if delivery to a particular receiver is failing, this is one of the few explanations you can confirm from outside. Read it as evidence to be corroborated against the rejection message you actually received.

Check this on your own domain. The blacklist check reads the live records and reports what a receiver would see.

Open the blacklist check

Common questions

How does a mail server check a blacklist?
It reverses the octets of the connecting IP address, appends the list's zone name and performs an ordinary DNS lookup. An address record in 127.0.0.0/8 means listed, and its last octet encodes the reason; NXDOMAIN means not listed. Because it is a cached DNS query, a receiver can consult several lists during the SMTP greeting.
What is the difference between an IP blacklist and a domain blocklist?
An IP list is queried on the address that connected, before the message is transmitted, and affects everything sent from that host. A domain list is queried on names found inside the message — the sending domain or a domain in a link — and follows the name across providers, so changing sending platform does not clear it.
How long does delisting take?
Removal itself is usually applied within minutes of a successful request, but receivers cache DNS answers for the zone's TTL, so the effect is not immediate everywhere. The larger delay is upstream: a request submitted before the cause is fixed will be refused, or the address will simply be listed again on the next observation.
Does a blacklist listing mean my mail will be rejected?
Not necessarily. Each receiving operator decides which lists to consult and whether a hit refuses the connection or only contributes to a spam score. A listing on a widely used zone is a serious delivery problem; a listing on an obscure one may have no measurable effect. Corroborate it against the actual rejection messages you are receiving.

Keep reading

Related checks, definitions and guides.