SMTP response received
550 5.1.0 ETP202: Your IP address is listed by Spamhaus. Please contact Spamhaus for delistingYou received this code because the receiving Microsoft Exchange Online mail server refused delivery because your sending IP was found on Spamhaus during Microsoft internal reputation check. The ETP202 tag is Microsoft Exchange Transport Protocol code indicating "Spamhaus-listed sender". Recovery requires Spamhaus delisting first, then waiting for Microsoft reputation cache to refresh, and potentially separate Microsoft mitigation if a deeper ban has been triggered.
๐ In this guide
๐ค Who sees this code
- Sender whose delivery to Microsoft 365 stopped after a Spamhaus listing
- Ops team investigating why Spamhaus delisting has not restored Microsoft delivery
- Deliverability lead coordinating Spamhaus + Microsoft dual remediation
๐ง What this guide fixes
- Understand the ETP202 Microsoft Spamhaus integration
- Coordinate Spamhaus delisting with Microsoft cache refresh timing
- Determine whether separate Microsoft mitigation is also required
๐ The 5.7.x security and policy family
550 5.7.1Delivery not authorized ยท policy or auth failure
550 5.7.9Message content not supported by policy
550 5.7.26Multiple authentication failures
421 4.7.0Transient policy ยท often greylisting
โก Do these 3 things first (before diving deeper)
Confirm the ETP202 tag in the diagnostic text
The ETP202 identifier is Microsoft-specific and confirms this is Microsoft Exchange Online rejecting due to Spamhaus consultation. Extract the exact diagnostic text from the Diagnostic-Code field of the bounce. If the tag is present, you have both a Spamhaus problem and a Microsoft delivery problem simultaneously. If the tag is absent but the wording mentions Spamhaus, the receiver may be citing Spamhaus without being Microsoft. See our DSN parsing guide for extracting these markers reliably.
Verify the active Spamhaus listing directly
Go to check.spamhaus.org and query your sending IP. The result confirms which Spamhaus zone lists you (SBL, PBL, CSS, or XBL) and shows the listing reason if available. Microsoft consults Spamhaus continuously but caches results โ if Spamhaus shows unlisted but Microsoft continues rejecting with ETP202, Microsoft cache has not yet refreshed. The cache refresh typically takes 4 to 24 hours after Spamhaus delisting.
Check whether 5.7.606 or other Microsoft-specific rejections accompany
ETP202 can arrive as a standalone Spamhaus-cited rejection or as an early indicator of deeper Microsoft reputation problems. If you also see 550 5.7.606 Microsoft IP ban across tenants, the underlying reputation damage requires both Spamhaus delisting AND separate Microsoft mitigation through their sender support form. Address each in parallel because the review processes are independent.
Common causes of 550 5.1.0
- Active Spamhaus SBL, PBL, CSS, or XBL listing. The most common cause. Your IP appears on one of the Spamhaus zones that Microsoft consults through their integrated reputation infrastructure. Each zone has a different trigger: SBL for confirmed spam, PBL for IPs not intended for direct mail, CSS for compromised or dedicated spam infrastructure, XBL for infected hosts. The specific zone determines the delisting procedure, but the rejection at Microsoft cites Spamhaus generically without distinguishing the zone. Confirm the specific zone via the Spamhaus lookup before submitting the delisting request.
- Historical Spamhaus record still in Microsoft cache. Microsoft consults Spamhaus continuously but caches results for 4 to 24 hours. If you were previously listed and Spamhaus has already delisted you, Microsoft may still return ETP202 for the cache duration. Wait 24 hours after Spamhaus delisting confirmation before concluding the Microsoft rejection persists. If ETP202 continues beyond 48 hours after Spamhaus delisting, Microsoft is not honoring the delisting due to their own reputation reasons, not the Spamhaus data.
- Reputation degradation crossed Microsoft threshold in combination with Spamhaus. Microsoft weighs Spamhaus listing alongside their own SNDS reputation data. Being on Spamhaus alone might not trigger ETP202 if your Microsoft reputation is otherwise strong. Being on Spamhaus WITH deteriorated Microsoft reputation absolutely triggers ETP202. This dual-signal architecture means recovery requires both Spamhaus delisting AND Microsoft reputation rebuild through the cold IP recovery process. See our cold IP recovery playbook.
- Combined Spamhaus + Microsoft reputation issues. When ETP202 accompanies additional Microsoft-specific rejections (550 5.7.606, 550 5.4.1, 550 5.7.26), the reputation problem is systemic across both Spamhaus signals and Microsoft internal signals. Delisting from Spamhaus alone does not fully restore delivery to Microsoft โ you also need to address the Microsoft-specific reputation issues that produced the accompanying codes. This scenario requires the longest recovery timeline (4 to 8 weeks minimum) of any Spamhaus-adjacent rejection.
- Compromised infrastructure detected in the Spamhaus + Microsoft correlation. Microsoft correlation of Spamhaus data with their own metrics can flag potentially compromised sending infrastructure faster than either signal alone. Sudden ETP202 appearing without a specific triggering event may indicate that your infrastructure has been compromised: a compromised SMTP credential, malware on your sending server, or an exploited web application pushing spam. Investigate outbound logs for unauthorized activity before submitting any delisting request.
How to fix 550 5.1.0, step by step
- Delist from Spamhaus first through their standard portal. Head to check.spamhaus.org and use the removal request form specific to the zone your IP appears on (SBL, PBL, CSS, or XBL). Explain the trigger if you know, describe your remediation, and provide evidence (log excerpts, screenshots of changed configurations, updated list hygiene procedures). Honest requests with clear remediation get processed faster. Expect 24 to 72 hours review for standard cases. See our Spamhaus delisting guide for the detailed process.
- Wait 24 hours after Spamhaus confirmation for Microsoft cache refresh. After Spamhaus confirms delisting, do not immediately test-send to Microsoft addresses. Microsoft caches Spamhaus consultation results for 4 to 24 hours. Sending during the cache window produces continued ETP202 rejections that look like the delisting failed. Wait a full 24 hours, then send a single test message to a monitored Microsoft address. If delivery succeeds, the Microsoft-side cache has refreshed and delivery to Microsoft has resumed.
- Check if 550 5.7.606 needs separate Microsoft mitigation. If ETP202 accompanies 550 5.7.606 (Microsoft-specific permanent IP ban), Spamhaus delisting alone will not restore delivery. Submit the Microsoft Sender Support mitigation form at sender.office.com/pm/troubleshooter in parallel with the Spamhaus delisting. The two processes run independently: Spamhaus review takes 24 to 72 hours; Microsoft mitigation takes 2 to 8 weeks. Do not wait to submit the Microsoft mitigation until Spamhaus resolves โ that adds unnecessary weeks to your recovery.
- Warm up carefully after complete resolution. Post-resolution recovery to Microsoft is slower than to other receivers because Microsoft weighs recent-history heavily. Start at 10 to 25 percent of your pre-listing volume, monitor SNDS daily, and scale up over 14 to 28 days if metrics stay green. Rushing back to full volume looks like continued risk to Microsoft reputation systems and can trigger a second ETP202 or escalation to 5.7.606. Follow our warmup schedule guide for the exact daily volumes during recovery.
- Monitor both Spamhaus and Microsoft dashboards going forward. ETP202 recovery requires ongoing monitoring on two fronts: Spamhaus status (re-check monthly at least) and Microsoft SNDS reputation (daily during recovery, weekly after stabilization). A single re-listing on either side can produce ETP202 recurrence, and the dual-signal architecture makes ETP202 more frequent than either single-source rejection would be. Building both checks into your ops routine is what prevents recurrence.
๐ How each provider sends this exact code
โ How this code differs from adjacent ones
550 5.7.1 blocked by Spamhaus (direct)550 5.7.606421 4.7.28Prevention going forward
ETP202 is Microsoft telling you that Spamhaus has flagged you, which means two things went wrong: reputation degraded enough to trigger Spamhaus, and Microsoft is honoring that signal. Preventing recurrence means addressing both fronts.
- Validate every address at collection with SMTPing to prevent spam trap hits that trigger Spamhaus listings. Trap hits are the fastest path from clean sender to ETP202.
- Monitor SNDS daily for Microsoft-specific reputation signals. Microsoft reputation degradation combined with any Spamhaus event produces ETP202; monitoring both catches problems before they compound.
- Follow the 30/60/90 warmup schedule strictly for any new sending IP. Rushed volume from unwarmed IPs is one of the fastest paths to reputation issues at Microsoft that combine with Spamhaus into ETP202.
- Cap complaint rate at 0.1 percent for Microsoft-facing traffic. Microsoft is stricter than Gmail on complaints, and elevated complaint rates precede both Spamhaus listing and ETP202.
- Segregate high-risk sending onto separate IPs from reputation-critical Microsoft-facing traffic. If a high-risk IP hits Spamhaus, your main Microsoft-facing sending is unaffected.
Frequently asked questions about 550 5.1.0
What exactly does ETP202 mean and where does it come from?
How is ETP202 different from directly-cited Spamhaus rejections?
Why do Microsoft rejections continue for 24 hours after Spamhaus confirmation?
Do I need to submit a Microsoft mitigation request in addition to Spamhaus delisting?
Can ETP202 come back after successful delisting?
Does ETP202 affect delivery to Gmail or Yahoo?
Stop 550 5.1.0 bounces before they happen.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send. Fewer bounces means less firefighting and a healthier sender reputation. 13 validation types, 25 free daily, no card required.
๐ Deep dive on related codes
550 5.4.1Office 365 tenant policyRecipient address rejected at Microsoft โ auth or reputation cause
550 5.7.1Blocked by SpamhausSpamhaus SBL/PBL/CSS/XBL delisting playbook
550 5.7.606Microsoft IP banPermanent Microsoft ban with mitigation form
550 5.7.1Blocked by BarracudaBRBL delisting for enterprise recipients
About the Author
Alaa ยท LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
