Microsoft 550 5.7.520 Block Fix: SNDS Diagnosis & Outlook Deliverability Remediation

Reading SNDS Data — Green, Yellow, Red

SNDS shows three status colours for each registered IP. Each colour requires a different response and the data behind each colour tells you specifically what action to take.

Preventing Future Microsoft Blocks

The pattern of Microsoft blocks is predictable and preventable. Most senders who experience a 550 5.7.520 block have three conditions in common: no SNDS registration before the block, no JMRP complaint visibility, and list segments older than 12 months without verification. Addressing all three before the next campaign prevents recurrence.

Connector and Policy Rejections

Not all Microsoft 550 errors originate from reputation or blacklisting. A subset of 550 rejections from Microsoft Exchange Online are caused by connector policy rules applied by the recipient organisation — not by Microsoft’s global filtering. These errors look identical in bounce headers but require a completely different response.

Connector-based rejections typically appear as 550 5.7.1 [CustomerID] sender is listed in the organisation's block list or similar. The key differentiator: the error includes a customer-specific ID or domain-specific context rather than the generic Microsoft enforcement language. These blocks are set by the recipient’s Exchange administrator, not by Microsoft’s spam filtering. SNDS will show your IP as Green even while these rejections occur. Resolution requires contacting the recipient organisation’s IT team directly — there is no external delist process for intra-tenant policy blocks.

Microsoft Bulk Sender Requirements 2025

Microsoft’s May 2025 enforcement changes affected all senders to consumer Outlook, Hotmail, and Live domains. The specific requirements now enforced are: SPF pass for the envelope sender domain, DKIM pass with the signing domain matching the From: header domain (alignment), DMARC record present with at least p=none and rua= reporting enabled, and a valid PTR record for the sending IP. Senders missing any of these receive 550 5.7.515 for DMARC failures specifically, and 550 5.7.1 for IP reputation failures.

The critical change from pre-2025 is the DKIM alignment requirement. Previously, DKIM from an ESP’s own domain was sufficient for delivery. Post-May 2025, Microsoft requires DKIM alignment — the DKIM d= tag must match the organisational domain of the From: header. This is the same requirement Gmail has enforced since February 2024. If you are seeing a sudden increase in 550 5.7.515 rejections at Microsoft after May 2025, reconfiguring your ESP to sign DKIM with your own domain is the fix.

Preventing Microsoft 550 5.7.520 and 5.7.511 Blocks

Microsoft blocks are preventable through the same monitoring and quality practices that prevent reputation problems at other ISPs — but Microsoft has specific monitoring tools and specific metrics that make its reputation system more transparent than most. Using these tools proactively is the most effective prevention strategy.

SNDS daily monitoring: Microsoft SNDS (Smart Network Data Services) shows complaint rate and spam trap data per sending IP, updated daily. A sending IP showing Yellow status in SNDS has elevated complaint or spam trap signals that will produce 5.7.511 or 5.7.520 blocks within 1-2 weeks if not addressed. Checking SNDS daily (a 5-minute task) catches the IP reputation degradation before it becomes a block rather than after. Any IP transitioning from Green to Yellow triggers an immediate investigation: which campaigns have been delivered from that IP in the past 7 days? Which list segments were included? What was the bounce rate and complaint rate for those sends?

JMRP complaint data: Microsoft JMRP (Junk Mail Reporting Program) provides individual ARF complaint notifications for Outlook.com recipients who mark messages as spam. Unlike Gmail, which does not provide per-message complaint notifications, Microsoft does — making it possible to see exactly which messages generated complaints at Microsoft recipients. Daily FBL complaint count monitoring (not just weekly) catches Microsoft-specific complaint rate increases within 24-48 hours of a problem campaign, enabling rapid investigation before the IP reputation deteriorates to block level.

Volume management at Microsoft: Microsoft applies burst rate limiting more aggressively than Gmail — a sudden volume increase to Microsoft recipients (e.g., injecting a large campaign segment to Microsoft addresses in a single hour) triggers 421 throttle responses that can accumulate into 550 blocks if not managed. Space Microsoft-bound volume evenly across the campaign delivery window, and configure the Microsoft domain block in PowerMTA with conservative per-minute rate limits that prevent burst injection regardless of what the campaign management system injects. The domain block rate limit acts as a safety governor that prevents the infrastructure from generating volume spikes that Microsoft interprets as anomalous behaviour.