The customer called us on May 6th. Their main sending IP had stopped delivering to a meaningful percentage of recipients overnight. Initial diagnostics showed Gmail and Microsoft accepting the mail, Yahoo rejecting some, and a long tail of corporate mail servers rejecting outright with specific 5.7.1 errors referencing Spamhaus. The IP was on the CSS (Composite Snowshoe Score) list.
The remediation took nine days from listing detection to confirmed delisting. This post is the operational sequence we used, the dead ends we hit, and what we learned about Spamhaus CSS specifically.
The customer has been anonymized. The IPs are anonymized. The timeline, errors, and remediation steps are real.
What CSS actually is
Spamhaus operates several blocklists. The SBL (Spamhaus Block List) lists IPs that Spamhaus has manually identified as spam sources. The XBL (Exploits Block List) lists IPs that show signs of compromise. The PBL (Policy Block List) lists IPs that should not be sending direct-to-MX mail. The CSS lists IPs identified by automated analysis as likely “snowshoe” senders.
Snowshoe spamming is the technique of distributing email volume across many IPs to avoid the reputation damage of any single IP carrying too much volume. The traditional spam pattern: one IP sends 1M spam messages per day, gets blacklisted quickly. The snowshoe pattern: 100 IPs each send 10K messages per day, the volume per IP stays below any single blocklist threshold but the aggregate is the same 1M messages.
CSS is Spamhaus’s response to snowshoe. It looks at patterns across IP ranges, sending behavior, content fingerprints, and reputation signals to identify IPs that participate in snowshoe operations even when individual IP volume is below traditional blocklist thresholds.
The challenge for legitimate senders: certain operational patterns can trigger CSS even when the operation is not snowshoe spamming. Multi-IP sending pools, careful sending volume management per IP, content variation across sends—all of these are practices both legitimate senders and snowshoe spammers use. CSS distinguishes based on aggregate patterns that are harder to identify from inside the sender’s operation.
Tuesday, May 6: detection and initial diagnosis
The customer’s monitoring alerted them to a delivery rate drop around 8:30 AM UTC. Their primary sending IP for one of their pools (call it IP A) went from typical 96-97% delivery rate to 78% in the span of 90 minutes. The other IPs in the pool were unaffected.
Initial diagnostic checks ran against the standard reputation services. Gmail Postmaster Tools showed Domain Reputation unchanged but the specific IP reputation moved from High to Medium. Microsoft SNDS showed unchanged. Sender Score (Validity) showed no change. Most of the major blocklists (Spamhaus SBL, XBL; SURBL; Composite Block List; UCEPROTECT) showed no listing.
The Spamhaus CSS check showed the listing. The CSS entry was timestamped 4:23 AM UTC that morning. Some receiver-side mail servers query CSS in their composite checks and reject based on the listing; others use it as one factor among many.
The rejection pattern in the sending logs showed the corporate and smaller mail receivers were rejecting more aggressively than the major mailbox providers. Microsoft and Gmail were still accepting most mail. Yahoo accepted some, rejected some. Smaller corporate MX servers rejected outright with 5.7.1 errors referencing CSS specifically.
The customer estimated the impact at around 4-6% of their total daily volume, but concentrated in business recipients (their newsletter is B2B). The business recipient impact was higher than the percentage suggested in raw volume terms because B2B engagement and revenue conversion rates are higher.
Tuesday afternoon: contact with Spamhaus
Spamhaus has a removal request process at lookup.spamhaus.org. The process: identify the listing, fill out the removal request form, provide context about the sending operation, request review.
The form asks for several specific items. The IP address being listed. The contact email of the sender’s abuse/operations team (not a customer email; Spamhaus expects to communicate with the operator). Volume of mail sent from the IP per day. Description of the mail content. Confirmation that the operator has investigated the listing and addressed any underlying issues.
We submitted the removal request that afternoon with the customer’s information. Spamhaus typically responds within 24-48 hours for initial review. We provided context: legitimate B2B newsletter with opt-in subscribers, no recent changes in sending patterns, no recent complaints, authentication complete, content matched to subscriber interests.
The initial response from Spamhaus arrived Wednesday morning, May 7th. The response acknowledged receipt and indicated they would review. No timeline commitment. The response also included a request for additional information: list source documentation, recent complaint rate data, sample of recent mail headers.
Wednesday May 7: information gathering
The Spamhaus follow-up request required information the customer needed to assemble.
List source documentation: the customer’s subscriber list came from multiple sources including signup forms on their website, co-registration through partner sites, and import of attendee lists from B2B events they hosted. The documentation required showing the opt-in mechanism for each source. We produced a documentation package showing signup form screenshots, partner agreement extracts confirming opt-in mechanism, and event attendance opt-in language.
Recent complaint rate data: from the customer’s ESP suppression lists and Gmail Postmaster Tools data, the recent complaint rate was 0.06%. The data covers the last 90 days of sending. The rate is well below any reasonable threshold.
Sample mail headers: we provided headers from the past week showing the authentication chain (SPF pass, DKIM pass, DMARC pass with alignment), the rDNS configuration, the sending pattern from the IP.
We submitted the additional information by end of day Wednesday. The submission included a brief narrative summarizing the sender, the operational practices, and why we believed the CSS listing was incorrect for this sender.
Thursday May 8 to Saturday May 11: parallel work and limited Spamhaus response
The Spamhaus side went quiet through Thursday and Friday. Our follow-up emails received automated responses indicating the case was under review. No additional information requests, no preliminary outcome indications.
We used this period to do parallel work that would help regardless of the Spamhaus outcome.
The customer’s sending was migrated partially to other IPs in their pool. The other IPs continued operating without CSS listings. The customer’s daily volume continued but with proportional load on the unlisted IPs. The IP A volume dropped to minimal (~10% of normal) during this period.
We reviewed the customer’s full sending operation for any operational practices that might be triggering CSS classification. The audit found:
The customer’s IP pool had grown over the past 90 days from 4 IPs to 7 IPs as their volume grew. The pattern of “expanding IP pool with steady volume per IP” can look like snowshoe even when it is legitimate scaling.
Some of the new IPs were from a different /24 range than the original pool. The geographic and AS-level distribution of the pool changed during the growth period. The pattern of “distributed IPs across multiple ranges with similar sending patterns” can trigger CSS.
The content of the customer’s newsletters had been A/B tested with multiple template variations going to different segments. The pattern of “many similar-but-not-identical messages across many IPs” can be CSS pattern indicator.
None of these practices were inherently problematic, but the combination might have looked like snowshoe to CSS’s automated analysis. We documented the findings for the Spamhaus review and made some operational adjustments.
Saturday May 11: limited weekend progress
Spamhaus operations slow over weekends. We did not expect a response Saturday and did not receive one.
We continued monitoring the customer’s sending operations. The IP A remained listed. The other IPs continued operating normally. Delivery rates on the unlisted IPs remained stable.
The customer’s lost revenue from the partial sending volume on IP A was estimated at €4,200/day. The cumulative impact through Saturday was approaching €25,000.
Monday May 13: Spamhaus engagement resumed
Monday morning we received a substantive response from Spamhaus. The reviewer had examined the case and identified the specific factors that triggered the CSS listing. The factors aligned with our internal audit: the IP pool expansion pattern combined with the content variation and the recipient distribution had matched their snowshoe detection algorithms.
The Spamhaus reviewer was clear that they understood our sender was legitimate. The challenge was that their automated CSS system had identified the pattern. Manual review can override automated listings but requires the underlying patterns to either change or be definitively explained.
Their request: confirm the operational adjustments to the IP pool growth pattern, provide a statement about future practices, and acknowledge that re-listing could occur if the pattern recurs.
We provided the requested commitments. The customer agreed to slow IP pool expansion (no new IPs added without 30-day evaluation periods), reduce content variation across IPs (use the same content templates per campaign across all IPs rather than A/B testing across IPs), and provide Spamhaus with advance notice if significant operational changes were planned.
The customer’s operational team initially pushed back on the A/B testing constraint. A/B testing is a standard marketing practice and the constraint affects their optimization capability. We discussed the trade-off: lose some optimization capability or accept potential CSS re-listing. The customer chose to accept the constraint as the cost of maintained deliverability.
Tuesday May 14: delisting confirmed
The Spamhaus delisting confirmation arrived Tuesday afternoon, May 14th. The IP A was removed from CSS. The delisting was effective immediately on the Spamhaus side.
The propagation to receiver-side mail servers took several hours. Receivers cache CSS data and refresh on different schedules. By Wednesday morning, May 15th, the rejection pattern in the customer’s sending logs had cleared. Mail to corporate and smaller business recipients started flowing normally again.
The 9-day total
The full sequence:
- Day 1 (Tuesday May 6): listing detected, initial diagnostics complete
- Day 2 (Wednesday May 7): Spamhaus contacted, additional information requested and provided
- Days 3-5 (Thursday-Saturday): parallel work, internal audit, limited Spamhaus engagement
- Day 6-7 (Sunday-Monday): operational adjustments, follow-up with Spamhaus
- Day 8 (Monday May 13): substantive Spamhaus engagement
- Day 9 (Tuesday May 14): delisting confirmed
- Day 10 (Wednesday May 15): full receiver-side propagation
Total impact: 9 days of degraded delivery for the IP A, approximately €40,000 in estimated revenue impact for the customer, several hundred hours of operational work across our team and the customer’s team.
What worked
The detection speed mattered. The customer’s monitoring caught the delivery rate drop within 90 minutes of the listing. Earlier detection produces earlier remediation start. Senders without sub-hour delivery monitoring would have noticed the issue days later, by which point the cumulative damage would be larger.
The information gathering speed mattered. We had the documentation Spamhaus requested within 8 hours of their request. Senders who do not have list source documentation, complaint rate data, and authentication headers ready to share will spend days assembling the package and the Spamhaus review will be delayed accordingly.
The parallel work mattered. Migrating sending volume to unlisted IPs during the review period kept the customer’s overall business operating. Senders who rely on a single IP have no fallback during the review process.
The honest engagement with Spamhaus mattered. We acknowledged the patterns their system detected, explained our practices in context, and agreed to operational adjustments. Pushing back on Spamhaus or trying to argue the listing was wrong would have extended the review and possibly damaged the relationship for future cases.
The operational adjustments mattered. The CSS listing was not arbitrary; the customer’s practices were producing patterns that looked like snowshoe even though they were not. Adjusting the practices addressed the root cause rather than just remediating the symptom.
What did not work or wasted time
Initial communication with Spamhaus through the web form was slower than expected. The form-based submission produces a ticket but the response time is variable. Direct email to Spamhaus operations (using the correct address from their site) may produce faster initial engagement, though we did not test this directly.
Trying to identify the specific algorithmic trigger consumed time without producing useful action. CSS is automated, the algorithms are proprietary, and Spamhaus does not publish specific thresholds. Time spent trying to reverse-engineer the algorithm is better spent on operational adjustments that address common snowshoe patterns generically.
Some early hypotheses about the cause were wrong. We initially suspected content fingerprinting was the primary trigger; the actual primary trigger was the IP pool expansion pattern. Pursuing the wrong hypothesis cost about a day of effort.
Customer-side communication with Spamhaus would have been counterproductive. Spamhaus prefers to communicate with operators rather than end senders. Our positioning as the operator handling the technical engagement kept the communication consistent.
What we changed in our practice afterward
The post-mortem produced several practice updates for our operations.
We now monitor Spamhaus CSS proactively rather than reactively. The CSS list updates regularly; we check our customer IPs daily rather than waiting for delivery rate degradation to surface listings.
We document IP pool expansion patterns when onboarding new customers. The pattern of “expanding pool size with growing volume” is common for legitimate growing senders but can trigger CSS. Documenting the customer’s growth plan upfront makes the pattern explainable if it triggers automated systems.
We tightened our IP pool expansion guidance for customers. New IPs are added in pairs or singles, not in groups. The expansion is paced with at least 14 days between additions when possible. The pattern of “gradual growth” is harder to confuse with snowshoe than “rapid scale-out.”
We document customer authentication and operational practices in a Spamhaus-ready format. The documentation Spamhaus requests during reviews is now pre-assembled for every customer. If a listing happens, we can submit the response within hours rather than days.
We brief customers on the Spamhaus risk before launching new IP pools. The conversation includes the risk of automated CSS listings, the typical remediation timeline, and the cost implications. Customers understand the risk and the practices that reduce it before they encounter the issue.
The honest cost of automated blocklist systems
The CSS listing of a legitimate sender is a real cost of operating in the modern email infrastructure. Automated systems will sometimes catch legitimate operations. The cost is days of remediation work and revenue impact.
The alternative—blocklist systems that catch fewer legitimate operations—would also catch more spam, which produces worse deliverability for everyone. The system as it exists is a compromise between false-positive and false-negative rates.
For senders, the practical implication: every legitimate sender has some probability of being incorrectly listed at some point. The question is not “will I be listed?” but “how will I respond when it happens?” Senders with documented operational practices, ready remediation processes, and pre-established relationships with their infrastructure providers handle listings faster than senders who treat each event as a surprise.
The 9-day timeline for this customer was on the faster end of what we see. Customers without our involvement often take 15-30 days to navigate the same situation. The difference is the established process and the readiness to provide the information Spamhaus needs.
What we tell customers about Spamhaus generally
Spamhaus is part of the operational infrastructure of email. Their listings affect deliverability across many receivers, not just senders directly mentioning Spamhaus. Their listing decisions, while sometimes frustrating, are not arbitrary. The automated systems are tuned to catch real patterns of abuse, and they catch real patterns most of the time.
For senders, the relationship with Spamhaus is operational rather than adversarial. They are doing the work of identifying spam patterns. Senders doing the work of operating legitimately should mostly stay off the lists. When listings happen incorrectly, the response process exists and works.
The customer in this post-mortem was listed for nine days. The customer continues to operate normally. The relationship with Spamhaus is intact. The operational adjustments produced are sustainable. The cost was real but bounded.
For senders reading this with a “what if I get listed?” thought: the answer is the operational process. Detect quickly, communicate professionally, gather information promptly, adjust practices honestly, accept the delisting timeline. The senders who operate this way handle listings as occasional operational events rather than existential threats. The senders who panic or try to game the system produce worse outcomes than the senders who engage professionally.
Nine days is the cost of operating at scale in 2024. The cost is acceptable for sustainable operation. The work is to minimize the frequency of these events, not to eliminate them entirely.