How to avoid email blacklists (and what to do if you're listed)

A blocklist lookup is a DNS query, and its answer depends on which resolver asked. Measured on 9 September 2026, the same query for Spamhaus's documented test address returned a real listing through Google Public DNS and Quad9, and returned 127.255.255.254 — Spamhaus's code for "query via public/open resolver" — through Cloudflare. A checker that reads any A record as "listed" and any absence as "clean" will report both of those as answers about your reputation. Neither is. Before you react to a blocklist verdict, find out whether the query was even allowed to run.

What a blocklist lookup actually is, and the command that runs one

A DNSBL is a DNS zone that answers a question by existing. To ask whether the IP 192.0.2.25 is listed on Spamhaus's combined zone, you reverse the octets, append the zone name, and resolve an A record:

dig +short A 25.2.0.192.zen.spamhaus.org

An answer means listed. An empty answer means the zone has nothing on that address. The value returned is not decorative — it identifies which underlying list matched and therefore what the listing means.

Domain blocklists work differently and the difference trips people up. The Spamhaus Domain Blocklist is queried with the domain name itself, not a reversed IP:

dig +short A example.com.dbl.spamhaus.org

Spamhaus is explicit that the DBL "ONLY lists domains. No IP addresses are listed in the DBL", and a query that puts an IP into it returns the error code 127.0.1.255 rather than a verdict.

Two query shapes, two return-code ranges, two different things being accused. Most checkers merge them into one traffic light.

Your checker's answer depends on which resolver it used

This is the finding that should change how you read every blocklist report you have ever been shown.

Spamhaus refuses lookups that arrive through public or open resolvers, because it cannot attribute query volume to a user. Instead of reputation data it returns a sentinel from the 127.255.255.0/24 range. Spamhaus published these in February 2021 and began implementing them in March 2021:

• 127.255.255.252 — typing error in the DNSBL name.
• 127.255.255.254 — query via public/open resolver, or generic unattributable reverse DNS.
• 127.255.255.255 — excessive number of queries.

Spamhaus documents 127.0.0.2 as the test address for its combined zone and test as the test domain for the DBL. Querying both through three public resolvers, on 9 September 2026:

• Google Public DNS, 8.8.8.8 — the zone query returned 127.0.0.2, 127.0.0.10 and 127.0.0.4; the DBL test returned 127.0.1.2. Real answers.
• Quad9, 9.9.9.9 — identical results.
• Cloudflare, 1.1.1.1 — both queries returned 127.255.255.254. No reputation data at all.

Same names, same instant, three resolvers, two completely different classes of answer. A checking tool that treats a returned A record as a listing would report your address as listed on Spamhaus off 127.255.255.254, which is a phantom. One that treats absence as clean would report not listed for an address Spamhaus keeps permanently listed for testing.

The practical rule: before you trust a negative result, prove the query works. Look up the test address through the same resolver your tool uses. If it does not come back listed, your tool cannot tell you anything, and its reassuring green tick is measuring its own network configuration. Spamhaus's own remedy for the refusal is its free Data Query Service, which attributes queries to an account rather than to an anonymous resolver.

Half the zones in a typical checker are dead

Blocklist checkers accumulate zones and almost never remove them. The zones themselves do not last forever.

SORBS — the Spam and Open Relay Blocking System, launched in 2001 and acquired by Proofpoint in 2011 — was decommissioned by Proofpoint on 5 June 2024, and its zones were emptied of data. Queried on 9 September 2026, sorbs.net has no name servers at all: the domain's DNS is simply gone. Every lookup against dnsbl.sorbs.net therefore returns nothing, and every checker still carrying it reports a confident, permanent, meaningless clean.

Testing a zone is alive takes one command, using that zone's own documented test point where it has one, or 2.0.0.127 where it follows the common convention:

dig +short A 2.0.0.127.bl.spamcop.net

An answer means the zone is alive and answering you. Silence means either the zone is dead, your resolver is refused, or the query is being filtered somewhere in between — and you cannot tell which from a checker's summary row. Run it against every zone in whatever report you are about to act on, and delete the ones that no longer answer. A blocklist report is only as honest as its shortest-lived zone.

Read the return code, not the yes or no

The value a zone returns tells you which list matched, and the lists mean very different things. For Spamhaus's combined zone:

• 127.0.0.2 — SBL. A manual Spamhaus listing of a spam source.
• 127.0.0.3 — CSS. Spamhaus's automated snowshoe and low-reputation listing.
• 127.0.0.4 — XBL, carrying CBL data: exploited machines, open proxies, worms and trojans. This is a compromise indicator, not a marketing complaint.
• 127.0.0.9 — DROP data, alongside a 127.0.0.2 listing.
• 127.0.0.10 and 127.0.0.11 — PBL, maintained by the ISP and by Spamhaus respectively.

The PBL codes are the ones most misread. The PBL is a policy list: it marks address ranges whose own operator says they should not be sending mail directly to mail exchangers, which is almost all residential and dynamic space. A PBL hit on a home broadband address is the system working correctly and there is nothing to appeal. The fix is to relay through an authenticated server. A PBL hit on an address you believe is dedicated sending infrastructure is a genuine finding, and it means your provider has classified that range as something other than a mail server.

For the DBL, the range is 127.0.1.0/24: 127.0.1.2 spam domain, 127.0.1.4 phishing, 127.0.1.5 malware, 127.0.1.6 botnet controller, and 127.0.1.102 through 127.0.1.106 for abused legitimate domains. That last group is the one a real business is most likely to land in, and it means a domain you own is being used for something you may not know about.

An XBL hit and a DBL spam listing call for entirely different phone calls. One is a security incident; the other is a marketing practices problem. A checker that shows both as a red square has thrown away the only part of the answer that decides what you do next.

A listing is usually not why Gmail put you in spam

This is the most expensive misconception in the subject, and it costs people weeks.

Neither Google nor Microsoft documents using third-party public blocklists as an input to consumer mailbox filtering. Both publish their own reputation systems instead — Google rates your domain and your IP in Postmaster Tools and tells you to keep the user-reported spam rate below 0.30%; Microsoft weighs IP reputation through its own data. Public blocklists are consulted mainly by self-hosted mail servers, small business appliances and filtering gateways.

So the two failure modes look identical from outside and have different fixes:

• Listed on a public blocklist, fine at Gmail. Your mail is being rejected by self-hosted receivers and accepted by the large providers. Symptom: hard rejections mentioning a specific list by name in the bounce text.
• Fine on every blocklist, filtered by Gmail. Your mail is accepted everywhere and read nowhere. Symptom: high acceptance rates and no replies. No blocklist check will ever surface this.

They correlate, because the practices that get you listed also raise your complaint rate. That correlation is why the folklore persists. But clearing a listing does not clear a placement problem, and the levers that actually decide the folder are a different list from the ones that decide a listing.

How senders actually get listed

Three mechanisms, in rough order of how often they apply to a legitimate outbound team.

Spam traps. Addresses that no human uses, so any mail arriving is evidence the list was not built with consent. Amazon SES describes their origins precisely: some are "converted from addresses that were once valid, but have been unused (and bouncing) for an extended period of time"; some are "set up just to be spamtraps"; and some "are addresses that are close to real addresses (for example, introducing a typo into a common domain name)". The first category is why removing hard bounces promptly matters — an address you keep mailing after it starts bouncing is a candidate for recycling into a trap. AWS also declines to publish how many hits trigger action, noting that "even a small number of spamtrap hits can have a very negative effect". What a spam trap is and how lists acquire them covers the acquisition paths.

Complaints. Recipients pressing the spam button, aggregated through feedback loops. This is the mechanism that scales with volume and with irrelevance, and it is the one no technical fix addresses.

Someone else's compromise. An XBL or CBL listing on an IP you share means a machine in that range is infected or acting as an open proxy. If you send through a shared pool, this can happen to you without any action of yours. It is also the fastest to clear once the operator fixes it.

Avoiding all three comes down to a short and unglamorous list: never buy, rent or scrape a list; verify addresses before import; suppress hard bounces immediately and permanently; keep complaint rate low by mailing people the message plausibly applies to; and authenticate so that mail you did not send cannot be attributed to you. The four stages of cleaning a list covers the verification half.

Autocloz's free plan covers 5 users and 10 mailboxes with 1,000 address verifications a day, hard-bounce suppression at workspace scope and SPF, DKIM and DMARC monitoring on every connected domain — start free and verify the list before it ever touches a sending identity.

Delisting, list by list, and the rule that governs all of them

The rule first, because it applies without exception: fix the cause, then request removal. A delisting granted while the behaviour continues buys you hours.

• Spamhaus. Removal requests go through the Spamhaus reputation checker. Spamhaus states that "There is never any charge or fee associated with removing any Spamhaus listing", that an approved removal "will be processed immediately. It should only take a few minutes", and that some users may lag up to 24 hours. Listings also expire on their own once the associated activity ceases. Anyone charging you for a Spamhaus delisting is selling you something Spamhaus gives away.
• SpamCop. Largely self-clearing. SpamCop's documentation states that "without any additional reports, a reported address stays on the SCBL for only 24 hours" — the short window is deliberate, limiting the damage when someone reports legitimate mail by mistake. If you are still listed after a day, reports are still arriving, and the answer is upstream.
• Barracuda. A removal request form, reviewed by their team. Fix first; a request submitted while the traffic continues is refused.
• A provider's own block. Not a blocklist at all. Microsoft has a sender support form for mitigation; Google has no equivalent for individual senders and expects you to correct the underlying practice.

Three things to do before any of the above. Confirm the listing is current by querying the zone directly rather than trusting a cached report. Confirm the listed address is actually yours — a shared pool IP is not, and the delisting request has to come from whoever operates it. And confirm your own authentication is intact, because a domain whose SPF record has quietly crossed the ten-lookup limit fails authentication everywhere while looking perfectly clean on every blocklist; retrieve the TXT record with dig and paste it into the SPF and DMARC record checker, which counts the lookups in the value you give it.

What a blocklist check cannot tell you, and what Autocloz does not do

A blocklist check answers one narrow question: does this zone currently have a record for this identifier. It cannot tell you why, cannot tell you when the behaviour that caused it happened, and cannot tell you whether the receivers you actually care about consult that zone.

It cannot see provider-internal blocks at all. The large mailbox providers do not publish their block decisions in a queryable zone, so a clean sweep across every public list is compatible with being filtered by every mailbox that matters.

It cannot distinguish a policy listing from a reputation listing without reading the return code, and most tools discard that code before showing you anything.

Autocloz queries a short set of zones rather than a long one, because wide zone lists include high-false-positive sources that flag entire networks and produce alarm without signal. It detects the 127.255.255.0/24 refusal sentinels and reports them as query-blocked rather than as listings, which is the specific failure this post opened with. It does not, on its own, tell you that a zone has been decommissioned — the SORBS case above is a reminder that any zone list needs pruning as operators shut lists down, and that applies to ours as much as to anyone's. It caches answers for an hour so a re-check does not hammer a zone that rate-limits. And it is honest about the boundary: a listing check is a diagnostic, not a remedy, and it does not request delisting on your behalf, does not operate its own sending IPs, and cannot tell you what a provider's internal filter concluded. Autocloz monitors authentication and pauses email sending on a mailbox whose failures accumulate, and the comparison against dedicated deliverability tooling is honest about where a monitoring product stops and an infrastructure decision begins.