InboxRatio
Check your domain

Outlook sender requirements: Microsoft's rules for high-volume email

Last reviewed:

Microsoft was the last of the big three mailbox providers to put hard authentication requirements behind an enforcement date. Gmail and Yahoo moved in February 2024; Microsoft followed in 2025 with its "Strengthening the Email Ecosystem" announcement, and since May 5, 2025, Outlook.com has been enforcing SPF, DKIM and DMARC for high-volume senders. Every requirement and error code on this page comes from Microsoft's Outlook.com Postmaster documentation, fetched and re-verified on the date at the top of this page.

One framing question before the details, because it decides which rulebook applies to you: are you sending to Outlook.com consumer mailboxes or to Microsoft 365 business tenants? The requirements here — the postmaster policies, the 5,000-per-day rule, SNDS and JMRP — govern the consumer service. Microsoft 365 organizational mail runs through Exchange Online Protection, where each tenant's administrators set their own policies on top of Microsoft's defaults. A sender can be clean at Outlook.com and still be blocked by one company's tenant rules, and vice versa. This page covers the consumer side, which is where Microsoft publishes provider-level sender requirements.

Current sender requirements

Microsoft's postmaster policies draw the same line Google draws, at the same number: domains sending more than 5,000 emails per day to Outlook.com accounts must be fully compliant with SPF, DKIM and DMARC.

Enforcement is phased, and the phasing is explicit in the postmaster documentation:

  1. Since May 5, 2025 — non-compliant messages from high-volume senders are routed to the junk folder.
  2. Rejection phase — messages that remain non-compliant are rejected outright with 550 5.7.515 Access denied, sending domain does not meet the required authentication level.

Alongside the authentication mandate, the policies page sets requirements that apply to senders generally:

  • Email servers must have valid reverse DNS records — check yours with our reverse DNS checker.
  • Connections from dynamic IP space may not be accepted.
  • A sender must not open more than 500 simultaneous connections to Outlook.com inbound servers.
  • The unsubscribe mechanism must be clearly documented and easy for recipients to find and use.

The connection limit is a genuinely Microsoft-specific item — neither Gmail nor Yahoo publishes an equivalent number — and it occasionally bites senders whose delivery infrastructure fans out aggressively during large sends.

Authentication requirements

For domains over the 5,000-per-day line, Microsoft's postmaster policies specify all three protocols, each with a pass condition:

SPF must pass for the sending domain, and the DNS record should accurately list the IP addresses and hosts authorized to send for it. A stale SPF record that no longer covers your current sending service fails this test even though the record exists.

DKIM must pass, validating message integrity and authenticity. As with the other providers, a DKIM signature from a domain unrelated to yours satisfies the cryptography but not the alignment requirement below.

DMARC: at least p=none, aligned with SPF or DKIM. Microsoft's wording is direct — publish a DMARC policy of at least p=none, with p=reject recommended, and the policy must align with either SPF or DKIM. Note the recommendation: Microsoft is the only one of the three major providers whose sender documentation nudges toward p=reject rather than stopping at "publish something." If your domain has no record yet, our DMARC walkthrough covers the path from p=none monitoring to enforcement.

The practical failure mode is the same one Gmail senders hit: mail sent through a third-party platform that authenticates as the platform's own domain. SPF passes, DKIM passes, DMARC alignment fails — and after the junk-folder grace phase, that is a 550 5.7.515. You can verify all three protocols in one pass with our email authentication checker.

Reputation factors

Microsoft's filtering weighs IP reputation and domain reputation heavily, and its postmaster program is unusual in how much raw telemetry it hands back to senders — through two free programs that recur throughout the troubleshooting documentation:

SNDS (Smart Network Data Services) gives IP owners Microsoft's view of traffic from their address space: mail volume seen, complaint activity, spam-trap hits and filtering status per IP. If you control your sending IPs and are not enrolled, you are diagnosing Outlook placement blind.

JMRP (Junk Email Reporting Program) is Microsoft's feedback loop: when an Outlook.com user marks your message as junk, enrolled senders get the report back and can remove the complainer from their lists. Microsoft's own troubleshooting guidance for the complaint-driven block (550 SC-004) is to enroll in JMRP and act on the reports.

The error-code table below is itself a map of what Microsoft's reputation system punishes: complaint-driven blocks (SC-004), namespace mining — probing for valid addresses (SC-002), open proxies and relays (SC-003), dynamic-IP and compromised-host traffic (DY-001, DY-002), and listings that track Spamhaus data (OU-001). That last one means an Outlook block can originate outside Microsoft entirely — worth a pass through our blacklist checker whenever OU-series codes appear.

Unlike Gmail and Yahoo, Microsoft's postmaster pages do not publish a numeric complaint-rate ceiling. The threshold exists inside the filter; what Microsoft gives you instead is the instrumentation — SNDS and JMRP — to see complaints and act before the block arrives.

Unsubscribe requirements

Microsoft's policies page states the requirement in functional terms: the mechanism for unsubscribing — from individual lists or from all lists hosted by the sender — must be clearly documented and easy for recipients to find and use.

That is a functional standard rather than a header specification — Microsoft's postmaster pages are less prescriptive than Google's about the exact mechanics (RFC 8058 one-click); for the full list of hygiene expectations accompanying the 2025 enforcement, see Microsoft's high-volume sender announcement in the Sources below. In practice, a sender implementing one-click unsubscribe for Gmail and Yahoo compliance satisfies Microsoft's functional requirement with the same headers — there is no reason to build a weaker mechanism for Outlook. Honoring the unsubscribe promptly is also cheap insurance for the complaint-driven SC-004 block: a recipient who cannot find the exit uses the junk button instead.

