Home › Guides

What Is a DNSBL (RBL)? How DNS Blacklists Work

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

A DNSBL (DNS-based blacklist, also called a DNS blocklist or RBL) is a list of IP addresses or domain names that a list operator considers a source of spam or abuse, published so that anyone can check it with an ordinary DNS lookup. Mail servers look up each connecting sender in one or more DNSBLs and then reject the message, accept it, or add the result to a spam score.

This guide explains how a DNSBL lookup works (reversed IP addresses, A and TXT records, IPv6 nibble format), the difference between IP-based and domain-based lists, how receivers actually use the answers, how blacklists differ from whitelists, why addresses get listed, and where a listing fits when your email is not being delivered. It is based on RFC 5782 and the official documentation of major list operators as of November 2026.

What DNSBL and RBL mean

RFC 5782, "DNS Blacklists and Whitelists," uses the umbrella term DNSxL for a DNS zone whose records identify hosts on a list. A blacklist is a DNSBL; a whitelist is a DNSWL. The two are built the same way. Only the meaning a receiver assigns to a match is different.

RBL stands for Real-time Blackhole List. According to the RFC, the first list of this kind was started in 1997 and became known by that name. Strictly speaking, RBL refers to that original list and its descendant, and the RFC notes the term is a registered service mark in the United States. In everyday use, though, "RBL" and "DNSBL" are used almost interchangeably, so "what is an RBL" and "what is a DNSBL" are effectively the same question.

RFC 5782 is an Informational document, not an Internet standard. It was produced by the IRTF Anti-Spam Research Group and represents that group's consensus on practices that improve interoperability between DNS blacklists and whitelists. It does not describe or recommend policies for adding or removing addresses; the RFC expects that to be covered in a separate document. In practice every operator sets its own listing and delisting policy.

How a DNSBL lookup works

A DNSBL lookup is a normal DNS query, so a manual check needs no special software: anything that can resolve a name can query a list. List operators may set usage terms, though. Spamhaus's public servers, for example, are free only for low-volume non-commercial use, and queries through public resolvers are not answered reliably (see below).

IPv4: reverse the address and append the zone

For an IPv4 address, write the four octets in reverse order and append the list's zone name. The structure is borrowed from reverse DNS. RFC 5782's example checks 192.0.2.99 against a list at bad.example.com by looking up:

99.2.0.192.bad.example.com

The A record says "listed," the TXT record says why

• A record. Every listed entry must have an A record. By convention its value is 127.0.0.2. The value is a signal, not an address, and must not be used as one; lists use the 127.0.0.0/8 range so that a value used by mistake does not create unwanted network traffic.
• Not listed. If the address is not on the list, there are no records for it, so the query normally returns NXDOMAIN.
• TXT record. A DNSBL should publish a TXT record describing the reason for the listing. Clients must check the A record and may also check the TXT record.
• Different values for different sublists. A combined list can return different 127.0.0.x values to show which sublist matched, or several A records at once. The meaning is specific to each list, so always read the operator's documentation. Our guide to DNSBL response codes covers the common ones.

From a terminal (the zone here is a placeholder):

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

Test entries

RFC 5782 requires IPv4 lists to contain an entry for 127.0.0.2 and not to contain one for 127.0.0.1. Clients are expected to check these test entries before trusting a zone, and not to use a zone that answers them incorrectly.

IPv6: the nibble format

An IPv6 address is written out in full as 32 hexadecimal digits, then reversed one digit (one nibble) at a time, with a dot between each, followed by the list's zone. The RFC's example, for 2001:db8:1:2:3:4:567:89ab on ugly.example.com:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.com

IPv6 lists must contain the test entry ::FFFF:7F00:2 (127.0.0.2 as an IPv4-mapped address) and must not contain ::FFFF:7F00:1. Not every list supports IPv6, so check the operator's documentation before relying on an IPv6 lookup.

IP-based and domain-based lists

Lists come in two broad kinds, depending on what they contain.

In RFC 5782's domain example, invalid.edu is checked against doms.example.net by looking up invalid.edu.doms.example.net. Domain-based lists sometimes go by the name RHSBL (right-hand-side blacklist). Their test entries use reserved names: the list must contain TEST and must not contain INVALID.

The Spamhaus Domain Blocklist (dbl.spamhaus.org) is a widely used example, and its documentation makes a few practical points:

• It is domain-only. Querying it with an IP address always returns a "listed" code, so it must not be configured as a generic IP DNSBL. Spamhaus recommends ZEN (zen.spamhaus.org) for IP lookups.
• You can query a full hostname; it matches if the host's domain is listed.
• During the SMTP session it is checked against the HELO string and the MAIL FROM domain. After the message is accepted, it is checked against domains in the headers and body, such as URLs and contact addresses.

