Spamhaus CSS Listing Removal: Fix It Right

Stop the send before you ask for removal

The bad moment is the bounce that names Spamhaus right before a campaign is supposed to go out.

Do not rush straight to the removal form. CSS is an IP reputation listing. Spamhaus says CSS is built automatically from signals tied to low-reputation mail, poor list hygiene, compromised hosts, insecure installs, misconfigured servers, and other abuse signals. A CSS listing is based on multiple events and heuristics, not one random message.

Spamhaus says CSS listings normally expire three days after the last spam detection. Chronic abuse can last longer. A fast delist will fail if the same IP keeps sending the same signal, so treat removal as the last step. First, find the cause and stop it.

• Pause bulk mail from the listed IP until you know what happened.
• Check the exact sending IP in the Spamhaus IP and Domain Reputation Checker.
• Confirm whether the IP is your dedicated server, a shared ESP pool, or a host controlled by your provider.
• Save bounce text and headers from Gmail, Outlook, Yahoo, and corporate gateways.
• Look for the recent change: a new list upload, new ESP, higher volume, broken DNS, compromised mailbox, CMS spam, or a new server image.

What a CSS listing means

CSS is not a list of email addresses. It is a Spamhaus dataset for IP addresses and IPv6 ranges that look risky to receivers.

Spamhaus lists IPv4 addresses as /32 entries and IPv6 addresses as /64 or larger ranges. Receivers choose how to use the data. One receiver may reject mail, another may put it in spam, and another may combine the listing with its own reputation data.

CSS can be influenced by snowshoe-like sending, bad list hygiene, infected hosts, compromised websites, bots, insecure mail software, weak HELO or EHLO names, missing reverse DNS, and other signs that a sender may harm users. Spamhaus says it does not provide spam samples for CSS listings, so your own logs matter.

If the IP is shared, open a ticket with the ESP or host. Spamhaus says removal requests must come from the registered owner of the IP or domain. If that is not you, give your provider the evidence and ask them to handle the request.

Fix the mail system first

The fastest path off CSS is boring: prove the IP is controlled, authenticated, and no longer sending unwanted mail.

• Check outbound logs for spikes, unknown senders, high bounce rates, repeated Gmail or Outlook deferrals, and messages sent outside your app or ESP.
• Audit every account that can send. Reset compromised mailbox passwords and revoke stale SMTP keys.
• Patch CMS, CRM, and form plugins that can send mail. A hacked site can damage the same domain reputation your campaign uses.
• Verify forward DNS, reverse DNS, and HELO or EHLO. The sending IP should have a PTR record, the PTR hostname should resolve back to the same IP, and the SMTP greeting should be a real fully qualified domain name.
• Clean the list. Remove purchased contacts, scraped contacts, old cold leads, hard bounces, role accounts with no clear consent, and people who have not engaged.
• Throttle volume after the fix. A sudden return to full campaign volume can look like the same event continuing.

Mailbox providers judge the domain as well as the IP. Gmail sender guidance requires SPF or DKIM for all senders. For bulk senders, Google requires SPF, DKIM, DMARC, alignment with either SPF or DKIM, low spam rates, and working unsubscribe for subscription mail. Microsoft email authentication guidance explains SPF, DKIM, and DMARC as core controls and notes that SPF checks the MAIL FROM domain, while DMARC checks alignment with the visible From domain. Bad authentication will not explain every CSS listing, but it makes recovery weaker because receivers have less reason to trust the mail.

Run a quick free InboxRadar domain scorecard after you change DNS. It checks the records receivers use and shows the highest impact fix first.

Authentication checklist for CSS recovery

SPF, DKIM, and DMARC do different jobs. For removal work, you want all three passing and aligned where DMARC requires it.

• SPF: publish one TXT record for the domain that lists every system allowed to send mail for that domain. Keep it under the RFC 7208 limit of 10 DNS lookups for mechanisms and modifiers that cause lookups. Do not use +all. Use ~all while you are testing. Use -all only when you are sure all legitimate senders are included.
• DKIM: turn on signing in each sender, such as Google Workspace, Microsoft 365, Postmark, SendGrid, or your own MTA. Publish the selector record each sender gives you. Check that the signing domain is your domain or a subdomain that aligns with the visible From domain.
• DMARC: publish a record at _dmarc.yourdomain. Start with p=none if you need reports, then move to p=quarantine or p=reject once real senders pass. DMARC passes when SPF passes and aligns with the From domain, or DKIM passes and aligns with the From domain.
• RUA reports: add a reporting address so you can see who is sending as your domain. If the XML is hard to read, use the free DMARC report reader to turn aggregate reports into sender names, IPs, and pass or fail counts.
• MX: keep inbound mail working. Broken MX records do not prove outbound spam, but they make role accounts, abuse mail, verification messages, and removal replies harder to receive.

The standards are public: SPF is RFC 7208, DKIM is RFC 6376, and DMARC is RFC 7489. If a tool gives advice that conflicts with those rules or with Google and Microsoft sender guidance, trust the standards and provider docs.

Request Spamhaus CSS removal

Submit the request only after the source is fixed and you can describe the fix in plain language.

Use the Spamhaus checker and follow the removal path from the result. Spamhaus says removal requests made through other channels, such as email, are not handled. The request must come from the registered owner of the domain or IP, or from the service provider if they own the space. Use an email address that clearly belongs to the domain or organization tied to the IP.

• State the cause: compromised mailbox, bad upload, misconfigured server, hacked CMS, bad ESP pool, or unknown source found in logs.
• State the action: disabled account, patched app, removed list, fixed SPF, turned on DKIM, added DMARC, corrected PTR, changed HELO, or stopped the sending host.
• Give the time and date you fixed it.
• Explain prevention: alerts, DMARC reports, feedback loops, lower send limits, list validation, access review, or a new deploy check.
• Keep the tone factual. Spamhaus has no fee for removal, and any service claiming it can pay for or force faster Spamhaus removal is selling a false promise.

After removal, wait for receivers to refresh. Spamhaus says some networks catch up in one or two hours, and rare sync issues can take longer. If only one network still blocks you, work with that network. If all networks still block you, update the removal ticket with new details.

Keep the next campaign out of spam

A clean delist is the beginning of recovery. Reputation comes back through consistent, wanted, authenticated mail.

• Restart with your most engaged recipients first.
• Send from one clear domain and one clear mail stream. Keep receipts, newsletters, and cold sales mail on separate identities.
• Use one-click unsubscribe for marketing and subscription mail when required, and put a visible unsubscribe link in the body.
• Watch Google Postmaster Tools, Microsoft SNDS when it applies, ESP complaints, hard bounces, and DMARC RUA reports.
• Check public blocklists again after you have checked authentication, logs, complaints, and list quality. A blocklist is often the symptom.

If your campaign points people to a landing page, check whether AI search engines can read it too. The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews because they ride the normal Search index and there is no separate opt-out crawler, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

By contrast, GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt is a site's stated policy, not proof of behavior. Perplexity-User and Bytespider are reported to ignore it, so do not assert from robots.txt what a bot actually did. Only Googlebot documents JavaScript rendering. Client-side-only content may be invisible to other AI crawlers, but treat that as an undocumented risk, not a proven fact about a named bot. Vendor docs are the source of truth for these names: OpenAI crawlers, Anthropic crawlers, Perplexity crawlers, Google AI features, Applebot, and Common Crawl CCBot. Use the free AI visibility checker if campaign pages need to be reachable in AI answers.