Known error codes

Microsoft documents its rejection codes on the postmaster troubleshooting page. They come in two families: standard SMTP codes with Microsoft-specific suffixes (RP, SC, DY, OU), and the enhanced status code attached to the 2025 authentication mandate.

| Code | Meaning per Microsoft's documentation | |---|---| | 421 RP-001 | Sending IP has exceeded the rate limit allowed | | 421 RP-002 | Sending IP has exceeded the rate limit allowed on this connection | | 421 RP-003 | Sending IP has exceeded the connection limit allowed | | 550 5.7.515 | Access denied — sending domain (over 5,000/day) does not meet the required authentication level (SPF, DKIM, DMARC) | | 550 SC-001 | Mail rejected for policy reasons — spam characteristics or reputation | | 550 SC-002 | Sending IP has exhibited namespace mining behavior | | 550 SC-003 | Sending IP appears to be an open proxy or relay | | 550 SC-004 | Block placed against the IP due to user complaints | | 550 DY-001 | Mail from dynamic IP space is generally not accepted | | 550 DY-002 | Likely a compromised or virus-infected server or computer | | 550 OU-001 | Rejected for policy reasons — tied to Spamhaus listings; request removal there | | 550 OU-002 | Rejected — spam-like content or IP/domain reputation |

Reading the families: RP codes are throttling — reputation-scaled rate and connection limits, retryable once volume drops or reputation improves. SC codes are behavioral blocks where Microsoft believes it has seen abuse. DY codes are about where you send from, not what you send. OU codes lean on external reputation data. And 5.7.515 stands alone as the authentication-mandate rejection — the only one on the list you can clear entirely on your own, with three DNS records.

For persistent blocks, the troubleshooting page routes senders to Microsoft's sender-support mitigation process; SC-004 resolution runs through JMRP enrollment.

Recommended practices

Distilled from the postmaster policies, services and troubleshooting pages:

  • Enroll in SNDS and JMRP before problems start. Both are free, and both are backward-looking — data begins when you sign up, and the SC-004 remedy assumes you are already receiving complaint reports.
  • Aim for p=reject, not just p=none. Microsoft's own policy page recommends it. Move through p=quarantine once DMARC reports show legitimate mail aligning.
  • Keep connection concurrency well under 500 and let your MTA respect RP-series backoff instead of retrying into the throttle.
  • Send from static IPs with clean reverse DNS. Two of the twelve documented error codes exist purely for dynamic and unidentifiable address space.
  • Watch bounce behavior. Repeatedly sending to nonexistent Outlook.com addresses looks like namespace mining (SC-002) from Microsoft's side of the wire — suppress hard bounces on the first occurrence.
  • Check Spamhaus when OU codes appear — the delisting path for those blocks starts outside Microsoft.

Frequently asked questions

What changed for Outlook senders in May 2025?

Since May 5, 2025, Outlook.com enforces SPF, DKIM and DMARC for domains sending more than 5,000 emails per day. Non-compliant mail was first routed to junk folders; Microsoft's postmaster pages state non-compliant messages are then rejected with 550 5.7.515 until the DNS records are corrected.

Does Microsoft require a DMARC enforcement policy?

The minimum is p=none with alignment against SPF or DKIM — but Microsoft's policies page explicitly recommends p=reject, making it the most enforcement-leaning of the three major providers' recommendations.

What is error 550 5.7.515 and how do I fix it?

It is the rejection code for the high-volume authentication mandate: "Access denied, sending domain does not meet the required authentication level." The fix is DNS, not content: publish and verify SPF, DKIM and an aligned DMARC record for the From: domain, then confirm all three pass on a live send.

Do these rules apply to mail sent to Microsoft 365 companies?

Not directly. The postmaster requirements govern the Outlook.com consumer service. Microsoft 365 tenants filter through Exchange Online Protection with administrator-controlled policies. The authentication work transfers — aligned SPF, DKIM and DMARC help at both — but deliverability to a specific company can still be gated by that tenant's own rules.

What are SNDS and JMRP, and do I need both?

SNDS reports Microsoft's view of traffic from IPs you control — volumes, complaints, trap hits, filter status. JMRP sends you a report each time an Outlook.com user marks your mail as junk. They answer different questions (how does Microsoft see my IPs vs. who is complaining), and both are free, so senders with their own IPs should run both. Senders on a shared platform depend on the platform operator's enrollment.

Microsoft doesn't publish a complaint-rate threshold — what should I hold myself to?

Hold the line the other providers publish. Gmail and Yahoo both set 0.3% as the ceiling, and a complaint rate that keeps you safe there has never been documented to trigger Microsoft's SC-004 complaint block in our reading of the postmaster pages. The block exists; the number is Microsoft's secret; the safe play is staying under the industry's published ceilings.

Sources

All requirements above were verified against these Microsoft pages on the review date shown at the top of this page:

The whole Microsoft mandate reduces to three DNS records done properly. Before your next large send to Outlook.com addresses, run the sending domain through our email authentication checker and confirm SPF, DKIM and DMARC all pass with alignment — it is the difference between the inbox and 550 5.7.515.