The practical consequence: a clean sending IP does not guarantee delivery. A listed sending domain, or a listed domain linked in the message, can still cause a block.

How receiving servers use DNSBLs

RFC 5782 describes the typical setup. A mail server checks a configured set of DNSxLs on every incoming SMTP connection. A blacklist hit leads it to reject the connection; a whitelist hit leads it to accept. Alternatively, the results feed a scoring function that weighs them together with other signals. Filters that run after the message is received usually pull the IPs to test from the Received header fields or from URIs in the body.

Reject or score?

That choice belongs to the receiver. SpamCop's own FAQ calls its list an aggressive tool and recommends tagging or diverting suspected spam, or using the list as one factor in a score, rather than rejecting mail outright. It describes rejection settings as information for administrators who cannot use a more subtle approach.

Pitfalls receivers are warned about

• You are delegating judgment. Using a DNSxL hands part of your server's management to the list operator. The RFC says you should make sure the list's policies are consistent with your own.
• Dead lists. An operator shutting down a list might install a wildcard that lists every address. The test entries above are how a client notices this.
• Caching. Servers may cache results but must respect TTLs and discard expired records.
• Public resolvers. Spamhaus's FAQ says queries through Google Public DNS will in most cases return "not listed," so real listings are missed. Codes in 127.255.255.x are errors, such as 127.255.255.254 for a query through a blocked public resolver, and must not be read as "listed." Spamhaus notes some servers mistakenly reject all mail because of this and recommends running your own resolver.

This is one reason two checking tools can disagree about the same address: they may be asking through different resolvers.

Blacklists vs whitelists (DNSBL vs DNSWL)

A DNSBL and a DNSWL are queried the same way, but a match means the opposite. Per RFC 5782, network managers typically use DNSBLs to block traffic and DNSWLs to accept traffic preferentially. The same list can even serve as a blacklist in one context and a whitelist in another.

dnswl.org (list.dnswl.org) is an example of a whitelist. Its documentation says answers take the form 127.0.x.y, where x is a category and y a trust level from 0 (none) to 3 (high). It suggests letting listed hosts skip greylisting and blacklist checks, letting medium- and high-trust hosts skip spam filtering, and never skipping virus scanning. How much a whitelist entry exempts is still the receiver's decision.

Common reasons an IP or domain gets listed

Each operator sets its own criteria, and many keep the exact triggers private. The reasons below come from the operators' published documentation.

• Spam reports and spam traps. The SpamCop Blocking List contains IPs that sent mail reported by SpamCop users, with extra weight for mail to spam traps (addresses harvested or created by spammers). Its FAQ says that without further reports a listing lasts only 24 hours, and addresses are removed automatically when reports stop.
• Infected or compromised devices. The Spamhaus XBL lists IPs automatically on evidence such as malware, "free VPN" apps that relay third-party traffic through the device, participation in brute-force attacks, or attempts to relay mail with stolen credentials. If the cause remains, the IP is listed again the next time it connects.
• Misconfiguration and poor list hygiene. The Spamhaus CSS cites HELO names that do not match forward DNS, compromised websites and CMS installs, insecure setups, and poorly maintained mailing lists. It states the cause must be identified and corrected before removal.
• Policy listings. The Spamhaus PBL covers address space, often residential broadband, that should not send mail directly. Spamhaus says a PBL listing is not the result of anything the end user did; mail from such ranges is expected to go out through an authenticated SMTP server.
• Shared infrastructure. On shared hosting, another customer's sending can affect the IP you use. See what to do when a shared hosting IP is blacklisted.

Where DNSBLs fit when email is not delivered

A DNSBL listing is one possible cause of undelivered mail, not the only one. Wrong addresses, full mailboxes, recipient-side problems and missing authentication can also cause bounces. When a list is involved, the bounce message often names it or includes a lookup URL.

1. Read the bounce. Note the reply code and any list name or URL in the text.
2. Identify your sending IP and domain. Use the Received lines in the headers, or ask whoever runs the server.
3. Check the major lists at once. Use the blacklist checker, then confirm any hit on the operator's own lookup page.
4. Fix the cause. Work through the causes above. Requests made before the cause is fixed usually end in relisting.
5. Follow that operator's process. Some lists expire on their own, some take a removal request, and some only accept requests from the network owner. The decision to delist always belongs to the list operator, and a request is not a promise of removal.

Receivers also run their own filtering, so mail may not flow again the moment a listing ends. For the full troubleshooting sequence, see email blacklisted: how to read the bounce, and for authentication, SPF, DKIM and DMARC setup. If you cannot pin down the cause yourself, you can ask us for help.

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
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Domain Blocklist (DBL)
• Spamhaus: Exploits Blocklist (XBL)
• Spamhaus: Combined Spam Sources (CSS)
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• dnswl.org: Return codes and recommended usage

Related guides

All guides →