If you send marketing or cold email at any volume and you get a Spamhaus listing, it is almost always the CSS. Not the SBL, not the XBL — the CSS. It is the component that quietly catches ordinary senders who did something ordinary wrong, like mailing a list that had gone stale. Understanding what the CSS is, and just as importantly how it behaves, changes your entire response — because the instinct most people have when they see a CSS listing is exactly backwards.
What the CSS actually is
CSS stands for the Combined Spam Sources list — a Spamhaus blocklist of individual IP addresses that Spamhaus does not want to see sending mail. Per Spamhaus's own description, the CSS "mostly targets static spam emitters that are not covered in the Policy Blocklist (PBL) or Exploits Blocklist (XBL), such as snowshoe spam operations," but it "may also include other senders that display a risk to our users, such as compromised hosts."
Two words in that description do the real work. Snowshoe and compromised.
Snowshoe is the tactic of spreading spam thinly across many IPs and domains — the way a snowshoe spreads weight across snow — so that no single sender looks big enough to trip a volume-based filter. The CSS is specifically built to catch that distribution pattern. The problem for legitimate senders is that some perfectly honest sending looks like snowshoe: an agency rotating sends across many sub-account domains, or a cold-email operation spread across several sending domains to manage volume, produces a footprint the CSS is designed to flag.
Compromised covers hijacked accounts, infected servers, and misconfigured applications that start emitting mail the owner never intended. If a sub-account login or an integration gets popped and starts sending, the CSS can pick that up too.
Crucially, CSS listings are automated. No human reviewer put you there. The list is generated algorithmically from observed sending behaviour, which is why the fix is also mostly about changing behaviour rather than pleading a case.
Why legitimate senders trip it
You do not have to be a spammer to land on the CSS. The behaviours that trigger it overlap heavily with ordinary list-quality mistakes:
- Spam-trap hits. Trap addresses exist only to catch senders using lists they should not be using. Mailing even one fresh trap is a strong signal, and traps accumulate in exactly the kind of old, inherited, or scraped lists that agencies and cold senders tend to mail.
- Recycled and dead addresses. Addresses that used to be real but were abandoned and reactivated as traps, plus high concentrations of hard bounces, read as poor list hygiene.
- Complaint-heavy sending. Mailing an unengaged or non-opt-in audience drives "mark as spam" clicks, and a complaint-heavy pattern is exactly the risk signal the CSS looks for.
- Snowshoe-shaped distribution. Volume spread across many IPs or domains without the consistent, engaged sending that would establish each one's legitimacy.
- Compromise. A sub-account or integration sending mail nobody authorised.
Notice what is not on that list: your email copy, your subject lines, your design. The CSS is a list-and-behaviour filter, not a content filter. If you are on it, the answer is upstream of the message — it is who you mailed and how.
The part everyone gets wrong: it usually clears itself
Here is the behaviour that should change your response. Per Spamhaus, a CSS listing normally expires three days after the last spam is detected. In cases of chronic abuse it can persist longer, but for a one-off listing caused by a bad send, the listing lifts on its own within about 72 hours of the offending sending stopping.
That single fact reorders your priorities:
- Stop the sending first. The listing's expiry clock only starts once the bad behaviour ends. Continuing to send resets it. Pausing the offending campaigns and workflows is the highest-leverage move you can make, and it is more important than any form.
- Fix the actual cause. Suppress the list source that carried the traps, tighten the audience, rotate credentials if it was a compromise. If you do not fix the cause, the listing recurs the moment you resume — and repeated listings are what turn a 3-day auto-expiry into a chronic one.
- Then, optionally, request removal. Spamhaus does offer a self-service removal process, and for a clean, honest submission it can speed things along. But submitting a delisting request while you are still sending, or without having fixed the cause, is worse than useless — it gets rejected, and it signals that you have not understood the problem.
The common failure mode is the reverse of this order: people see the listing, panic, and immediately hammer the removal form while their campaigns keep running. The form does nothing because the sending is still generating the exact signal that listed them. Stop sending, fix the cause, and in most one-off cases you would have cleared even without touching the form.
CSS vs the other Spamhaus lists
Knowing you are on the CSS specifically — rather than another Spamhaus component — tells you how worried to be:
- CSS (Combined Spam Sources) — automated, behaviour-driven, auto-expiring. The overwhelming majority of legitimate-sender listings. Recoverable in days if you stop and fix the cause.
- SBL (Spamhaus Block List) — manual listings of known spam operations and infrastructure. A human put you there; it is rare for ordinary senders and slower to resolve.
- XBL (Exploits Block List) — IPs associated with open proxies, malware, and botnets. You see this when infrastructure is compromised at a low level, not from a marketing send.
- PBL (Policy Block List) — residential and dynamic IP ranges that should not send mail directly. This is a policy list, not a reputation one; the fix is to relay through a proper ESP, not to request delisting.
- ZEN — the combined lookup that queries SBL, CSS, XBL, and PBL in one request. Most blocklist checkers hit ZEN, so when a tool says "Spamhaus," check the underlying component code to know which list you are actually on.
If the checker shows CSS, you are in the most recoverable category there is. Treat it as a signal to fix list hygiene, not as a crisis.
How to check which list you're on
You cannot respond correctly until you know the component. Run the sending IP and the sending domain — separately — through a blocklist checker that surfaces the individual Spamhaus list codes, not just a pass/fail on ZEN.
- IP on CSS, domain clean → the listing is at the sending-infrastructure layer. If you are on shared infrastructure (for example, GoHighLevel's LC – Email pool), this may be a neighbour's behaviour and a platform ticket, not your list. See the GoHighLevel Spamhaus runbook.
- Domain listed → the signal is coming from your own sending, regardless of IP. This is a list-and-behaviour fix on your side.
The free blocklist checker queries the major lists and returns the specific hits so you can tell the two apart in one lookup.
What MailerMonk does at this layer
The agency reputation scorecard checks any domain and IP against Spamhaus ZEN, Barracuda BRBL, SpamCop SCBL, SORBS, and more in a single request, alongside SPF / DKIM / DMARC / MX status — so a CSS hit surfaces with enough context to know whether it is your list or your infrastructure. Because CSS listings move fast in both directions, the value is catching them early: for multi-sender operations the dashboard runs these checks daily, so a listing alerts you inside the auto-expiry window rather than after it has already cost you a week of placement.
A CSS listing is not a verdict on your sending forever. It is a three-day timer that starts when you stop doing the thing that triggered it. The whole game is stopping fast and fixing the cause — the list does the rest.
Frequently asked questions
How long does a Spamhaus CSS listing last?
A CSS listing normally expires about three days after the last spam is detected from the listed IP — the clock starts when the offending sending stops, not when you notice the listing. If you keep sending, you keep resetting it. Chronic or repeated abuse can extend a listing beyond the usual window, which is why fixing the underlying cause matters more than the delisting form.
Should I submit a Spamhaus delisting request for a CSS listing?
Only after you have stopped the offending sending and fixed the cause. Because CSS listings auto-expire once the bad behaviour ends, a one-off listing often clears on its own within about 72 hours. A removal request submitted while you are still sending, or before the root cause is fixed, will typically be rejected. Stop first, fix second, request removal third — if at all.
Why did I get listed on CSS when I'm a legitimate sender?
The CSS is behaviour-driven, and legitimate senders trip it through ordinary list mistakes: mailing a stale or inherited list that contained spam traps, high complaint rates from unengaged audiences, or sending patterns spread across many domains that resemble snowshoe distribution. It is not a judgement on your content — it is a signal about who you mailed and how. Fix the list and the sending pattern and the listing clears.
What's the difference between Spamhaus CSS and SBL?
CSS is automated and behaviour-based — it catches snowshoe-style and low-reputation bulk sending, and it auto-expires roughly three days after the sending stops. SBL is a manually curated list of known spam operations and infrastructure; a human reviewer places SBL listings, they are rare for ordinary marketing senders, and they resolve more slowly. Almost every legitimate-sender Spamhaus listing is CSS, not SBL.