Your campaign goes out, and within minutes your bounce log fills with something like this:
550 5.7.1 Service unavailable; Client host [203.0.113.45] blocked using zen.spamhaus.org; https://check.spamhaus.org/query/ip/203.0.113.45
Spamhaus data sits in front of a large share of the world’s mailboxes, so a single listing can take your delivery to near zero across many receivers at once. Microsoft enforces Spamhaus listings as OU-001, for instance. It is also the blocklist senders handle worst — mostly because they never work out which Spamhaus list they are on, and request removal from the wrong one.
Table of Contents
What Spamhaus Is and Why It Blocked You
Spamhaus is not one list. It publishes several separate datasets, and the one that matters for a blocked sending IP is usually ZEN — a combined zone that bundles the three IP-based blocklists (SBL — which includes CSS — XBL, and PBL) into a single query. When a receiving mail server says you are “blocked using zen.spamhaus.org,” it is telling you that you are on at least one of those, but not which. Spamhaus carries far more delivery weight than lighter lists like Barracuda’s BRBL — see how Spamhaus compares to lower-impact lists.
That distinction is the whole game. SBL is manually curated and human-reviewed. CSS is automated reputation detection; in our experience it is the dataset most legitimate ESP senders hit, though Spamhaus publishes no breakdown confirming that. CSS is not a standalone zone — it is published inside the SBL and ZEN zones, so a CSS listing is always cited as SBL or ZEN. XBL means a compromised host. PBL is not a spam list at all — it is a policy statement that a range should not send direct-to-MX. DBL sits outside ZEN entirely and lists domains, not IPs. Different triggers, different owners, different removal paths — the reference table below maps all of them.
One thing worth stating plainly: Spamhaus never charges to remove a listing. Any service offering paid removal is a scam.
How to Confirm This Is Your Problem — and Which Zone
A 550 5.7.1 with a named blocklist in the SMTP response is the confirmation. Start with your bounce logs and grep for:
zen.spamhaus.org— you are on one of the IP zonessbl.spamhaus.org/xbl.spamhaus.org/pbl.spamhaus.org— the receiver queried a single zone and told you exactly which. There is nocss.spamhaus.org: CSS is published inside the SBL and ZEN zones, never as its own zone, so a CSS listing is cited as SBL or ZEN.dbl.spamhaus.org— a domain listing, not an IP onecheck.spamhaus.orgin the bounce text — Spamhaus is the source, regardless of zone
If the bounce only says “zen,” do the lookup yourself. Reverse the octets of your sending IP and query the zone. For 203.0.113.45:
dig +short 45.113.0.203.zen.spamhaus.org
The answer comes back as one or more 127.0.0.x codes, one per dataset you are listed on:
Read the return code carefully before you act on it. Public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS) return 127.255.255.254 for every query — an error code meaning “open resolver”, not a listing. Treat any answer in 127.255.255.x as a failed query, not a result. Naive tooling reads that positive 127.x answer as LISTED and will tell you every IP you own is blocked. Use a resolver that queries Spamhaus directly, or the web checker at check.spamhaus.org, which returns the zone and the removal link together.
One caveat on the resolver route: Spamhaus states that the free public query service “still exists but is being deprecated” in favour of its free Data Query Service, and self-hosted resolvers querying above fair-use volume are cut off. If you check listings regularly, register for a free DQS key at spamhaus.org and query your DQS zones instead of the public ones.
The Zone Reference Table
This is the table to bookmark. Find your zone, and you know who fixes it and where.
One behaviour worth knowing: Spamhaus lists at the hostname level for abused-legitimate cases in the DBL rather than always listing the entire registered domain. A compromised subdomain no longer automatically takes your primary sending domain with it.
The 4 Most Common Reasons Senders Get Listed
1. Spam traps (the dominant trigger for SBL and CSS)
Spamhaus operates a very large trap network, and in our experience trap hits are the most common reason a legitimate sender ends up on CSS or SBL — Spamhaus does not publish a breakdown of listing causes, so treat that as a practitioner observation rather than a published statistic. Two kinds matter. Pristine traps are addresses that were never valid and never opted in anywhere — hitting one means your data came from scraping or a purchase, and it is treated as strong evidence, enough to support a manual SBL listing. Recycled traps are real addresses that were abandoned, hard-bounced for months, then reactivated by the provider as traps. Recycled traps are what catch honest senders: the address was legitimately collected years ago and simply never removed.
2. No sunset policy
If you mail contacts who have not opened or clicked in a year, you are mailing addresses that have had ample time to turn into recycled traps. This is the mechanism behind most surprise CSS listings at otherwise clean senders.
3. Snowshoe-shaped sending patterns
Thin volume spread across many IPs, rotating subdomains, fresh domains with sparse WHOIS, and inconsistent identification across the fleet. CSS is built specifically to detect this. Well-meaning senders trip it by over-fragmenting their infrastructure.
4. A compromised host or misconfigured relay
An open relay, a compromised CMS sending through your MTA, a leaked SMTP credential, or a form without rate limiting. This usually lands you on XBL rather than CSS — and the listing will keep returning until the actual hole is closed.
How to Fix It: Step by Step
The order below matters more than any individual step. Most senders start at the last step, and it costs them.
Identify the zone → stop the traffic → fix the root cause → verify → request removal.
Why requesting removal first backfires
CSS and XBL both re-list immediately if the triggering behavior is still detected, so delisting mid-campaign buys you hours. Spamhaus is unusually strict about that pattern: self-service removal is explicitly limited — Spamhaus describes “fast, no-questions-asked removals – within limits” — and the reasonable inference is that repeatedly delisting the same IP without fixing the cause exhausts those limits and leaves you without self-service. You have then converted a three-day automatic expiry into a manual case a human must review. For SBL it is simpler still — a request submitted while the spam is still flowing shows you have not diagnosed anything, and it costs you credibility on every future request.
Step 1: Identify the exact zone
Run the ZEN lookup or use check.spamhaus.org. Do not proceed until you know whether this is SBL, CSS, XBL, PBL, or DBL. If you are on more than one, our recommended triage order is SBL first, then XBL and CSS, then PBL. Spamhaus does not document an official ordering — this is our practitioner advice, based on which listing costs you the most while it stands.
Step 2: Stop the triggering traffic
Pause sending from the listed IP entirely. Not “reduce” — stop. CSS listings expire roughly three days after the last detection, so every campaign you push through the block resets that clock. A large share of CSS listings resolve with no request at all if you simply stop sending.
Step 3: Fix the root cause
- CSS or SBL: isolate which campaign and segment triggered it. Suppress every contact with no engagement in 90 days, delete any purchased, appended, or scraped data outright, and verify what remains.
- XBL: treat it as a security incident. Audit for open relay, rotate all SMTP credentials, patch the application layer, and check outbound logs for mail you did not send.
- PBL: confirm the IP is static with matching forward and reverse DNS and a real outbound mail server behind it. If it is genuinely dynamic broadband space, the fix is not delisting — it is relaying through a smarthost or an ESP.
- DBL: remove the offending content or compromised subdomain before touching the removal form.
Step 4: Verify before you request
Re-check the IP at check.spamhaus.org — sometimes the listing has already expired and you need to do nothing. Confirm sending is still paused and no automation is scheduled to resume.
Step 5: Submit the removal request, then re-warm
Everything runs through check.spamhaus.org. Look up the IP or domain, open the listing details, and follow the removal link for that zone. There is no separate sender portal, no email address to write to, and no paid fast-track. Once you are clear, do not resume at full volume: start at 10–25% of normal, mail only contacts who engaged in the last 30 days, and increase gradually. A relisting days after a delisting is much harder to resolve than the original listing was.
Paste-Ready Removal Request Template
When the removal form gives you a free-text field, this is the shape that gets processed. Specific, verifiable, no excuses, no volume of adjectives. Replace the bracketed values.
IP: [203.0.113.45] | Listing: [CSS / SBL ref SBL123456] | Organization: [Company], [website]
What we send: Opt-in [marketing / transactional] email for [Company]. This IP sends only for our own [domain.com] mail, at roughly [X] messages per day.
What caused the listing: On [date] we sent a campaign to a segment of [N] contacts that had not engaged since [date]. That segment included addresses collected in [year] that we had never sunset, and we believe it contained recycled spam traps.
What we have done: (1) Stopped all sending from this IP on [date/time UTC]. (2) Permanently suppressed [N] contacts with no opens or clicks in 90 days. (3) Deleted [N] contacts from [source] entirely. (4) Ran the remaining [N] addresses through verification and removed [N] invalid. (5) Implemented an automatic 90-day sunset rule so this segment cannot be rebuilt.
What we will do next: Resume at [X]% of prior volume to 30-day-engaged recipients only, ramping over [N] weeks.
Technical contact: [name], [role], [email at your sending domain].
Two rules for using it. Use a contact address at your own sending domain, not a free mailbox. And do not claim a fix you have not actually made — Spamhaus can see whether the traffic pattern changed, and a request contradicted by the data is worse than no request.
How to Prevent Spamhaus Listings
Sunset aggressively and bounce strictly
A 90-day engagement window for most senders, and no longer than 180 days for anyone. Suppress hard bounces permanently and immediately — a hard-bouncing address you keep mailing is a recycled trap in waiting. The whole recycled-trap problem lives in the gap between “stopped engaging” and “still on the list.”
Use confirmed opt-in on risky acquisition sources, and never buy data
Paid lead-gen, co-registration, offline collection, and unvalidated form fills are where pristine traps enter. Confirmed opt-in eliminates them at the door. Purchased, rented, and appended data has no clean version — not for a pilot, not for one campaign.
Monitor the zones on a schedule
Check your sending IPs and domains weekly, not after the bounces start. CSS listings expire in about three days, so a weekly check can miss one entirely while your delivery quietly suffers.
Consolidate rather than fragment infrastructure
Concentrated, consistently identified sending looks legitimate. Volume thinly spread across many IPs and rotating subdomains looks like snowshoe, whatever your intent.
Shared IP vs. Dedicated IP: Who Fixes What
On a shared IP pool, the listing is your provider’s to resolve — they own the IP and only they can act on it. Your job is to identify and stop your contribution, because your provider will isolate the sender that caused it. A CSS listing on a shared pool usually means one tenant mailed a stale list.
On a dedicated IP, everything above is yours: you own the reputation, submit the removal, and set the re-warm pace.
PBL is the exception to both — it is almost always the ISP’s record about their own address space. If you are on PBL as a legitimate sender, either claim the single static IP through the checker or stop sending direct-to-MX.
How Mailercloud Handles Spamhaus Listings
Mailercloud delivers over a billion emails a month, so Spamhaus zone monitoring is continuous rather than reactive. Our deliverability team watches trap feedback and reputation signals across all shared pools, isolates a sender before a pattern becomes a listing, and owns the full stop-fix-verify-delist-rewarm cycle when one does occur. Customers on dedicated IPs get the same diagnosis and the same re-warm plan, applied to infrastructure they control.
If you are looking at a “blocked using zen.spamhaus.org” bounce right now, talk to our deliverability team — or start free with Mailercloud.
FAQ: Spamhaus Delisting
How long does a Spamhaus CSS listing last?
CSS listings normally expire about three days after the last detection, and in cases of chronic abuse they last longer. If you stop the triggering traffic and change nothing else, many CSS listings clear on their own without any request.
Can I remove myself from the SBL?
Usually not directly. SBL removals are meant to come from the ISP or network operator responsible for the IP, and they are human-reviewed rather than automatic. If you are on a shared pool, this is your provider’s request to make. If you control the network yourself, work through the listing detail page at check.spamhaus.org.
What happens if I keep requesting delisting?
Self-service removals are limited by design. Repeatedly delisting the same IP without correcting the underlying problem gets your self-service access revoked, which turns a fast automatic expiry into a slow manual case. Fix first, request once.
Why does my IP get relisted immediately after removal?
Because the triggering behavior is still being detected. CSS and XBL both re-list on detection, so a delisting that happens while your campaign is still running buys you hours at most. Stop the sending completely before you request anything.
I am listed on more than one zone. Which do I fix first?
Spamhaus does not publish a prescribed order, so this is our own triage advice: SBL, then XBL and CSS, then PBL. PBL goes last, because it is a policy statement about the address space rather than a reputation problem, and clearing it while you are still emitting low-reputation mail achieves nothing. And note that removal is free in every case — any third party offering paid removal is running a scam.
What does “blocked using zen.spamhaus.org” mean?
Your sending IP is on at least one of Spamhaus’s IP blocklists — but the ZEN response alone doesn’t say which. ZEN bundles SBL, CSS, XBL, and PBL into one query, so the fix is to look up the IP at check.spamhaus.org (or dig the zone) and read the 127.0.0.x code: .2 is SBL, .3 is CSS, .4 is XBL, .10/.11 is PBL. Each has a different owner and removal path, so identifying the zone is the whole first step.
Amar CP is the Co-Founder and Sales Director at Mailercloud, where he leads partnerships, alliances, and customer growth. With over a decade of experience in application development, database architecture, and scaling web systems, Amar brings a rare blend of engineering depth and go-to-market expertise to email marketing. He writes about email deliverability, marketing automation, and helping small businesses grow smarter with data-driven campaigns.
