Microsoft Outlook.com Sender Requirements

Microsoft brought its consumer mail service into line with Gmail and Yahoo on May 5, 2025, requiring high-volume senders to authenticate with SPF, DKIM, and aligned DMARC. The post was published April 2, 2025 and updated April 30, 2025, and that editing history matters: the page is internally contradictory about what actually happens to non-compliant mail. This page reports both states rather than guessing.

Scope, stated plainly by Microsoft:

“This applies to Outlook.com - our consumer service, which is supporting hotmail.com live.com and outlook.com consumer domain addresses.”

It does not cover Microsoft 365 / Exchange Online (enterprise). These are consumer-inbox rules.

The 60-second version

• Enforcement began May 5, 2025, targeting senders of 5,000+ emails/day.
• High-volume senders must pass SPF and DKIM, and publish DMARC at minimum p=none, aligned with SPF and/or DKIM (preferably both).
• The published post contradicts itself on the May 5 action: one paragraph says non-compliant mail is rejected (550 5.7.515), another says it is routed to Junk first with rejection “to be announced.”
• A functional unsubscribe is recommended, but RFC 8058 one-click is not mandated in this guidance.
• The safe-sender list will not be honored for this enforcement. SPF must stay within the 10 DNS lookup limit.

Who it targets: 5,000+/day

Microsoft draws the same numeric line as Google:

“For domains sending over 5,000 emails per day, Outlook will soon require compliance with SPF, DKIM, DMARC.”

“By focusing on senders of 5,000+ messages a day, we significantly reduce the likelihood of spam…”

And, like Google, it frames the line as an enforcement focus, not a free pass below it:

“While enforcement first targets large senders, all senders benefit from these best practices.”

The authentication requirements

Requirement	Microsoft’s rule
SPF	”Must Pass for the sending domain. Your domain’s DNS record should accurately list authorized IP addresses/hosts.”
DKIM	”Must Pass to validate email integrity and authenticity.”
DMARC	”At least p=none and align with either SPF or DKIM (preferably both).”

On alignment, Microsoft’s own FAQ phrasing:

“Alignment ensures the ‘From’ domain matches (or sub domain) the domain used by SPF and/or DKIM. This prevents bad actors from exploiting your domain name.”

And on going beyond the floor:

“Does publishing a strict DMARC policy (p=reject) offer better security? Absolutely, once your legitimate sources are aligned, p=reject is the most effective… We advise moving gradually (none → quarantine → reject) to avoid unintended mail loss.”

So the minimum is p=none, but Microsoft explicitly recommends climbing to p=reject once your sources are aligned.

The enforcement-state ambiguity (read this carefully)

The post was edited in layers and now contains two paragraphs that describe different actions for May 5. Both are present in the source; this is not a paraphrase choice.

Paragraph 1 (the April 29 update):

“After careful consideration… we have made a decision to reject messages that don’t pass the required authentication requirements… The rejected messages will be designated as ‘550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.’ This change will state taking effect on May 5th as originally stated.”

Paragraph 2 (earlier/original):

“After May 5th, 2025, Outlook will begin routing messages from high volume non-compliant domains to the Junk folder, giving senders an opportunity to address any outstanding issues. NOTE: that in the future (date to be announced), non-compliant messages will be rejected to further protect users.”

How to read it: the April 29 update appears to reverse the original “Junk first” stance, but the page never removed the older paragraph, so it reads both ways. The last-stated action for May 5 is routing to Junk, with a hard-reject date still “to be announced” as of this page’s last check (2026-06-21). The reject code, when rejection applies, is:

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

The only safe response to a contradictory enforcement notice is to be fully compliant, so neither the Junk path nor the reject path ever applies to you.

Hygiene recommendations (not hard requirements)

Microsoft lists these as best practice, separate from the SPF/DKIM/DMARC enforcement table:

• Valid, reply-able “From” or “Reply-To” addresses.
• Functional unsubscribe links for marketing / bulk mail.
• List hygiene and bounce management.
• Accurate subject lines, no deceptive headers, consent-based lists.

“Outlook reserves the right to take negative action, including filtering or blocking - against non-compliant senders, especially for critical breaches of authentication or hygiene.”

One-click unsubscribe

Unlike Gmail and Yahoo, Microsoft’s published guidance treats unsubscribe as a recommendation, not an enforced RFC 8058 mandate:

“Provide an easy, clearly visible way for recipients to opt out of further messages, particularly for marketing or bulk mail.”

There is no RFC 8058 one-click requirement stated in this post. Implement it anyway - it is mandatory at Gmail and Yahoo and harms nothing here.

ARC, safe-sender lists, and the SPF lookup limit

• ARC for forwarding: “Forwarding can break DMARC alignment. ARC preserves the original authentication checks, preventing legitimate forwarded mail from being wrongfully flagged.” Recommended for forwarding/mailing-list scenarios.
• Safe-sender list does not bypass enforcement: “Will adding to safe senders list bypass the new enforcement? No. Safe Sender list won’t be honored.” There is no list a recipient can add you to that skips authentication.
• SPF 10-lookup limit: “If you exceed 10 DNS lookups, your SPF check might fail. Tools exist to ‘flatten’ your record or reduce the number of includes.” A bloated SPF record with too many include: statements can fail the SPF “must pass” requirement on its own.

What this post does NOT cover (and what was omitted here)

To keep this page strictly sourced, several things commonly attached to “Microsoft sender requirements” are omitted because they are not verified in the post this page is built from:

• SNDS (Smart Network Data Services) and JMRP (Junk Mail Reporting Program): these are Microsoft’s long-standing consumer-mail tools, but this high-volume-sender post does not reference them. Their specifics are unconfirmed against this source, so no SNDS/JMRP feature claims are made here. The post does reference a general sender support portal at sendersupport.olc.protection.outlook.com.
• PTR / reverse DNS, TLS, and a spam-complaint-rate threshold: none are stated in this post as requirements. Gmail and Yahoo publish complaint-rate numbers; Microsoft’s high-volume guidance does not. “Not stated” is not “not checked,” but this page will not invent a number.

Common mistakes

• Reading only one of the two enforcement paragraphs. The page says both “reject” and “route to Junk.” Plan for rejection (550 5.7.515) and be compliant so it never fires.
• Stopping at p=none. Microsoft itself advises none → quarantine → reject once aligned.
• Trusting a safe-sender add to bypass the rules. It will not be honored for this enforcement.
• An SPF record over 10 DNS lookups. It can fail the “SPF must pass” requirement; flatten or trim includes.
• Assuming SNDS/JMRP enrollment satisfies the new rules. This post does not tie them to the authentication mandate.

What Egressif does

We authenticate Outlook.com-bound mail so the contradictory enforcement paths are moot: SPF that passes and stays well under the 10-lookup limit, DKIM that passes, and DMARC aligned with both - published at a real enforcement level rather than parked at p=none, following Microsoft’s own none → quarantine → reject advice. We add ARC on any forwarded mail so alignment survives the hop. On owned infrastructure we keep reply-able From/Reply-To addresses and a working one-click unsubscribe even though Microsoft only recommends it, because the same stream has to clear Gmail and Yahoo where it is mandatory. We do not claim SNDS/JMRP coverage we cannot source from this guidance, and we do not promise inbox placement - authentication is the entry condition, and Outlook’s filtering still weighs reputation and engagement.