Home › Guides

DNSBL Return Codes Explained: 127.0.0.2, 127.255.255.x and NXDOMAIN

Published 2026-11-03 ／ Updated 2026-11-03 ／ By Yuki Nakazawa

A DNSBL lookup that returns an address in 127.0.0.0/8 means the IP or domain is listed; an NXDOMAIN answer means it is not. Beyond that, the exact number is list-specific, some 127.x answers are error codes rather than listings, and SERVFAIL or a timeout tells you nothing about listing status at all.

This guide walks through the conventions recorded in RFC 5782 and the return codes that Spamhaus, SpamCop and UCEPROTECT document on their own pages. It is based on those official pages as of November 2026. Lists change their data and policies, so check the operator's documentation before acting on a result. If you need the background on how blocklists work, start with what a DNSBL (RBL) is.

The basics: what RFC 5782 says about return codes

RFC 5782, published in February 2010, describes how DNS blacklists and whitelists are queried and what their answers look like. It is an Informational document, not a Standards Track specification: it records common practice, and the details of value assignments are left to each list operator.

How a lookup is built

For IPv4, you reverse the order of the octets and append the list's zone. To check 192.0.2.99 against bl.example.com:

dig +short 99.2.0.192.bl.example.com A
dig +short 99.2.0.192.bl.example.com TXT

For IPv6, the address is written as 32 hex nibbles in reverse order, followed by the zone. Domain-based lists simply take the domain name followed by the zone name; the RFC notes that name-based lists are far less common than IP-based ones.

The A record: listed or not

• Listed: the list returns an A record. The RFC says all A values should be in 127.0.0.0/8, to prevent unwanted network traffic, and that the value conventionally is 127.0.0.2.
• Not listed: there must not be any records for the address. In DNS terms, the answer is NXDOMAIN, meaning the name does not exist.
• The A record value must not be used as an IP address. 127.0.0.2 is a flag, not a server to connect to.

The TXT record: the reason and a URL

According to the RFC, DNSBLs should publish a TXT record describing why an entry is listed, and that reason often includes a URL with more information. Client software must check the A record and may check the TXT record. The TXT text is often used in the SMTP error message, so a bounce message may contain a lookup or removal URL taken from it.

Why lists return different numbers: sublists and bit masks

A value other than 127.0.0.2 usually means the zone combines several sublists. RFC 5782 describes three ways to represent them: subdomains, multiple A records, and bit-encoded values.

• Multiple A records: each sublist has its own value, and the list returns one A record for every sublist the address appears on.
• Bit masks: each sublist is assigned a bit, and the answer is the logical OR of the bits for every sublist that matches. In the RFC's example, an address on the 127.0.0.2 and 127.0.0.4 sublists returns 127.0.0.6.

The key point is that the RFC itself states there is no widely used convention for mapping sublist names to values. The same number can mean different things on different lists. Always read a return code together with the zone that produced it, against that list's own documentation. The RFC also says client software should be able to apply bit masks and value range tests to returned values.

Spamhaus ZEN is a good example of the multiple-answer style. Its documentation says a query generally produces several distinct answers in the same DNS response, one for each dataset on which the IP is listed, with a different return code for each dataset. Seeing two or three codes at once is normal.

Return codes for major blocklists

The table below covers return codes that the operators document on their official pages.

• Spamhaus: ZEN combines the SBL, CSS, XBL and PBL and covers IP addresses only; domains are checked against the DBL. The DBL uses 127.0.1.0/24 and the Zero Reputation Domains list uses 127.0.2.0/24. Because the DBL always answers an IP query with 127.0.1.255, it cannot be used to check IPs. For what each Spamhaus list means and how to request removal, see our Spamhaus removal guide.
• SpamCop: the official FAQ gives 127.0.0.2 as the response that indicates a listed IP. It also recommends giving users access to filtered mail, for example by tagging it or moving it to a separate folder, rather than rejecting it outright. Removal is covered in our SpamCop delisting guide.
• UCEPROTECT: the DNS usage page lists the three zone names but does not describe return values. It says the DNS method is really only useful for small to medium mail servers and suggests rsync for systems making more than 100,000 requests per day. The levels are explained in our UCEPROTECT Level 2 and 3 guide.
• Barracuda: its return values are not covered here. Check Barracuda Central's own pages.

