DNS Blocklists and the Spamhaus Zones

When a widely used blocklist lists your IP address or domain, receivers across the internet can refuse your mail at the same moment. Spamhaus is the most widely consumed reputation provider in email.

Mailbox providers such as Comcast, RoadRunner and Sky use commercial spam filters and reputation data from providers like Cloudmark and Spamhaus. The largest freemail providers (Gmail, Hotmail and Outlook.com, and Verizon Media, the former Yahoo and AOL) rely mostly on filtering they built themselves on their own user data, and may or may not combine it with commercial data. A listing by a widely adopted reputation provider can therefore block delivery at thousands of receiving networks at once.

There are hundreds of blocklists in the industry, but only a few have broad impact. Any comprehensive tool for checking blocklists (see Deliverability Testing Tools) will show your IP or domain listed somewhere, so how seriously to take a listing depends on who issued it. A Spamhaus SBL listing has enormous reach, while a listing on a defunct or obscure list can be ignored.

How a DNSBL works

A DNS-based blocklist (DNSBL) publishes its listing data as a DNS zone. The receiving mail server checks a connecting IP address (or a domain seen during the transaction) with an ordinary DNS A record query:

• IP lists: reverse the octets of the IP address and append the zone. To check 192.0.2.99 against ZEN, query 99.2.0.192.zen.spamhaus.org.
• Domain lists: append the domain to the zone, for example example.com.dbl.spamhaus.org.

If the IP address or domain is not listed, the query returns NXDOMAIN. If it is listed, the query returns one or more addresses in 127.0.0.0/8, and the specific return code identifies which dataset listed it and why. A single ZEN query can return several answers in one response packet, one for each dataset the IP appears in. This is why querying ZEN is equivalent to querying SBL, CSS, XBL and PBL separately, and cheaper.

Receivers use the answer at different stages:

The Spamhaus zones

Return codes

A query for a listed item returns one or more of these codes:

Any answer in 127.255.255.0/24 is an error signal, not a listing. Treat it as "do not block."

Usage terms

Use of the public Spamhaus DNSBL mirrors is free for low-volume, non-commercial users under the DNSBL Fair Use Policy. Commercial and high-volume users must use the subscription Data Query Service (DQS). ZEN covers IP addresses only. It provides no protection against malicious domains, which is what DBL and ZRD are for.

Why senders get listed

For a legitimate sender, as opposed to a compromised host, listings almost always trace back to problems with data, not with content:

• Spamtrap hits: the strongest signal of poor address acquisition or list hygiene (see the spamtrap taxonomy below).
• High complaint volumes at receivers and through feedback loops.
• Sending to purchased, rented, harvested, appended or co-registration lists. Spamhaus's position is aligned with that of the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG): "The practice of selling, buying or sending to lists of purchased email addresses – whether B2B, B2C or other categories, is in direct violation of M3AAWG core values." Consent is not transferable, so a purchased list can never carry consent.
• High unknown-user rates (hard bounces): the signature of a stale or fabricated list.
• Bursty, erratic volume that looks like an infected host.
• Compromised infrastructure: a hacked form, an open relay, stolen SMTP credentials (leading to XBL, CSS or AuthBL listings).
• Sending directly to MX servers from dynamic or residential IP space (leading to a PBL listing, which is not an accusation of spamming, only a policy statement about that IP range).
• Brand-new domains that send immediately after registration (listed in ZRD for the first 24 hours, which is a reason to register domains well before you first use them).

Delisting

All checking and delisting goes through the IP & Domain Reputation Checker at check.spamhaus.org. It is free, checking needs no account, and the tool automatically detects and evaluates your client IP when the page loads. It shows which dataset lists you and why, and walks you through troubleshooting and removal.

Details for each list:

• PBL: self-service removal for end users who legitimately run a mail server on the IP. Alternatively, route mail through your provider's smarthost. Ranges designated by the ISP (127.0.0.10) are policy statements by the network owner.
• XBL: self-service, after you remediate the compromised device or malware. A new listing follows quickly if the infection persists.
• CSS (127.0.0.3): automated listings that largely resolve themselves. Before you request removal, you must meet the sending best practices of RFC 5321 and RFC 5322 (valid rDNS, matching HELO, and so on). The checker includes a dedicated troubleshooting step for CSS.
• SBL (127.0.0.2): investigated manually. Removal requires convincing a Spamhaus researcher that the issue is resolved. Investigations frequently demand proof of consent (see data collection below), and ISPs and reputation providers may also require you to ask your whole list for permission again.
• DBL: listings expire automatically once the domain stops meeting the listing criteria. Manual removal goes through the checker ("using the form does not guarantee removal"). Approved removals propagate within minutes, or within up to 24 hours for some mirrors.

