exim.ro

DNS blocklists: how they work and how to get delisted

How DNS blocklists (DNSBLs) answer, what their return codes mean, why a check can come back "unavailable", and what to do when your IP is listed.

Updated 4 min read6 sections

Run the Blacklist check

A DNS blocklist (DNSBL) is a list of IP addresses or domains that its operator considers sources of spam or abuse, published through the DNS so that mail servers can look an address up in a few milliseconds. Many receiving servers consult one or more lists while a message is being delivered and reject or score it according to the answer. The Blacklist check asks several public lists at once.

How a lookup works

The convention is described in RFC 5782. To ask whether 192.0.2.99 is listed on bl.example.org, the octets are reversed and the list's zone is appended:

99.2.0.192.bl.example.org   IN A
  • NXDOMAIN (the name does not exist) means not listed.
  • An A record, normally in 127.0.0.0/8, means listed. The value is a code; many lists use different codes for different reasons.
  • A TXT record at the same name often explains the listing and links to the list's page.

Domain lists work the same way with the domain name instead of reversed octets: example.com.dbl.example.org.

Return codes are not all listings

Lists also use A records to report problems with the query, not with the address. For example, Spamhaus documents 127.255.255.254 for queries that arrive through a public or open resolver and 127.255.255.255 for an excessive number of queries; SURBL and URIBL answer 127.0.0.1 when they refuse a query. Software that treats every A record as "listed" marks everything as spam; software that ignores these codes believes everything is clean.

That is why the checker only counts a code as a listing when the list documents it as one, reads every documented refusal code as unavailable, and treats any code the list does not document the same way. An unavailable answer is never shown as "not listed".

Test points and health checks

RFC 5782 requires IPv4 lists to list 127.0.0.2 and never list 127.0.0.1, and domain lists to list TEST and never list INVALID. Checking both shows that the list is answering and that it has not been replaced by a wildcard. The checker asks every list about its test points every few minutes and treats a list that fails as unavailable until it passes again. You can check the test address yourself by entering 127.0.0.2.

Why some lists refuse queries

Most free lists limit who may query them: by volume, by purpose (non-commercial use only), or by requiring a registered resolver or an API key. Many also refuse queries that come through large public resolvers, because those carry traffic from millions of users. A mail server should query lists through its own resolver. Before relying on a list, read its usage terms.

If your address is listed

  1. Find out why. Follow the list's link from the result; most show the reason and the date. The TXT record often says the same.
  2. Fix the cause first. Typical causes are a compromised mailbox or web form sending spam, an open relay, a missing or generic reverse DNS (PTR) record, or sending from an address range the provider marks as not meant for mail servers.
  3. Request removal through the list's own procedure. Some lists expire listings on their own after the problem stops; others need a request.
  4. Check again after the list's own delay. Answers are cached for a while everywhere, including here (15 minutes).

A clean result is not a guarantee of delivery: receivers also use their own reputation data, authentication (SPF, DKIM, DMARC) and content filters. The Email DNS check covers the authentication side.

Sources