What is an email blocklist (DNSBL), and how does it work?

A message bounces with "Client host blocked using" and the name of a list you've never heard of. That's a DNS-based blocklist at work. This guide explains what email blocklists are, exactly how a lookup works, what the answers mean, how mail servers use them, and why some blocklist checks give misleading results. If you're already listed and need out, go straight to our blacklist removal guide.

What is an email blocklist?

An email blocklist is a list of IP addresses or domain names that a list operator considers a source of spam or abuse. Mail servers check senders against it and treat listed senders with suspicion. When the list is published in DNS, it's called a DNSBL (DNS-based blocklist). DNS, the Domain Name System, is the internet's lookup service for names and addresses, so every mail server can already query it.

You'll see several names for the same idea:

• Blacklist is the older word. Blocklist is the term most operators use now.
• RBL comes from the first list of its kind. RFC 5782 records that in 1997 Dave Rand and Paul Vixie began keeping a list of IP addresses that had sent them spam, which became the Real-time Blackhole List. Strictly, RBL means that MAPS list, but people use it for any DNSBL.
• RHSBL (right-hand side blocklist) is a list of domain names rather than IPs.
• DNSWL is an allowlist, a list of senders to trust more, published the same way.

RFC 5782 is an Informational document from the IRTF's Anti-Spam Research Group. It describes how DNSBLs work; it isn't a mandatory standard.

How does a DNSBL lookup work?

A DNSBL lookup turns the sender's IP address into a DNS name under the list's zone and asks whether that name exists. It takes one DNS query. Here are the steps for the documentation address 192.0.2.99 and a list at bl.example.net:

1. Take the connecting IP. The receiving server sees a connection from 192.0.2.99.
2. Reverse the octets. 192.0.2.99 becomes 99.2.0.192.
3. Add the list's zone. The query name is 99.2.0.192.bl.example.net.
4. Ask for an A record. If the name doesn't exist (an NXDOMAIN answer), the IP isn't listed.
5. Read the answer. Any A record means "listed". RFC 5782 says the value is "conventionally" 127.0.0.2, and a client "MUST interpret any returned A record as meaning that an address or domain is listed." Some lists, such as Spamhaus, also return documented error codes, covered below.
6. Optionally read the TXT record, which usually explains why and links to the removal page.

An example lookup with the dig tool might look like this:

$ dig +short 99.2.0.192.bl.example.net A
127.0.0.2
$ dig +short 99.2.0.192.bl.example.net TXT
"Listed for sending spam, see https://bl.example.net/lookup?ip=192.0.2.99"

IPv6 addresses work the same way, but are written as 32 reversed hexadecimal digits ("nibbles"). Domain lists skip the reversal: the query is the domain name followed by the list's zone, for example badsite.example.dbl.example.net.

What types of email blocklists are there?

Email blocklists differ by what they list and why. Knowing the type tells you what a listing really says about a sender.

The policy type is often misread. The Spamhaus DNSBL FAQ says "PBL is a list of IP space that should not be sending email directly to the Internet," and warns that "the PBL is not a list of 'spamming IP addresses'." A home connection on the PBL hasn't done anything wrong; it just shouldn't be running a mail server.

Large providers also keep their own lists. Microsoft says it uses a blocked senders list: "if a source IP address is identified as a potential threat to the service, the message source is added" to it (Microsoft Learn). Its connection filtering documentation also refers to "Microsoft's proprietary blocklists or non-Microsoft blocklists" (Microsoft Learn).

What do blocklist return codes mean?

Blocklist return codes tell you which sub-list matched, or that the query failed. Combined lists use different 127.x.x.x answers for different reasons. Spamhaus's zone documentation and its return-code notice list these codes, among others, at the time of writing (October 2026):

Two test entries help you check a list works. RFC 5782 says IPv4 lists "MUST contain an entry for 127.0.0.2 for testing purposes" and "MUST NOT contain an entry for 127.0.0.1". RFC 6471 adds that if the 127.0.0.2 test fails, "the DNSBL should be considered non-functional."

