Why are my IPs listed on Spamhaus CSS despite passing DMARC, DKIM, and SPF?
Published 24 Jul 2025
Updated 10 Oct 2026
12 min read
Summarize with
Updated on 10 Oct 2026: We clarified CSS listing checks and added steps to trace unauthorized SMTP traffic before requesting removal.
Your IPs can be listed on Spamhaus CSS even when DMARC, DKIM, and SPF all pass because CSS evaluates sending behavior and reputation, not only authentication. A DMARC pass means SPF or DKIM passed using a domain that matches the visible From domain under DMARC rules. It does not show recipient consent or guarantee good IP reputation.
Treat passing authentication as a baseline, then look for the likely CSS triggers: bad customer traffic, poor recipient acquisition, repeated mail to invalid or mistyped addresses, spam trap hits, risky URLs or domains, sudden bursts, shared infrastructure reputation, compromised accounts, and routing patterns that resemble traffic spreading.
A CSS listing is not cancelled out by a clean DMARC pass. Confirm the listed IP and dataset first, then work backwards through recent logs by IP, customer, domain, template, URL, and recipient outcome.
How authentication differs from CSS reputation
The most likely reason is that one or more mail streams from those IPs look abusive or low-quality to Spamhaus, even if each message authenticates correctly. Spamhaus describes Spamhaus CSS as an automatically produced dataset for SMTP sources, with listing influences including unsolicited mail, poor list hygiene, compromised systems, insecure installations, misconfigured servers, and other low-reputation behavior.
DMARC, DKIM, and SPF establish domain authentication. CSS evaluates sending reputation and behavior. A receiving server can reject a listed IP during the SMTP connection, before it receives the headers needed to evaluate DKIM or DMARC.
- Authentication: SPF checks whether the connecting IP is authorized for the SMTP MAIL FROM domain, or the HELO identity when the reverse path is empty. DKIM validates the signature over signed message data. DMARC needs a passing SPF or DKIM result with domain matching against the visible From domain; it does not require both to pass.
- Reputation: CSS uses multiple events and heuristics associated with unsolicited mail, poor list hygiene, compromise, or other abuse.
- Routing: Spreading traffic across several IPs can look worse if it resembles an attempt to dilute bad mail.
- Infrastructure: HELO names, rDNS, customer domains, hosted URLs, and shared network space can expose connections between mail streams.
What Spamhaus CSS checks
CSS (Combined Spam Sources) is a Spamhaus IP DNSBL focused on SMTP detections on destination TCP port 25. It is a blocklist (blacklist) for sending IPs connected to low-reputation mail. CSS lists IPv4 addresses as individual /32 entries and IPv6 space as /64 or larger prefixes, so one IPv6 listing can cover many individual addresses.
Check authentication guidance, but do not stop there. Correct rDNS, forward DNS, HELO, TLS, DKIM signing, SPF, and DMARC are important technical hygiene. They do not guarantee that a mail stream will avoid a blacklist.
Spamhaus CSS investigation flowchart covering authentication, customer traffic, recipients, and domains.
|
|
|
|---|---|---|
Unwanted recipients | Spam trap hits and invalid-address attempts warrant a list-hygiene review. | Confirm consent and suppress invalid addresses. |
High bounces | Repeated failures show weak address controls. | Suppress invalid-recipient bounces; investigate other failures. |
Related domain listings | Customer or link domains can have separate reputation problems. | Check DBL status and investigate the listing. |
Unexpected HELO | An unknown value can reveal misuse or misconfiguration. | Match it to logs. |
Web app abuse | Compromised forms or CMS processes can send unwanted mail. | Audit outbound sources. |
Traffic bursts | Abrupt changes warrant review alongside recipient and complaint data. | Rate-limit. |
Pool spread | Distributing abusive traffic across IPs resembles snowshoe spam. | Isolate streams. |
Investigation signals, not published CSS listing thresholds.
Why clean authentication is not enough
A phishing message, fake account confirmation, unsolicited invite, or mistyped one-time password (OTP) can pass authentication. If the platform allows a customer to send mail with a verified domain, the message can authenticate while still being unwanted or harmful.
This is why a small low-volume stream of very bad mail matters. A service sending millions of legitimate transactional messages can still get an IP listed if another stream repeatedly sends phishing messages, hits recycled traps, uses a listed domain, or contacts invalid recipients. Large legitimate volume does not erase strong abuse signals.
Passing authentication and valid DNS do not establish recipient consent or rule out compromised accounts. A passing result on a test message also does not prove that every sender using the IP authenticates. Investigate the actual outbound traffic.
OTP and account-confirmation mail can reach unintended recipients when people mistype addresses. Some mistypes bounce. Others land in a real mailbox owned by someone else. Some typo addresses and abandoned inboxes are used as spam traps. If a form accepts common typo domains and retries the same code several times before suppression takes effect, the stream can look worse than the product team expects.
Track invalid-recipient bounce rates against each stream's own baseline and investigate sudden changes by form, customer, and IP. Spamhaus does not publish a universal CSS bounce-rate threshold, and a low aggregate bounce rate does not rule out abusive traffic.
Signals to investigate first
Start with the exact listed IPs. For each one, pull a time-windowed report for all accounts, domains, templates, links, return paths, bounce reasons, suppressions, complaints, and retry attempts. Compare that evidence with the listing time and the last major traffic spike. Preserve the SMTP rejection text and timestamps so you can separate the affected outbound IP from unrelated domain or inbound-server results.
Suped's blocklist monitoring product monitors IP and domain listings and alerts your team to the affected sender and list source. Use the alert time to narrow the logs that need review.
Blocklist checker
Check your domain or IP against 144 blocklists.
- Customers: Find the accounts that sent on the listed IP before and during the CSS event.
- Domains: Check customer domains, link domains, tracking domains, and hosted assets for reputation issues. A Spamhaus Domain Blocklist (DBL) result is separate from a CSS IP listing and needs its own investigation.
- Recipients: Review acquisition sources, purchased or scraped lists, recently reactivated old addresses, repeated sends, and invalid-recipient bursts.
- Content: Look for templates that resemble known spam, fake account notices, credential prompts, or URL-heavy mail.
- Routing: Map which pools share the same range, HELO naming pattern, return path, and customer base.
- Timing: Compare CSS events with volume spikes, queue flushes, suppression changes, and customer campaigns.
For a broader primer on these lists, use blocklist basics. For an authentication and DNS sweep, run a domain health check. For live message headers and authentication output, send an email test from the same MTA path.
Check for outbound SMTP outside your mail server
A clean MTA log does not account for every connection leaving a shared public IP. A compromised device behind the same NAT gateway or a web application sending directly can generate abusive SMTP traffic that never appears in your authorized mail server's logs.
Spamhaus recommends restricting outbound SMTP to authorized mail servers. Apply that restriction to destination TCP port 25 for both IPv4 and IPv6, then trace the source of any unexpected connections.
- Review firewall and NAT logs for outbound port-25 connections. Map each internal source to the listed public IP, and compare timestamps and HELO/EHLO values with the listing details.
- Allow direct port-25 delivery only from authorized MTAs. Configure other clients or applications to use authenticated submission on port 587 or 465 where supported, and log blocked attempts to locate the source.
- Check the mail server for an open relay and review SMTP AUTH activity for stolen credentials. Inspect web applications and scheduled jobs that can send through the authorized MTA.
- Isolate compromised devices, patch affected applications, and rotate exposed credentials. A firewall restriction contains direct SMTP abuse but does not remove the compromise or stop abuse through an authorized account.
How shared ranges affect CSS risk
Abusive traffic from another sender using the same public IP can affect your mail. For IPv6, CSS lists /64 or larger prefixes, so several addresses can share one listing. For IPv4, CSS lists individual /32 addresses; an adjacent IP's listing does not automatically list your dedicated IP. Receiving systems can still connect related traffic through shared sending identities and abuse patterns.
If unrelated customers share your listed IPv6 /64, ask the hosting provider to investigate the abuse and provide a dedicated prefix. If an IP was newly assigned, compare the listing activity with the assignment time and give that evidence to the provider; a previous user's activity needs investigation rather than an assumption about your own mail.
Adding more IPs to bypass reputation throttling can spread the same problem. If a mailbox provider temporarily defers mail, inspect its SMTP response before deciding whether the cause is reputation, rate limits, or a temporary outage. Distributing abusive traffic across more IPs resembles snowshoe spam. Clean the mail stream, smooth peaks, and keep routing stable.
Spamhaus CSS listing result with IP reputation status and removal guidance.
Risky response
- Pool churn: Moving mail away from listed IPs without fixing the sender.
- Extra IPs: Adding more IPs to mask throttling caused by reputation.
- Fast removal: Requesting delisting before the cause is corrected.
Better response
- Isolation: Pause abusive customers. Keep higher-risk legitimate streams in controlled pools with strict limits.
- Throttling: Smooth traffic peaks before mailbox providers do it for you.
- Correction: Fix recipient, content, and domain issues before delisting.
Fixes that reduce relisting
The strongest fix is to stop the bad mail at the source. CSS delisting can be fast, but relisting is fast too when the same signals continue. Fix the cause first, request removal, then watch for recurrence by customer and IP.
- Recipient gates: Suggest corrections for common typo domains and suppress known invalid addresses. Use confirmed opt-in (double opt-in) for subscriptions; rate-limit OTP requests and resends.
- Suppression rules: Suppress addresses after permanent invalid-recipient bounces. Apply bounded retries to temporary failures such as full mailboxes, and investigate policy blocks separately.
- Customer controls: Review high-bounce senders, new accounts, sudden traffic spikes, and low-volume accounts with suspicious content.
- Domain screening: Investigate customer or link domains listed on the Spamhaus Domain Blocklist (DBL), and suspend sources tied to unresolved abuse.
- Stable identity: Use a valid fully qualified HELO/EHLO hostname that matches the PTR and resolves back to each active sending IP.
- Traffic shape: Avoid sudden queue dumps and keep high-risk senders away from dedicated customer pools.
IPv4 MTA identity example
PTR: 203.0.113.10 -> mta1.mail.example.com A: mta1.mail.example.com -> 203.0.113.10 HELO: mta1.mail.example.com
A valid hostname does not need to contain 'mail'. Check the public A or AAAA record for the HELO/EHLO hostname and confirm that the PTR uses the same hostname. Ask the IP owner or hosting provider to correct reverse DNS if you cannot manage it.
For a deeper Spamhaus-specific remediation path, read the Spamhaus block guide. If messages authenticate but still go to spam, the same thinking applies when authentication still passes: identity checks are only one part of deliverability.
How to confirm and remove a CSS listing
A CSS listing points to recent activity. Spamhaus's CSS guidance says listings normally expire three days after the last spam detection, although chronic abuse can keep them active longer. The interval starts after the last detection, not after your removal request. Waiting is not a fix if the same traffic continues.
- Confirm the dataset: Record the affected outbound IPv4 address or IPv6 prefix. CSS is included in Spamhaus ZEN and the SBL DNSBL zone, where its return code is 127.0.0.3. ZEN is a combined list, so a ZEN result alone does not establish CSS. Distinguish CSS from SBL, XBL, PBL, and a separate domain DBL listing before choosing remediation.
- Review recent HELO values: Compare the values shown with the configured MTA names. Unknown or random names can indicate a misconfigured process, compromised host, or unapproved sender.
- Validate MTA identity: Make the HELO/EHLO hostname resolve to the sending IP through an A or AAAA record. The PTR must use that same fully qualified hostname and resolve back to the IP, providing forward-confirmed reverse DNS (FCrDNS).
- Correct the traffic source: Stop unwanted mail, secure compromised applications, enforce suppressions, and review related domain reputation before requesting removal.
- Request removal: Follow the official Spamhaus removal workflow after correcting both the traffic source and DNS checks. Self-removals are limited; if automatic removal is unavailable, follow the ticket process presented. For shared or provider-managed IPs, involve the IP owner or hosting provider.
- Watch for recurrence: Keep the sending identity stable and monitor the affected IP, customer, and domains after delisting. Check SMTP responses as receiving-system caches refresh. A quick relisting indicates new detection and calls for another source investigation.
Spamhaus says CSS decisions use multiple events and heuristics, and it does not provide spam samples for CSS listings. It sometimes has additional information for compromise cases. Build the case from listing details, recent HELO data, MTA and firewall logs, customer activity, recipient outcomes, and reports sent to your abuse contact.
How Suped fits into this workflow
Suped's product supports this investigation by placing DMARC, SPF, DKIM, blocklist (blacklist) monitoring, source attribution, and alerts in one workflow. The useful connection is timing: a new CSS event can be compared with sender changes and authentication data without treating authentication as the cause of every reputation problem.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Set alerts for IP and domain listings, watch DMARC source changes, and compare verified senders with unexpected sources. Use the listing time to inspect the relevant customer, sending IP, and domain logs, then keep the same monitoring active after removal. DMARC reports do not cover every outbound message, so use MTA and firewall logs to investigate traffic outside the reporting data.
Suped's product helps detect the listing and identify the affected IP or domain. Compare that alert with authentication and sending-source data, verify the cause in your own logs, fix the source, and keep monitoring after removal. Spamhaus controls CSS delisting.
Frequently asked questions
Yes. DMARC passes when SPF or DKIM succeeds using a domain that matches the visible From domain under DMARC rules. It does not prove that the recipient wanted the message, that the content is safe, or that the sending IP has good reputation.
Yes. A previous user's activity or a shared IPv6 prefix can explain a listing on a newly assigned address. Compare the listing details with your assignment time, give the evidence to the hosting provider, and check for current outbound abuse before requesting removal.
Spamhaus says CSS listings result from multiple events and heuristics, so do not infer a one-message trigger. A short low-volume stream can still produce repeated strong detections that deserve immediate review.
Not always. A CSS listing can result from unwanted mail, poor recipient hygiene, or compromised systems. If your MTA logs are clean, check other devices sharing the public IP and inspect outbound TCP port-25 traffic in firewall logs.
Stop abusive accounts or unauthorized SMTP traffic, correct recipient and suppression problems, and verify matching HELO/EHLO, PTR, and forward DNS. Investigate related DBL listings, then follow the official removal process with the IP owner if required.
Spamhaus says CSS listings normally expire three days after the last spam detection, not three days after a removal request. Chronic abuse can keep a listing active longer, and a new detection can cause rapid relisting.