127.255.255.x and public resolvers: answers that are not listings

Spamhaus reserves 127.255.255.0/24 for error codes. They can be returned for any zone, and the official FAQ states that they must not be taken to mean the queried object is listed.

Why public resolver results are unreliable

Spamhaus's FAQ says that when you query through large public resolvers, in most cases you get a not-listed (NXDOMAIN) reply. In other words, a listed IP can look clean. The same FAQ names using Amazon, Quad9, Google, Cloudflare or another public resolver as the most common cause of the opposite problem, where a list appears to block the whole internet.

Some resolvers also rewrite NXDOMAIN answers and return an IP address for names that do not exist. A mail server can mistake that for a listing. The FAQ suggests instructing the mail server to ignore any response that is not in 127.0.0.0/8, running your own resolver, or contacting your ISP or DNS provider. To see which resolver you are actually using, the FAQ gives this check:

dig txt whoami.fastly.net

If you run DNSBL filtering on your own mail server, also make sure it does not reject mail whenever it sees a 127.255.255.x answer. Spamhaus describes that as a misconfiguration.

NXDOMAIN vs SERVFAIL vs timeout

Every DNS response carries a response code (RCODE), defined in RFC 1035. When you read a DNSBL result, separate the RCODE from the A record value.

RFC 5782 does not say how clients should handle a list that fails or does not respond. Reading SERVFAIL or a timeout as either listed or not listed is a mistake. Retry later or query from a different path.

Use the test entries to check that a list works

RFC 5782 requires IPv4 lists to contain an entry for 127.0.0.2 and not to contain one for 127.0.0.1. IPv6 lists use ::FFFF:7F00:2 (listed) and ::FFFF:7F00:1 (not listed), and domain lists use the reserved name TEST (listed) and INVALID (not listed).

dig +short 2.0.0.127.zen.spamhaus.org A
dig +short 1.0.0.127.zen.spamhaus.org A

If the first query returns a listing code (a 127.x value other than 127.255.255.x) and the second returns nothing, lookups against that list are working. If the first returns 127.255.255.x, your query path is being refused. The RFC says clients should periodically check test entries and should not use a list without correct ones. It also notes that operators shutting down a list have sometimes removed every entry, or installed a wildcard that lists every address. If 127.0.0.1 also comes back as listed, suspect the list or your query path, not your own IP.

A practical way to read your own result

1. Pick the right IP or domain. Use the IP in the bounce message, or the sending server's IP from the Received lines in the message headers.
2. Check several lists at once. Our blacklist checker runs the major lists in one pass.
3. Read each code together with its zone. A listing code in 127.0.0.0/8 (other than 127.255.255.x) means listed; look up what that value means on that list. A 127.255.255.x answer, SERVFAIL or a timeout means the status is still unknown.
4. Look at the TXT record and the operator's lookup page. Many lists return a reason or URL. Treat the operator's own lookup page as the authoritative result.
5. Fix the cause, then follow that list's removal process. Each operator decides whether and when to delist. If the cause remains, the listing usually comes back.

For the full troubleshooting path when mail is bouncing, see email blocked by a blacklist. If you need help interpreting results or tracking down the cause, you can ask us about delisting.

FAQ

Official pages used

The facts in this article were checked against the official pages below at the time of publication. Policies and behavior change without notice, so check the official pages before relying on anything important.

• RFC 5782: DNS Blacklists and Whitelists
• RFC 1035: Domain Names - Implementation and Specification (RCODE)
• Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
• Spamhaus: ZEN Blocklist
• Spamhaus: Domain Blocklist (DBL)
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• UCEPROTECT: Using DNS Lookups

Related guides

All guides →