Blue Canoe

Commercial site

Search Blue Canoe

Enter at least two characters.

Guides · reviewed 27 August 2026

Delivering mail to Outlook.com

Current Outlook.com sender requirements, SNDS and JMRP operation, with consumer Outlook separated from Exchange Online.

·

This guide covers Microsoft’s consumer Outlook.com service, including recipients at outlook.com, hotmail.com, live.com and msn.com. It does not treat every Microsoft 365 or Exchange Online recipient as Outlook.com; organizational recipients have tenant policy and a separate NDR system.

Baseline Outlook.com requirements

Microsoft’s published policies require sending systems to use valid reverse DNS, comply with Internet mail standards, avoid insecure relays and stop retrying a message after a permanent 5xx response. Subscription mechanisms must be clearly documented and easy to use.

Microsoft recommends SPF, DKIM and DMARC for all senders. From 5 May 2025, domains sending more than 5,000 messages a day to Outlook.com accounts became subject to explicit high-volume authentication requirements:

  • SPF must pass for the sending domain;
  • DKIM must pass;
  • DMARC must be present with at least p=none and align with SPF or DKIM.

Microsoft recommends p=reject once a domain is ready to enforce it. Non-compliant high-volume messages may be rejected with:

550 5.7.515 Access denied, sending domain [SendingDomain]
does not meet the required authentication level.

The Postmaster policy page and Microsoft’s announcement contain slightly different descriptions of the enforcement progression. The SMTP response from the actual delivery is the decisive evidence for a particular message.

SNDS and JMRP

Smart Network Data Services provides Outlook.com data for sending IP addresses that you control. Access requires a Microsoft account and authorization for the relevant IP space.

In July 2026 Microsoft replaced the previous SNDS site with the current portal. Automated-access URLs under the former sendersupport.olc.protection.outlook.com/snds/ path were deprecated, so existing integrations must use a link generated by the new portal.

SNDS no longer includes trap-hit counts in its Data Report. Microsoft removed them on 22 July 2026. Do not infer a precise trap count from transitional or historical values.

The Junk Mail Reporting Program is now managed within SNDS. JMRP returns the full message and headers when an Outlook.com user reports eligible mail as junk or phishing. Use those reports to suppress the reported recipient and to identify the responsible account, list or application. Microsoft says feedback can begin within about 72 hours after enrolment, but does not promise that every complaint will be returned.

What SNDS can and cannot establish

SNDS is evidence about traffic from an IP as Outlook.com sees it. It can help identify unusual behaviour, complaint patterns and reputation problems. It does not guarantee delivery, and a favourable view does not override a recipient rule, a malformed message or a specific SMTP rejection.

Shared IP space combines the behaviour of multiple streams. If you do not control the sending IP, the provider that does must investigate IP-level reputation and SNDS access.

Diagnose from the returned response

Microsoft publishes exact Outlook.com responses, including:

  • 421 RP-001, RP-002 and RP-003 for documented rate or connection limits;
  • 550 SC-001 for content or IP/domain reputation policy;
  • 550 SC-002 for namespace mining behaviour;
  • 550 SC-003 for an apparent open proxy or relay;
  • 550 SC-004 for an IP block associated with complaints;
  • 550 5.7.515 for high-volume authentication non-compliance.

Do not collapse these into a generic “Microsoft block”. Preserve the exact response and apply the condition-specific remedy.

For a temporary 421 response, allow the sending MTA to retry and reduce connections only where the response supports a rate or connection diagnosis. For a permanent 550, fix the documented condition before attempting a new delivery.

Forwarded mail

Forwarding can invalidate SPF because the forwarding host becomes the connecting IP. A surviving, aligned DKIM signature can still allow DMARC to pass.

SRS can rewrite the envelope sender so that SPF evaluates the forwarder’s domain. ARC can record authentication results across intermediaries. Neither mechanism compels Outlook.com to trust a forwarded message, and neither should be enabled as a generic fix without understanding the forwarding path.

Asking Microsoft to review a case

Microsoft directs urgent Outlook.com delivery problems to its sender-support route. Escalate only after checking the published requirements and correcting the observed failure.

Include the sending IP, EHLO name, domains, complete SMTP response, UTC timestamp and a representative Message-ID. State the verified change made. Do not describe SNDS as green or quote trap counts as proof that delivery must be allowed.

Primary references

Reviewed against these sources on 27 August 2026.