How to fix Spamhaus CSS listing and prevent email blocks on Outlook/Hotmail?
Michael Ko
Co-founder & CEO, Suped
Published 23 Apr 2025
Updated 18 May 2026
11 min read
To fix a Spamhaus CSS listing that is causing Outlook or Hotmail blocks, stop sending from the listed IPs, identify the behavior that triggered the listing, remove the bad traffic source, clean the recipient base, fix any domain reputation issue tied to the campaign, then use the Spamhaus CSS self-removal process only after the problem is fixed. If self-removal has already failed several times, pause the IPs and wait for the listing to expire while preparing clear evidence that the cause has been removed.
The mistake I see most often is treating CSS like a simple DNS mistake. It is not. A CSS listing is usually a signal that Spamhaus saw behavior consistent with unwanted mail, compromised systems, snowshoe-like sending, poor list sourcing, bad suppression handling, or related non-email abuse. Microsoft can then reject or junk the mail because Outlook and Hotmail systems treat that reputation signal seriously.
Immediate action: Pause all bulk mail from the listed IPs before asking for delisting again.
Main fix: Remove the sender, list segment, automation, compromised host, or domain that caused the listing.
Microsoft angle: Do not test large Outlook or Hotmail sends until the CSS listing and sending behavior are clean.
Monitoring step: Use blocklist monitoring with authentication data so you can see whether the same IPs, domains, or sources keep causing trouble.
What a Spamhaus CSS listing means
CSS means Combined Spam Sources. It is part of the Spamhaus reputation system and is commonly seen through the SBL DNS zone, but it is not the same operational problem as a normal manual SBL listing. The practical difference matters: CSS is heavily automated, often narrow to a single IP address or IPv6 range, and self-removal exists when the listing qualifies.
Spamhaus describes CSS in its CSS FAQs as a system for IPs involved in spam-source behavior. In practice, I treat a CSS listing as evidence that something about the send stream is too risky to keep sending while hoping the block clears.
Signal
Typical scope
Best response
CSS
IP behavior
Fix source, self-delist once
SBL
Manual listing
Document fix, contact Spamhaus
DBL
Domain reputation
Fix domain and content signals
CSS and SBL need different response plans.
Do not burn your self-delisting path
Repeated self-delisting while the same bad traffic continues can make the situation worse. Once Spamhaus sees repeated removals followed by relisting, it becomes harder to argue that the issue was fixed. I would rather pause for a few days, prove the traffic has stopped, and delist once with a clean story.
Why Outlook and Hotmail block the mail
Outlook and Hotmail blocks usually happen because Microsoft sees a combined reputation problem, not because one record is missing. A Spamhaus CSS listing is one signal. Microsoft also looks at complaints, spam-trap hits, volume changes, engagement, same-domain authentication, content patterns, and IP history. Passing SPF, DKIM, and DMARC does not override a poor sending reputation.
If Outlook or Hotmail suddenly blocks a high percentage of mail after a CSS listing, the right answer is not to route around the problem with another unproven IP. That pattern can look like evasion. Fix the listed stream, reduce volume, remove risky recipients, and use testing only after the observable blocklist and blacklist signals have improved.
Flowchart for moving from Microsoft bounces to CSS recovery.
The bounce text is useful because it tells you whether Microsoft is blocking due to its own reputation systems, a referenced third-party blocklist, or a mix of both. Keep the exact SMTP code, enhanced status code, sending IP, recipient domain, timestamp, campaign name, and message ID. A vague statement like "Hotmail blocked us" is not enough to diagnose the path back.
Evidence to keep from a Microsoft bouncetext
Recipient: user@hotmail.com
Sending IP: 203.0.113.25
SMTP code: 550 5.7.1
Enhanced code: S3150 or related block text
Timestamp: 2026-05-18 10:42 UTC
Campaign: May reactivation test
Message ID: <abc123@example.com>
Step 1: confirm the listing and exact scope
Start with the exact IP address and listing type. Do not rely on a screenshot, a forwarded complaint, or one mailbox provider's rejection. Check the listed IP, the sending domain, the bounce domain, the tracking domain, and the visible website domain. CSS is IP-focused, but a concurrent domain listing can keep Microsoft blocking even after the IP improves.
Listed IP: Confirm whether one IP, a pool, or an IPv6 range is affected.
Listing text: Record whether the identifier starts with CSS, SBL, or DBL.
Domain checks: Check the organizational domain, return-path domain, link domain, and image host.
Authentication: Check SPF, DKIM, and DMARC identity matching so reputation repair is not blocked by a basic failure.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a broad first pass, a domain health check helps connect the DNS side with the reputation side. I still keep the raw bounce messages and listing evidence because they show what mailbox providers actually saw.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Step 2: stop the traffic that caused it
Stopping all mail is blunt, but it is often the correct first move when Outlook and Hotmail are rejecting a large share of volume. After that, narrow the stop to the source. The source is often a reactivation campaign, old list import, customer account, compromised form, shared pool sender, automated notification stream, or a domain created only for mail with no real brand presence.
What keeps the listing alive
Repeated delisting: The same IP returns to the same bad pattern after removal.
Stale recipients: Old contacts, recycled traps, and dead mailboxes stay in the send.
Pool leakage: Another tenant or customer continues the same risky traffic.
What actually helps
Source isolation: Map bounces and listings back to sender, campaign, and IP.
Recipient cuts: Suppress unengaged, invalid, unsubscribed, role, and suspect records.
Clean restart: Resume only with recent, consented, engaged recipients.
The hardest part is being honest about the list. A list can be "opt-in" and still be unsafe if it includes single opt-in records, old store registrations, addresses that never opened, dormant accounts, or imported segments with unclear provenance. If the campaign was twice normal size and aimed at old low-engagement recipients, I would assume the list caused at least part of the issue until proven otherwise.
Do not move the same bad mail
Moving the same campaign to a fresh IP, a new domain, or a different subdomain does not solve a CSS problem. It spreads reputation damage. If the recipient set, content, and complaint pattern stay the same, the new path inherits the risk.
Step 3: clean the list before delisting
Before using the self-removal path again, make irreversible list changes. I prefer to export the removed segments and preserve the audit trail, but I do not keep sending to them while testing whether the block clears. The goal is to prove that the risky traffic has stopped, not that a smaller version of the same risk can slip through.
Segment
Action
Reason
Unsubscribed
Remove
Consent is gone
Hard bounces
Remove
No valid mailbox
No opens
Suppress
High trap risk
Old signups
Reconfirm
Consent is stale
Role accounts
Review
Weak consent
Recipient segments to suppress before retrying Outlook and Hotmail.
Engagement windows should be strict during recovery. For Microsoft-heavy mail, I would start with recipients who opened, clicked, purchased, logged in, or otherwise interacted recently. If a recipient has never opened or has been dormant for months, leave them out until reputation is stable.
Recovery list risk thresholds
Use strict engagement thresholds while recovering from CSS and Microsoft blocks.
Safe restart
0-30 days
Recent click, purchase, login, or reply.
Cautious test
31-90 days
Recent open with no complaint or bounce history.
Suppress now
90+ days
No recent engagement or unclear source.
Step 4: fix domain and authentication signals
A CSS listing is IP-focused, but domain choices still matter. If the sending domain has no website, no brand history, no redirect to the real company, or only generic email-platform content, filters can treat it as suspicious. That gets worse when the same domain appears in links, images, return paths, and DKIM signatures across a risky campaign.
DMARC will not remove a CSS listing by itself, but it gives you evidence. With aggregate reports, I can see which sources are using the domain, whether SPF and DKIM pass with the right domain, and whether an unapproved sender is sending mail that looks like yours. In Suped, the useful workflow is to combine DMARC monitoring with blocklist alerts, then trace each authentication source back to the campaign or platform that used it.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
During cleanup, check the DNS basics and keep them boring. The policy does not need to jump to enforcement during a blocklist incident, but the record should be valid, reporting should work, and every active sender should authenticate with a matching domain identity.
Basic DMARC record during investigationdns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
Where Suped fits
Suped is the practical place to centralize this work when a CSS listing is mixed with Microsoft blocks. It brings together DMARC, SPF, DKIM monitoring, hosted SPF, hosted DMARC, blocklist monitoring, real-time alerts, and clear issue steps so the team can move from "we are blocked" to "this source caused it and this is the fix."
Step 5: use self-delisting carefully
For CSS, self-delisting is often available through Spamhaus. Use it after the cause is gone. If you have already used the form several times and Spamhaus says the listing remains, assume you no longer have a simple self-removal problem. At that point, the best move is to stop the bad traffic, wait, and prepare a concise remediation note.
Confirm scope: Record the listed IP, listing type, and all domains used in the campaign.
Pause risk: Stop the campaign, automation, customer, or compromised source.
Clean lists: Suppress unsubscribed, bounced, dormant, unengaged, and suspect addresses.
Fix identity: Make the sending domain credible and tied to the real brand.
Delist once: Use the self-removal flow only when you can explain what changed.
Short remediation note to keep internallytext
Cause: Reactivation campaign to old, low-engagement records.
Action: Campaign stopped on 2026-05-18.
Suppression: Unsubscribed, bounced, and 90+ day inactive records removed.
Domain: Sending domain now redirects to the primary brand domain.
Restart: Only 30-day engaged recipients will receive the next send.
If the block remains, avoid sending from those IPs while waiting for timeout. A quiet period helps prove the source has stopped. In one common recovery pattern, teams pause the IPs for several days, remove risky recipients, and see the blocklist and blacklist pressure clear after the bad stream stops.
Step 6: restart without triggering Microsoft again
After delisting, do not resume the old campaign plan. Restart with a small Microsoft-specific segment of recently engaged recipients and watch bounces, complaint signals, opens, clicks, and blocklist status. A clean restart proves the change worked. A rushed restart proves to filters that the same sender behavior is back.
Safer restart plan
Keep Microsoft volume conservative until bounce and blocklist signals stay clean.
Recent engagement
Older engagement
Suppressed
Test with real mail alongside DNS checks. A message can authenticate correctly and still be blocked or junked because the sending reputation is damaged. Use an email tester for message-level checks, then compare that with actual Microsoft bounce and inbox data.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If Microsoft rejects again, stop immediately and inspect the first failing slice. The goal is not to push through the block. The goal is to learn whether the remaining risk sits in a domain, content template, recipient segment, or sending IP.
When CSS is only one issue
CSS rarely exists in isolation when the underlying problem is serious. If you also see DBL, other IP blocklists, domain blacklist entries, high Microsoft complaint rates, or block codes like S3140 and S3150, treat the incident as a full reputation problem. The repair plan needs to cover the sending identity and the audience, rather than one listing.
Microsoft Outlook delivery failure screenshot with block details.
A good escalation packet has five parts: exact bounces, the listed IPs, list-source explanation, suppression evidence, and the restart plan. If you use a shared email platform, include the provider's deliverability team early because they can see pool-level traffic that you cannot. If one customer caused the problem, quarantine that customer before they affect the rest of the pool.
A clean recovery pattern
Pause: No bulk traffic leaves the listed IPs while the cause is investigated.
Remove: The bad segment, domain, compromised source, or customer is taken out.
Verify: Blocklist, DNS, DMARC, and Microsoft bounce data are checked together.
Resume: Only engaged recipients receive mail until reputation is stable.
For a deeper Microsoft-specific path, the same principles apply when Outlook blocks email: prove the bad traffic stopped, then restart conservatively with clean authentication and engaged recipients.
Views from the trenches
Best practices
Pause listed IPs, isolate the source, then delist after the risky traffic is gone.
Keep bounce text, listing identifiers, campaign names, and timestamps in one evidence file.
Restart with recent engaged users only, then expand after Microsoft bounces stay clean.
Common pitfalls
Repeated self-delisting before fixing the cause can remove your easiest recovery path.
Calling a list opt-in without checking age and engagement hides spam-trap exposure.
Moving bad mail to a new IP or domain spreads the reputation issue instead of fixing it.
Expert tips
Treat concurrent domain listings as part of the same incident, not a separate cleanup.
Check whether the sending domain has credible brand presence and matching authentication.
Use a quiet period to prove the source stopped before asking filters to trust the stream.
Expert from Email Geeks says CSS listings differ from normal SBL listings because the listing and delisting behavior is mostly automated.
2018-11-29 - Email Geeks
Expert from Email Geeks says repeated self-delisting without fixing the cause can remove the sender's ability to use simple self-removal.
2018-11-29 - Email Geeks
The practical fix
The fix is more than "request delisting." The fix is to stop the listed traffic, prove why it happened, remove the source, repair domain and authentication signals, then restart with a smaller engaged audience. For Outlook and Hotmail, I would not send a scheduled bulk campaign from the affected IPs while the CSS listing is active or while Microsoft bounces are still showing reputation blocks.
For most teams, Suped is the best overall practical choice when the incident involves multiple moving parts: DMARC evidence, SPF and DKIM identity checks, hosted SPF changes, blocklist alerts, and specific issue steps for the people who own DNS, sending platforms, and campaign lists. The platform does not make Spamhaus ignore bad traffic. It helps teams find the bad traffic faster and keep it from returning.
CSS
Outlook and Hotmail blocks usually happen because Microsoft sees a combined reputation problem, not because one record is missing. A Spamhaus CSS listing is one signal. Microsoft also looks at complaints, spam-trap hits, volume changes, engagement, same-domain authentication, content patterns, and IP history. Passing SPF, DKIM, and DMARC does not override a poor sending reputation.
DMARC will not remove a CSS listing by itself, but it gives you evidence. With aggregate reports, I can see which sources are using the domain, whether SPF and DKIM pass with the right domain, and whether an unapproved sender is sending mail that looks like yours. In Suped, the useful workflow is to combine DMARC monitoring with blocklist alerts, then trace each authentication source back to the campaign or platform that used it.
