Spamhaus blacklist removal: a practical guide to delisting

Start with the sending IP or domain

Open Spamhaus’s IP and Domain Reputation Checker and enter the IP address that actually connected to the recipient’s mail server. Take it from your sending platform or delivery logs: your website’s hosting IP is often not your mail-sending IP. If a rejection message names a domain, check that domain as well. ^[1]

A block at one mailbox provider does not prove a Spamhaus listing. Compare the receiver’s full SMTP response with the Checker result, and record the exact list name before changing anything. If the Checker shows no listing but blocking continues, Spamhaus says the cause can be a resolver problem or a recent removal that downstream networks have not yet picked up. ^{[1] [10]}

Read the list name, not just ‘listed’

The current IP datasets are the Spamhaus Blocklist (SBL), Combined Spam Sources (CSS), Exploits Blocklist (XBL) and Policy Blocklist (PBL). ZEN combines all four into one query, and one lookup can return a separate answer for each dataset that lists the address. Spamhaus also describes CSS as a subset of the SBL zone, so read the component, not the zone name. ^{[2] [4]}

SBL covers addresses Spamhaus identifies as malicious, such as spam sources, malicious hosting or hijacked IP space. CSS is an automatic dataset of port-25 detections, influenced by unsolicited mail, poor list hygiene and compromised or misconfigured systems. XBL lists addresses with compelling evidence of a compromised or infected device. PBL marks end-user ranges that should not send mail directly to destination servers; Spamhaus says those addresses are not necessarily ‘bad’. ^{[3] [4] [5] [6]}

For domains, the Domain Blocklist (DBL) covers domains showing signs of spam or malicious activity, including hijacked legitimate domains. The Zero Reputation Domain (ZRD) list is a short-lived listing of newly registered or newly observed domains. A ZRD entry says the domain is new, not that you did something wrong. ^{[7] [8]}

A DNS error code is not a listing

Many false alarms come from querying Spamhaus through a public or open DNS resolver. Spamhaus reserves answers in 127.255.255.0/24 for errors that do not mean ‘listed’. 127.255.255.254 means the query came through a public or open resolver, 127.255.255.252 means a typo in the blocklist name, and 127.255.255.255 means excessive query volume. ^[9]

If your own server or a monitoring script reports a Spamhaus hit, check the exact answer code before you panic or contact anyone. Then confirm the result in the Checker. A real ‘not listed’ query returns no record, while a listing returns a Spamhaus 127.* answer outside that error range. ^{[1] [9]}

Choose the removal route for that dataset

SBL: a general sender does not remove this listing directly. Spamhaus says only the responsible network or hosting company handles SBL removals, so contact that provider’s abuse team. The network owner asks for removal once the conditions behind the listing no longer apply. Spamhaus’s 2021 Checker announcement also says an SBL listing must be cleared before other lists. ^{[3] [12]}

CSS and XBL: start at the Checker and follow its instructions. Spamhaus says CSS normally expires three days after the last spam detection, longer in chronic cases, and that self-removals are limited. XBL expires after the malicious behaviour is no longer detected. Asking again while the activity continues does not help. ^{[4] [5]}

DBL and ZRD: most DBL listings expire automatically once associated activity stops. If a domain is eligible for earlier removal, use the Checker form; Spamhaus says using it does not guarantee removal. ZRD is automatically removed after 24 hours, and Spamhaus does not accept removal requests for it. ^{[7] [8]}

PBL: first ask whether this address should be sending directly to other organizations’ mail servers. For a home, office or general end-user address, leave the listing alone and send through an authenticated mail service. For a genuine mail server, follow the Checker’s exclusion steps if the network’s policy allows it. ^{[6] [12]}

Fix the trigger before asking for removal

For CSS or XBL, review every device and service that can send on port 25. Look for compromised mailboxes, leaked SMTP passwords, malware, hacked websites or a relay that accepts mail it should refuse. Disable unauthorized sending, change exposed passwords, patch or clean affected systems and restrict outbound port 25 to approved mail servers, as Spamhaus recommends. ^{[5] [11] [13]}

For a marketing-related listing, trace where the affected addresses came from and stop mailing bought, rented, scraped or harvested lists. Spamhaus calls these the most common source of spam-trap hits. A trap hit points to how the list was collected; do not try to find and delete individual trap addresses. Sky’s earlier post on Spamhaus and cold email covers this in more depth. ^[11]

Check infrastructure before you resume volume. Spamhaus’s Sender Guidelines call for valid reverse DNS (PTR) with a matching forward record and a consistent HELO/EHLO name that resolves to the sending IP; missing or mismatched reverse DNS is one of the most common reasons an IP is considered for listing. Sky’s earlier post on the HELO, PTR and A-record checks has the step-by-step DNS check. ^[11]

Why a listing comes back

Removal changes the listing, not the cause. It does not clean a server, close a relay, revoke a stolen password or repair a list source. Spamhaus says CSS re-lists quickly on re-detection, DBL domains re-list if re-detected, and a hacked site found again after delisting will quickly be listed again. Repeated relisting can also stop further removals until the issue is fixed. ^{[4] [7] [13]}

Moving the same mailing to a fresh IP or domain does not fix compromised sending or unwanted recipients. Keep mailing limited to people who asked for it, keep infrastructure stable and correctly configured, and only then expand volume again. ^[11]

When to bring in a specialist

Get help when a removal is followed by another listing, several IPs or domains are involved, you cannot find which system or account sent the traffic, or one provider keeps blocking you after the listing clears. A security compromise, a migration to a new IP or domain at volume, or unclear SMTP evidence also needs more than a quick lookup.

Before asking your ISP, ESP or a deliverability specialist, collect your monthly sending volume, sending platform or MTA, affected mailbox providers, the date it started and what changed just before. Add the exact bounce or deferral text, Postmaster Tools or SNDS screenshots, full message headers, the sending IPs and the Checker result. That evidence separates a Spamhaus listing from a receiver-specific problem.