How do mail servers use blocklists?

Mail servers use blocklists in one of two ways: to reject the connection outright, or to add points to a spam score. The receiving server's administrator chooses, list by list. That's why one recipient bounces your mail while another accepts it.

Reject at connection time. In Postfix, a widely used open-source mail server, reject_rbl_client bl.example.net rejects a client whose reversed IP is listed. The Postfix documentation gives 554 as the default reply code. The bounce usually names the list, as in Microsoft's 550 5.7.1 client host blocked error.

Weigh several lists. Postfix's postscreen can score lists against a threshold. This example, from the Postfix documentation, treats one list as high confidence and blocks on the other two only when both agree:

postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = example.com*2, example.net, example.org

Add spam points. Content filters often treat a listing as one signal among many, alongside authentication and content checks. Our guide to how spam filters work shows where blocklists fit in that pipeline.

RFC 6471 is clear about who owns the result: "responsibility for filter decisions remains ultimately with you, the postmaster."

Why do blocklist checks sometimes give wrong answers?

Blocklist checks give wrong answers mainly because of where the query comes from. Spamhaus refuses queries sent through big public resolvers. Its FAQ names "Amazon, Quad9, Google, Cloudflare or some other public/open DNS resolver" as the most common cause of problems. It says the 127.255.255.* error codes "must not be taken to imply that the object of the query is 'listed'," and that "some mail servers mistakenly reject all mail" because they treat the error as a listing.

That cuts both ways. A mail server that ignores error codes may block everyone, and a checker that treats a refused query as "not listed" may give you false reassurance. Our Blacklist Checker shows lists that refuse public lookups as "not tested", with a link to check them directly, rather than calling them clean.

Lists also shut down. RFC 6471 records that some DNSBLs shut down in a way that would "list the entire Internet," and says operators "MUST NOT" do that. If a server suddenly rejects everyone, check whether a list it uses has died.

What makes a blocklist trustworthy?

A trustworthy blocklist publishes its criteria, follows them, and makes removal free and prompt. RFC 6471 sets out the operating practices:

• Published criteria. "A DNSBL MUST abide by its stated listing and delisting criteria."
• Temporary listings. Listings "SHOULD be considered temporary and should expire on their own" once the reason is gone.
• Prompt responses. An operator "SHOULD respond within 2 days and MUST respond within 7 days" to removal requests.
• No delisting fees. Negative lists "MUST not charge fees or require donations for delisting or 'faster handling'," and lists that do are "RECOMMENDED" not to be used.
• Graceful shutdown. Warnings first, and never a shutdown that lists everyone.

If a list asks you to pay for removal, RFC 6471's guidance is that receivers shouldn't be using it.

What should you do if your IP or domain is listed?

If your IP or domain is listed, find the cause before you ask for removal, or you'll be listed again. Use this checklist:

1. Confirm the IP that actually sends your mail. Read the bounce or check the headers of a sent message with the Email Header Analyzer.
2. Check it with the Blacklist Checker, and use each list's own lookup page for lists marked "not tested".
3. Read the listing reason in the TXT record or on the list's site.
4. Fix the cause: a compromised account or website, an infected device, an open relay, or a missing PTR record.
5. Request removal through the list's own page. For Microsoft's own list, use the delist portal at sender.office.com, which Microsoft says "might take up to 24 hours or longer."

Our blacklist removal guide covers each major list's process.

Next steps

• Check your sending IP with the free Blacklist Checker, then confirm your reverse DNS is set.
• If mail is bouncing, look up the exact error in our SMTP error codes reference.
• Make sure SPF, DKIM and DMARC pass for everything you send. A good sender reputation makes a listing less likely and recovery faster.
• On the receiving side, you don't have to maintain DNSBL settings yourself. iBlockSpam filters spam, phishing and malware at the MX level, before mail reaches your mailboxes. See how it works.