Microsoft's 550 5.7.520 error is a permanent rejection — Microsoft is refusing to deliver your message and will not retry. It means your sending IP has been blocked by Microsoft's real-time reputation system, Sender Policy Framework evaluation has failed in a way that triggers policy enforcement, or your domain or IP has been added to a Microsoft-specific blocklist. Unlike Yahoo's temporary TS codes, a 550 is a hard bounce: the message is lost, and your MTA should not retry.
Microsoft 550 Error Code Reference
Microsoft uses a structured taxonomy of enhanced status codes. Each 5.7.XXX code has a specific meaning. Treating them as equivalent and applying a single fix is the most common mistake — different codes require different remediation approaches.
| Code | Error text | Root cause | Fix approach |
|---|---|---|---|
| 550 5.7.1 | Service unavailable; client host blocked | IP on Microsoft block list | SNDS registration + delist request |
| 550 5.7.350 | Remote server returned message not accepted | Domain/IP not authorized to send | Fix SPF record; register JMRP |
| 550 5.7.520 | Access denied, banned sender | IP blocked — sender policy violation | SNDS delist + authentication audit |
| 550 5.7.515 | Access denied, domain does not match | DMARC enforcement failure (from May 2025) | Fix DKIM alignment to From: domain |
| 550 5.7.708 | Service unavailable. Access denied (IP) | Sending limit exceeded for IP | Rate reduction + reputation rebuild |
| 421 4.7.650 | Connection refused — new domain | New domain, no reputation (temporary) | Gradual volume increase, wait |
| 451 4.7.650 | Temporary service unavailable | Rate limiting (not a block) | Reduce rate, retry exponentially |
Diagnosing a 550 5.7.520 Block
The first step is checking Microsoft SNDS (Smart Network Data Services) at sendersupport.olc.protection.outlook.com. SNDS shows the reputation status of each of your sending IPs: green (good), yellow (investigate), or red (blocked). A 550 5.7.520 almost always corresponds to a red status in SNDS. SNDS also shows trap hit data — the number of spam trap addresses your IP hit in the past 30 days — which is the primary cause of Microsoft blocks.
Final-Recipient: rfc822; user@outlook.com Action: failed Status: 5.7.520 Diagnostic-Code: smtp; 550 5.7.520 Access denied, banned sender[COL0NAM10FT065.eop-nam10.prod.protection.outlook.com] # Breakdown: # 550 = permanent rejection (hard bounce) # 5.7.520 = Microsoft policy block on your sending IP # COL0NAM10FT065 = the specific Microsoft MTA that rejected you # eop-nam10 = Exchange Online Protection datacenter (North America region) # This is NOT a content filter — it is an IP-level block # Check which IP was blocked: # Look at the Received: headers above this bounce — the IP listed # in the first Received: line is your sending IP that was blocked. # Check SNDS immediately: # https://sendersupport.olc.protection.outlook.com/snds/
SNDS Registration and Delist Request
SNDS is the primary tool for resolving Microsoft blocks. Registration is free at sendersupport.olc.protection.outlook.com. Once registered with your sending IPs, SNDS shows complaint rate, spam trap hit data, and current IP reputation status. The delist request portal — also at SNDS — submits a manual review request to Microsoft's postmaster team.
▶ Microsoft 550 5.7.520 resolution workflow
JMRP — Microsoft Feedback Loop Setup
JMRP (Junk Mail Reporting Program) is Microsoft's complaint feedback loop — the equivalent of Yahoo's FBL. When a recipient clicks "This is junk" in Outlook or Hotmail, JMRP sends a complaint report to your designated mailbox. Without JMRP registration, Microsoft blocks accumulate silently.
Register at sendersupport.olc.protection.outlook.com/snds/JMRP.aspx. You will need to verify ownership of your sending IP via a confirmation email to the postmaster@ address for the domain in your MAIL FROM (envelope sender). JMRP reports arrive as ARF-format emails — configure your MTA or ESP to automatically suppress the complainant's address upon receipt.
Situation: 100% of sends to Outlook.com and Hotmail.com returning 550 5.7.520. SNDS showed red status with 12 spam trap hits in the previous 7 days. Sending IP not registered with SNDS or JMRP.
Actions: Registered SNDS and JMRP immediately. SNDS data revealed trap hits concentrated on 3,200 addresses imported from a trade show list 8 months prior. Suppressed the entire trade show import globally. Ran remaining Microsoft addresses through email verification — suppressed 8,400 additional invalid addresses. Submitted delist request with remediation documentation.
Outcome: Delist approved in 31 hours. Resumed with 2,000-message test. SNDS showed green within 5 days. Full Microsoft delivery restored at week 2. No re-blocking in 90-day follow-up period.
Microsoft May 2025 Enforcement — What Changed
In May 2025, Microsoft began enforcing stricter authentication requirements for consumer domains (outlook.com, hotmail.com, live.com). Senders without SPF, DKIM, and DMARC alignment began receiving 550 5.7.515 rejections in addition to any existing blocks. This is separate from the 5.7.520 IP block but often appears simultaneously if authentication was not previously configured.
The May 2025 enforcement means that even senders with clean IP reputations started receiving 550 errors if their email authentication was not aligned. The fix requires the same authentication stack as Gmail's February 2024 requirements: SPF covering all sending IPs, DKIM signed with the From: domain (not an ESP subdomain), and DMARC published at minimum p=none with rua= reporting enabled.