Delisting is always free. Spamhaus: "Any offer from anyone to remove any Spamhaus listing for a fee is a scam."

Blocks at receivers that reference Spamhaus (for example 554 The IP address of your mail server (…) was found in the Spamhaus blocklist. See https://check.spamhaus.org/) clear on the receiver's own schedule after the listing is removed, typically 24–72 hours after the issue that triggered them stops.

Spamhaus's deliverability guidance (Deliverability 101)

Spamhaus's "Deliverability 101" eBook is written from the reputation provider's side of the fence. Its core claim matches the foundations of email deliverability: there is no shortcut, so consistently send correctly authenticated, carefully targeted emails to an engaged audience. The sections below cover what it adds.

What feeds reputation (in Spamhaus's model)

Reputation is made up of an unknown number of variables that ISPs and reputation providers do not reveal. The known components are:

There is a key asymmetry, by design and with no override: it is much easier to drive reputation down than to repair it. IP reputation has also become less central than domain and content reputation. With the 340 undecillion addresses of IPv6, criminals burn IP addresses freely, so filters rely on domains. Inbox placement is recalculated exceptionally quickly in response to how end users react, and treatment can change from one moment to the next. Allowlisting (formerly "whitelisting") by ISPs no longer exists.

Looking legitimate: setup checklist

Intentions matter far less than behavior. Spam filters cannot tell a well-meaning sender from a spammer if the behavioral basics are missing:

• Authenticate everything, with SPF and DKIM at a minimum. Keep the SPF record as narrow as possible, because designating the whole internet as a permitted sender invites abuse. See DMARC for alignment rules.
• Domain strategy for the customers of an email service provider (ESP), from best to worst: (1) delegate a subdomain of the brand's primary domain, for example email.customerbrand.com; (2) customerbrand.espdomain.com; (3) as a last resort, a cousin domain such as customerbrand-email.com. If a cousin domain cannot be avoided, it must clearly relate to the brand, because phishing has made users wary of look-alike domains.
• Do not use anonymized WHOIS records on sending domains. Legitimate businesses have no reason to hide their identity, and registrars that switched to privacy by default after GDPR will usually unmask a record on request.
• Limit the number of distinct sending domains, because the more unique domains send the same mail, the more flags it raises. Use the primary business domain or its subdomains.
• Every domain that sends email should have working abuse@ and postmaster@ addresses and a working website. Link and tracking domains should redirect to the primary business site.
• Where possible, use contiguous IP addresses on the same network, and do not use more IP addresses than you need. Hundreds of IP addresses scattered across networks is the definition of snowshoeing (see Basic IP Allocation).
• ESPs should publish an acceptable use policy (AUP) and terms of service (ToS) that are easy to find and enforced, and should watch SMTP logs for unexpected bounces, temporary failures (tempfails) and anomalies in mail streams.
• Reputation is established during warm-up, so plan it. Choose highly engaged recipients for the first mailings, and grow volume based on the results of each previous send (see IP Warm-Up).

Address acquisition and consent records

For every contact, record the following, and keep the record up to date:

• The date and time of signup, in UTC
• The channel through which the address was obtained
• The IP address that submitted it

If an IP or domain is blocklisted and manual intervention is needed, ISPs and reputation providers often demand this proof of consent. Without it, resolution takes longer or fails. The records also protect you against complaints under GDPR and similar laws.

Rules for forms: opt-in checkboxes must be selected voluntarily (pre-checked boxes are dishonest, and illegal in some countries). Protect forms with CAPTCHA or reCAPTCHA. Since roughly August 2016, bot abuse of unsecured signup forms has been escalating. It poisons databases (including with malicious spamtrap submissions) and amounts to a denial-of-service (DoS) attack.

Acquisition methods, ranked:

Frequency, engagement, and sunset policy

Set the expected frequency in the confirmation or welcome message, and keep to it. Unexpected or erratic mail drives spam reports. Spamhaus gives this example of a sunset ladder:

1. The recipient has not opened in more than 1 week: move them from weekly to monthly mail.
2. They have not opened in more than 1 month: send a "do you wish to continue your subscription?" message with a confirmation link.
3. No response: add them to the suppression list and stop.

Review engagement continuously, and segment out recipients who do not engage. The usual starting cutoff is one year of inactivity, tightened to six months and then three, depending on results. Sending in bulk to addresses that never consented is spam, and so is continually sending to addresses that have never been successfully delivered.

The idea that ISPs and reputation vendors "tighten the rules" in the holiday season is a myth: nothing changes on the receiver side. Senders who reach deep into old or unengaged segments (or buy lists) for holiday revenue cause their own decline in reputation, with tempfails, deferrals, blocks and sometimes Spamhaus listings.

Bounce handling

Hard bounce: a permanent failure (5xx) that is not retried. If you get one, never send to that contact again: delete or suppress it. Codes that senders see frequently:

Most hard bounces in marketing are the direct result of poor data hygiene. Note that non-existent domains can later become spamtraps.

Soft bounce: a temporary failure (4xx) that is retried. The sending system retries until the message is accepted or times out. The timeout is set on the sending side and varies by network:

Some ISPs respond to a dip in reputation with tempfails ("421 4.7.0 [TS01] Messages from x.x.x.x temporarily deferred due to user complaints"). Mail is deferred until either the flow stops or the reputation recovers. Do not automatically remove addresses hit by a tempfail from the list. Fix the problem with list quality instead.

ISP hard block: a policy rejection of the whole stream, usually 554, often with a URL to consult (for example, a Spamhaus reference). The causes are blocks on URLs or body content, missing authentication, a poor IP or domain reputation, or presence on a blocklist the receiver uses. Blocks typically clear after an arbitrary 24–72 hours once the trigger stops. Otherwise, resolve the root cause first, then open a ticket with the blocking network. Some ISPs, notably Gmail, have no remediation channel at all. Receivers generally escalate in this order: placement in the spam folder, then tempfails and throttling, then bounces, then hard blocks.

Complaints and feedback loops

Some causes of complaints are within your control: no real signup, expectations about frequency or content that were never set, too much mail or a sudden change in frequency, purchased lists, irrelevant content, and mailing after an unsubscribe. Remove an address immediately when it unsubscribes, whatever grace period the applicable law allows. Other causes are harder to control: recipients who simply do not remember signing up (mail them promptly after signup, because a first email weeks later is forgotten), typos in addresses collected at the point of sale, and frustrated users who report their whole inbox as spam.

Reduce complaints by keeping the promise made at opt-in, offering a preference center with frequency options, never pre-checking boxes, never buying lists, and making unsubscribing trivial. Never require a login to unsubscribe, which is illegal in some places, and put the link where it is found faster than the spam button, for example at the top.

The monitoring data sources are Outlook and Hotmail SNDS (mail volume, deferrals, complaint rates and trap hits per IP), Google Postmaster Tools (complaint volumes and domain reputation), and every available feedback loop (FBL). Through an FBL, ISPs report user spam complaints back to the originating network in the Abuse Reporting Format (ARF), with personally identifiable information (PII) redacted. Process reports promptly and suppress complainants immediately.

Spamtrap taxonomy

Spamtraps prove a problem in data collection or hygiene, so fix the process, not the trap. Trap owners never reveal their traps. Traps are part of the secret of filtering, and bad actors who identify traps just suppress them without fixing anything. The types are:

Legal context (consult counsel; there are email and data-protection laws in at least 77 countries)

• CAN-SPAM (US): federal. The Federal Trade Commission (FTC) has successfully sued violators.
• CASL (Canada): applies if mail goes to a Canadian domain or a Canadian user, or passes through Canada.
• GDPR (EU, in force 2018-05-25): covers residents of the EU and the EEA, and transfers of data out of them. Fines are severe, and consent records materially reduce exposure.
• CCPA (California, effective 2020-01-01): rights to know, to delete, to opt out of sale, and to non-discrimination. People under 16 need to give opt-in consent, and those under 13 need parental consent.