How to delist from Spamhaus: step-by-step (SBL, XBL, PBL)

Spamhaus runs the most influential blocklist operation on the public internet. When their data feed flags your IP or domain, Gmail still tends to deliver, but the long tail of corporate gateways, university mail systems, and cPanel-style hosts will reject outright with a 5.7.1 Service unavailable and a Spamhaus URL in the bounce. Fixing this in 24–72 hours is achievable. Fixing it permanently is the harder part.

The three Spamhaus lists you might be on

Spamhaus operates several feeds. The three you care about for outbound mail are SBL, XBL, and PBL. The lookup tool tells you which one you're on, and the answer dictates the entire delisting workflow. Treating an XBL listing as if it were SBL wastes a day — and vice versa.

• SBL (Spamhaus Block List). Manually curated. An investigator added your IP because of observed spam, hijacked space, or hosting a known spammer. Removal requires evidence and a written explanation.
• XBL (Exploits Block List). Automatic — composed of CBL (Composite Blocking List) data plus other exploit feeds. Your IP got listed because a machine on it sent malware, ran an open proxy, or generated bot-like SMTP traffic.
• PBL (Policy Block List). Not a reputation listing. Spamhaus marks IP ranges that should not be sending mail directly to MX records — typically residential IPs and dynamically allocated ranges. Listed by ISP policy, not behaviour.

There's also DBL (Domain Block List) for domains themselves and ROKSO for the "Register of Known Spam Operations" — a list of repeat-offender entities, not single-incident listings. ROKSO removal is a different conversation entirely.

Step 1: Use the Spamhaus lookup tool

Open https://check.spamhaus.org/ and enter the IP address (or domain) you want to query. The result page lists every Spamhaus feed the IP appears on, with a direct link to the entry, a reason code, and the evidence Spamhaus has on file if applicable.

Always test the exact sending IP from a recent bounce header, not your guess. Many ESPs send from a pool, and listings often affect only one IP in the pool. The bounce will read something like blocked using zen.spamhaus.org followed by the offending IP — use that one.

If you see multiple listings (SBL plus XBL, for example), expect to file separate removal requests. Each list has its own workflow, and removing one does not auto-remove the others.

Step 2: Fix the underlying cause first

This is the step nearly every first-time submitter skips, and it's the reason most resubmissions get ignored. Spamhaus investigators look at the listing context first. If you submit a removal request while your server is still emitting the same traffic that got you listed, the request is closed without action and you've burned credibility.

Common root causes by list type:

1. Compromised mailbox. A user's password leaked and a spammer is sending through your authenticated SMTP. Force a password rotation, enable MFA, and audit recent SMTP-AUTH logs for unusual IPs.
2. Open relay. Postfix or Exim accepts mail from anywhere to anywhere. Lock down mynetworks, require authentication on submission, test with mxtoolbox.com/diagnostic.aspx.
3. Web form / contact form abuse. A WordPress contact form is being used as a relay through your sending IP. Add captcha, rate-limit, validate Reply-To headers.
4. Malware in your network. A workstation on the same NAT IP is part of a botnet. CBL data flagged it. Isolate, scan, patch.
5. List quality collapse. A campaign hit a spam-trap run. Pause sending, audit the most recent imports, drop the guilty list segment.

Step 3a: SBL removal procedure

Open the SBL ticket linked from the lookup result. The page shows the listing reason in plain text — sometimes a link to captured spam, sometimes a description like "snowshoe spammer hosting". There is a green "Removal Request" link near the top.

The form asks for: your name, your role at the network operator, the IP being delisted, and a free-text explanation. The explanation is the entire substance of the request. Investigators read every word. Write it like an incident postmortem:

• What happened (root cause in one sentence).
• When you discovered it.
• What you did to stop it (specific actions, with timestamps).
• What you put in place to prevent recurrence.

Response time for SBL is typically 24–72 hours. Spamhaus investigators do this work manually and they have a queue. Polite, evidence-rich requests get processed faster than adversarial ones.

Step 3b: XBL removal procedure

XBL listings are automatic. The lookup result links to the CBL page (cbl.abuseat.org) which shows the specific behaviour the sensor observed — for example "sending mail to spamtrap on port 25 from a residential IP". The page also shows a self-service removal button.

The catch: if the bot-like traffic is still happening, the IP re-lists within minutes of removal. The CBL self-service button only succeeds if you've actually fixed the issue. Run a sniffer, audit your egress traffic, and only press the button when you're sure the source is clean.

XBL removal is instant when it succeeds. No manual review, no explanation form. But you only get a small number of self- service removals per IP per year before the option disappears and the IP can only be delisted by your ISP.

Step 3c: PBL removal procedure

PBL is fundamentally different. The IP is on the list because Spamhaus believes it should not be talking to remote MX servers at all — typically a home connection, a mobile carrier, or a dynamically assigned cloud IP without proper authorisation.

Two paths to removal:

1. ISP removal. Your ISP contacts Spamhaus and updates the policy on their range. This is the right answer if you control the IP space (a small business with static IPs from a regional ISP). Most large cloud providers — AWS EC2 EIP, GCP, Azure — already maintain their own PBL relationships and will not delist on user request.
2. End-user self-removal. Spamhaus offers a self-removal form for legitimate users on PBL-listed ranges. Confirms contact details, requires you to acknowledge you're running a real mail server. Removal is per-IP and reversible if abuse is detected.

Response times and what to expect

Realistic expectations matter here, because every hour you spend hitting refresh on the lookup page is an hour you could spend fixing the upstream issue.

• SBL: 24 hours typical, 72 hours worst case for straightforward cases. Complex listings (ROKSO-adjacent, repeat offenders) can take longer.
• XBL: Instant on successful self-removal, but the IP must remain clean. Re-listings happen within minutes if the underlying sensor still sees bad traffic.
• PBL: Self-removal is near-instant. ISP removal depends entirely on the ISP's response time, which ranges from hours to weeks.

Preventive checks that actually work

After you've been listed once, build the monitoring you wished you had. The minimum viable setup is:

• Daily DNS query against zen.spamhaus.org for every IP you send from. Alert on any non-NXDOMAIN response.
• Weekly placement test from a tool like inbox-check that flags Spamhaus status alongside actual inbox results.
• Bounce-log monitoring that pattern-matches Spamhaus URLs in rejection text — when a bounce mentions Spamhaus, alert loud and immediately.
• Monthly review of SMTP-AUTH logs for credential abuse, plus enforced password rotation and MFA for every sending account.

Frequently asked questions