How DNS Blocklists Work: DNSBL, Spamhaus Zones, and RPZ

DNS blocklists — also called DNSBLs or RBLs (Real-time Blackhole Lists) — are DNS-based databases that allow mail servers, firewalls, and resolvers to check in milliseconds whether an IP address or domain name has a reputation for sending spam, hosting malware, or belonging to other threat categories. The elegance of the mechanism is that it reuses the existing DNS infrastructure: any system that can make a DNS query can consult a blocklist, with no special client software required.

The DNSBL Query Mechanism

Every DNSBL query follows the same pattern: take the IP address you want to check, reverse its octets, and append the blocklist's zone name. Then query for an A record.

For example, to check whether 192.0.2.4 is listed on Spamhaus ZEN:

4.2.0.192.zen.spamhaus.org

If the IP is listed, the query returns a 127.0.0.x address. If it is not listed, the query returns NXDOMAIN. The specific value of x in the return code identifies which sub-list the IP appears on — more on this below. The querying MTA checks for any response in the 127.0.0.0/8 range to make a binary reject/accept decision, or inspects the specific return code to make policy decisions.

For IPv6, the address is reversed nibble-by-nibble. The address 2001:db8::1 becomes:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.zen.spamhaus.org

Spamhaus Zones

Spamhaus is the dominant DNSBL operator and runs several distinct lists, each targeting a different category of IP address. Understanding the zones is essential because listing on different zones carries different implications for delisting and policy:

The PBL is important to understand: it does not indicate that an IP has sent spam. It indicates that the IP is in a range where the network operator has stated that outbound SMTP to port 25 should not originate. Residential ISP subscribers and CGNAT pools are commonly listed here because users in these ranges should be routing mail through their ISP's or email provider's submission server (port 587) rather than connecting directly to recipient MTAs.

How the Query Fits Into the Email Flow

The key architectural advantage of connection-time DNSBL checking is efficiency. A traditional content filter must accept the entire message — headers, body, attachments — before it can analyze it. A DNSBL check fires the moment the remote IP connects, before the MTA has even sent its greeting banner in some implementations. Rejected connections consume negligible resources and generate no delivery status notifications. For a high-volume mail server receiving millions of connection attempts per day, this matters enormously.

Domain Blocklists

Domain-based blocklists check URIs and domain names rather than IP addresses. Three widely used ones:

• DBL (Spamhaus Domain Block List): lists domain names found in spam message bodies, in From/Reply-To headers, and in phishing URLs. Query by prepending the domain: example.com.dbl.spamhaus.org. Return codes distinguish spam domains (127.0.1.2), phishing (127.0.1.4), malware (127.0.1.5), and botnet C&C (127.0.1.6).
• SURBL: lists domains appearing in spam message bodies, focusing on click-through URLs. Uses multi.surbl.org with bitmask return codes to indicate which sub-lists the domain appears in.
• URIBL: similar to SURBL; lists domains from URI payloads in spam. multi.uribl.com returns bitmask codes for different categories.

How MTAs Integrate DNSBLs

Mail transfer agents consult DNSBLs at connection time — before accepting any message data — which allows them to reject spam at the SMTP level with minimal resource cost. In Postfix, the postscreen daemon handles this efficiently by checking the connecting IP before handing the session to an smtpd process.

A minimal Postfix postscreen configuration using Spamhaus ZEN:

postscreen_dnsbl_sites =
    zen.spamhaus.org*3
    bl.spamcop.net*2
    b.barracudacentral.org*2

postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = enforce

Each blocklist is assigned a weight. When the sum of weights for listed blocklists exceeds the threshold, the action is taken. enforce means the connection is rejected with a 550 SMTP error after completing the postscreen handshake tests. Using zen.spamhaus.org*3 means a ZEN listing alone crosses the threshold of 3 and triggers rejection — a single authoritative listing is sufficient.

The specific reject message Postfix sends can include the return code and a lookup URL, which helps postmasters at the sending side diagnose and resolve listings. Many organizations configure bounce messages that say which DNSBL caused the rejection and link to delisting information.

Listing Causes and Delisting

IP addresses land on blocklists through several paths:

• Spam trap hits: messages delivered to addresses that have never signed up for email (honeypots). A single hit is often evidence of harvested-address spamming.
• User complaints: recipients marking messages as spam in their mail client, which some providers forward to feedback loops.
• Botnet or malware detection: XBL listings come from feeds like CBL (Composite Blocking List) and Abusix, which detect IPs exhibiting bot-like behavior.
• ISP notification: PBL listings are submitted by ISPs to mark their dynamic/residential ranges.

Delisting procedures vary by list and category. PBL delisting is self-service via the Spamhaus website if you operate a mail server on a static business IP — you simply submit the IP with a description of its role, and removal is usually immediate. SBL and XBL listings require investigation and remediation (cleaning malware, stopping the spam source) before removal is granted. Some severe SBL listings, particularly of known spam operations, are permanent.

False Positives and Shared-IP Pain

