The first reaction to a Spamhaus listing is usually to find the delisting form. That is almost always the wrong first move, because the return code already tells you which of several unrelated problems you have, and three of them cannot be fixed by delisting at all.

The Code Is the Diagnosis

A DNSBL answers with an address in 127.0.0.0/8, and the last octet identifies which dataset matched. Querying the combined zone gives you one lookup and a code that says which list you are on:

$ dig +short 2.0.113.203.zen.spamhaus.org A
127.0.0.4

Note the reversed octets. The address 203.0.113.2 becomes 2.0.113.203 in the query. The codes map like this:

127.0.0.2    SBL       manually researched spam source
127.0.0.3    CSS       automatically detected low-reputation sender
127.0.0.4    XBL       compromised or exploited machine
127.0.0.9    DROP      resource controlled by bad actors
127.0.0.10   PBL       dynamic space, declared by the ISP
127.0.0.11   PBL       dynamic space, inferred by Spamhaus
127.0.0.20   AuthBL    credential bruteforcing or hijacking
127.0.0.30   BCL       malware command and control

An empty answer means not listed. Always fetch the TXT record too, since it carries the reference URL for that specific listing.

What Each One Means for You

PBL, 127.0.0.10 or 127.0.0.11, is not a reputation problem and it is the most common cause of confusion. It says the address is in a range that should not be running a mail server, either because the ISP declared it dynamic or because Spamhaus inferred it. You have done nothing wrong. If you are sending from a residential or default cloud IP, the fix is to send through a proper relay or get static space with a matching declaration from the provider. Delisting an address whose range is still marked dynamic accomplishes nothing durable.

XBL, 127.0.0.4, means the address is emitting traffic characteristic of a compromised machine. Treat it as an incident. Something is infected, or something is being proxied through, or you have an open relay or a web form somebody is abusing. Delist after you find it and the listing returns within hours, which at least confirms the diagnosis.

CSS, 127.0.0.3, is automated and driven by sending behavior: poor list hygiene, high bounce rates, spam-trap hits, sudden volume changes from a cold address. This is the one that most often reflects marketing practice rather than a technical fault, and the technical team frequently cannot fix it alone.

SBL, 127.0.0.2, is manually researched by a human at Spamhaus. Something specific and documented happened, the TXT record will point to the evidence, and there is no automated path out. Read the reference before contacting anyone.

DROP and BCL are severe. DROP marks space believed to be under criminal control, and BCL marks malware command-and-control infrastructure. If either appears against space you own, the conversation is with your provider and probably with an incident responder.

Delisting Without Fixing the Cause

Every automated list re-lists. That is the point of automation. Requesting removal while the underlying condition persists buys hours, and it also trains you to treat the listing as the problem instead of the symptom.

The order that works is to identify the code, find and fix the cause, verify the cause is actually gone, and then request removal. For CSS in particular, verification means watching your own outbound metrics for long enough to know the behavior changed, since a quiet weekend proves nothing.

Check the Basics While You Are There

Listings frequently arrive alongside configuration problems that make delivery worse independently. Reverse DNS that does not exist or does not match the HELO name, SPF that does not cover the sending host, DMARC set to a policy nobody tested. None of those cause a Spamhaus listing directly, and all of them compound the damage while you are listed.

$ dig +short -x 203.0.113.2
mail.example.com.
$ dig +short mail.example.com A
203.0.113.2

Forward and reverse should agree. The email health check on mrdns.com runs that alongside SPF, DKIM, and DMARC in one pass, and the blacklist check covers the wider set of lists in case this is not the only one you are on.

One operational note if you are querying at any volume: the free DNS interface is intended for individual mail servers checking their own inbound traffic. Anything programmatic or repeated belongs on Spamhaus’s data query service, and running bulk lookups against the public zone will get you blocked, which then looks exactly like a clean result.