DNSBLs are blunt instruments. A single IP address shared by many users — as in CGNAT deployments, cloud provider NAT gateways, or large office NATs — can be blocked because one user on that IP sent spam, affecting all other users sharing it. This is a structural problem that worsened as IPv4 exhaustion drove wider CGNAT deployment.

Cloud provider outbound IPs (AWS, Azure, GCP) are particularly prone to appearing on blocklists because they are frequently misused for spam and are in ranges that are pre-listed on PBL. Running a mail server on a cloud VM sending directly to port 25 is almost guaranteed to encounter DNSBL rejections from major receivers. Best practice is to relay through a dedicated email delivery service (SES, SendGrid, Mailgun) that maintains IP reputation and handles DNSBL management.

Response Policy Zones (RPZ)

RPZ (RFC 5782 extension, widely implemented since BIND 9.8) allows a DNS resolver to apply custom policies based on blocklist data, rewriting DNS responses in real time. An RPZ zone contains override records: when a query matches a listed domain or IP, the resolver can return NXDOMAIN, a walled-garden IP (redirecting to a warning page), or a custom record — rather than the real answer.

This moves blocklist enforcement from the MTA to the resolver, covering all traffic types — not just email. A resolver with an RPZ feed for malware C&C domains will prevent infected hosts from beaconing out, regardless of which application the malware uses. ISPs, enterprises, and managed security service providers use RPZ feeds from Spamhaus, Cisco Talos, and others to provide DNS-layer filtering.

Public Resolver Filtering

Quad9 (9.9.9.9) is the most prominent example of a public resolver that performs DNSBL-style filtering at query time. It aggregates threat intelligence from over 20 sources (including Spamhaus DBL, IBM X-Force, and others) and returns NXDOMAIN for domains on its blocklist. This provides protection to any user who points their system at 9.9.9.9, without requiring any MTA-level configuration. Cloudflare's 1.1.1.1 for Families service (1.1.1.2 / 1.1.1.3) similarly blocks malware and adult content categories via DNS.

DNSBL Caching and Operational Considerations

DNSBL operators run authoritative DNS servers that handle billions of queries per day. Resolvers caching DNSBL responses is essential to the system's scalability, but it creates a latency tradeoff: a just-listed IP will continue to receive positive (allowed) responses from resolvers that have cached NXDOMAIN until the TTL expires. DNSBL zones typically use short TTLs — Spamhaus uses 5 minutes for ZEN — to ensure new listings propagate quickly while keeping query volume manageable.

Operators of mail infrastructure should configure their resolvers to forward DNSBL queries to the authoritative servers directly (or use a dedicated DNSBL resolver) rather than letting a general-purpose caching resolver accumulate stale DNSBL data. High-volume deployments often run a local copy of the DNSBL zone via RSYNC or the Spamhaus Data Query Service (DQS) to eliminate the DNS query latency entirely.

There is also an abuse vector: public DNSBL lookups can be rate-limited by the DNSBL operator. An MTA making thousands of queries per second from a single IP will find its queries answered with an error code or a constant positive return, effectively making the DNSBL useless. Organizations with significant mail volume must use the DNSBL provider's commercial feeds or authenticated access credentials.

Integration With DKIM, SPF, and DMARC

DNSBLs operate on envelope information — the connecting IP and the message's SMTP envelope — before the MTA knows anything about the message content or authentication status. SPF, DKIM, and DMARC operate later in the pipeline on the message headers and body. These mechanisms are complementary rather than overlapping.

A common layered defense applies them in sequence:

1. DNSBL check on connecting IP (postscreen) — reject obvious spam sources before accepting the connection
2. SPF check on the MAIL FROM domain against the connecting IP — reject senders that fail SPF hard-fail (-all)
3. DKIM signature verification — validate the message has not been tampered with and originates from a domain key published in DNS
4. DMARC policy enforcement — apply the sender domain's published policy (quarantine or reject) for messages failing SPF/DKIM alignment
5. Content filtering — analyze the message body using spam scoring, URI blocklist lookups (SURBL/URIBL), and bayesian filters

URI blocklist checks (step 5) query domain blocklists like SURBL and URIBL against every domain found in hyperlinks within the message body. A message from a clean IP, passing SPF and DKIM, can still be caught if it contains a link to a phishing domain that was listed on DBL after the domain was registered.

The DNSBL Under Attack

The 2013 attack on Spamhaus — one of the largest DDoS attacks ever recorded at the time, peaking at 300 Gbps — was a direct retaliation against the blocklist infrastructure. A spam operation whose hosting provider had been listed on the SBL organized a DNS reflection/amplification attack against Spamhaus's infrastructure. The attack leveraged the same DNS infrastructure that DNSBLs depend on: open resolvers around the world were used to amplify traffic toward Spamhaus's authoritative servers. The full story is covered in the 2013 Spamhaus DDoS attack article.

Explore It Live

• 9.9.9.9 — Quad9, a public resolver that uses blocklist-based filtering for malware domains
• AS13335 — Cloudflare, which operates 1.1.1.1 for Families with DNS-layer filtering
• AS9003 — Spamhaus's own autonomous system, whose IP space was the target of the 2013 DDoS retaliation