What are the Microsoft Outlook sender requirements?

In April 2025, Microsoft announced its own sender requirements for the Outlook consumer mail service — the mailboxes behind outlook.com, hotmail.com, and live.com addresses. The rules deliberately mirror the Google and Yahoo requirements from February 2024: domains sending more than 5,000 emails per day must pass SPF, pass DKIM, and publish a DMARC record at p=none minimum that aligns with the From domain. Enforcement began on May 5, 2025 with junk-folder routing and escalated to outright rejection with the SMTP error 550 5.7.515. With Microsoft on board, all three major consumer mailbox providers now enforce the same authentication baseline — unauthenticated bulk email no longer reaches any mainstream inbox.

Who is affected

Microsoft applies the requirements to domains sending more than 5,000 emails per day to its consumer service: outlook.com, hotmail.com, and live.com addresses. This is the consumer side of Outlook — Microsoft 365 business mailboxes are filtered under separate tenant-level rules, though in practice they apply very similar authentication checks.

The threshold is domain-based. It does not matter whether you send from your own servers, through an ESP (SendGrid, Mailgun, Postmark, Amazon SES), or through a CRM — the sending domain in your From header is what gets measured and what gets blocked.

Below 5,000 messages a day the rules are not enforced as hard requirements, but Microsoft's own FAQ is explicit that all senders benefit from meeting them: the same checks feed reputation and spam filtering at every volume. Treat the threshold as where enforcement starts, not where good practice starts.

The core requirements

Microsoft requires three things for high-volume senders, all verifiable in DNS:

1. SPF must pass. Your domain's DNS record must accurately list the IP addresses and hosts authorized to send for it. Watch the 10-DNS-lookup limit — Microsoft's FAQ explicitly calls out that records with too many include statements fail with a permerror, which counts as not passing.
2. DKIM must pass. Every message needs a valid DKIM signature that validates the message's integrity and authenticity.
3. DMARC must be published at p=none or stronger, and the message must align with either SPF or DKIM — Microsoft says preferably both. Alignment means the From-header domain matches (or is a subdomain of) the domain that passed SPF or DKIM.

Note what this means in combination: publishing records is not enough. A message that carries a DKIM signature for sendgrid.net while the From header says yourbrand.com fails alignment and counts as non-compliant, exactly as it does at Gmail and Yahoo.

One Outlook-specific detail: Microsoft states that a recipient adding you to their Safe Senders list will not bypass the enforcement. There is no allowlist escape hatch — the domain must authenticate.

The enforcement timeline

The rollout evolved between announcement and enforcement, which caused some confusion at the time:

• April 2, 2025 — Microsoft announces the requirements on the Microsoft Defender for Office 365 blog and tells senders to update SPF, DKIM, and DMARC ahead of enforcement.
• Originally, Microsoft said it would start rejecting non-compliant messages on May 5, 2025 with the 550 5.7.515 error.
• Late April 2025 — Microsoft updates the post and softens the first phase: instead of rejecting immediately, non-compliant mail will be routed to the Junk folder first, "giving senders an opportunity to address any outstanding issues," with rejection to follow at a later date.
• May 5, 2025 — enforcement begins. Messages from high-volume non-compliant domains start landing in Junk.
• Through the rest of 2025 — Microsoft tightens enforcement from junk-folder routing to rejection. Industry trackers reported gradual rejections ramping up from September 2025, with enforcement fully in effect by early 2026.

The practical takeaway in 2026: the grace period is over. A non-compliant high-volume domain does not get a junk-folder warning shot anymore — it gets bounces.

The 550 5.7.515 rejection

When Outlook rejects a message under these rules, the SMTP response is:

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

The error names the sending domain, which makes diagnosis straightforward: that domain is failing at least one of the three requirements. Check them in order — SPF first (does the record exist, is it syntactically valid, is it under 10 lookups, does it include your actual sending infrastructure?), then DKIM (is the message signed, does the d= domain match your From domain?), then DMARC (is a record published, does at least one of SPF or DKIM align?). Fix the failing layer, wait for DNS propagation, and the bounces stop.

If you see 550 5.7.515 only on a subset of mail, the usual culprit is one sending source that was never configured for custom-domain DKIM — a CRM, a ticketing system, or a marketing platform still signing with its own domain.

Hygiene requirements beyond authentication

Like Google and Yahoo, Microsoft pairs the hard authentication requirements with mailing-hygiene requirements, and reserves the right to filter or block senders for "critical breaches" of them:

• Compliant P2 (primary) sender addresses. The From or Reply-To address must be valid, must reflect the true sending domain, and must be able to receive replies. No-reply addresses on dead domains are out.
• Functional unsubscribe links. Recipients need an easy, clearly visible way to opt out, particularly for marketing and bulk mail. Note the difference from Gmail and Yahoo: Microsoft requires a functional unsubscribe, not specifically the RFC 8058 one-click mechanism. In practice you should implement one-click anyway — you need it for Gmail and Yahoo at the same volume.
• List hygiene and bounce management. Remove invalid addresses regularly to keep complaints, bounces, and wasted sends down.
• Transparent mailing practices. Accurate subject lines, no deceptive headers, and recipients who actually consented to receive your mail.

Microsoft does not publish a numeric spam-complaint threshold the way Google does (0.3% in Postmaster Tools). It monitors sender reputation through SNDS (Smart Network Data Services) at sendersupport.olc.protection.outlook.com — register there if you send meaningful volume to Microsoft addresses, and keep complaints as low as you can.

How it compares to the Google and Yahoo rules

The three programs are deliberately aligned, which is good news: one fix satisfies all three.

• Volume threshold: 5,000+ messages/day at all three providers.
• Authentication: SPF, DKIM, and DMARC at p=none minimum with alignment everywhere. Microsoft asks for both SPF and DKIM to pass; Google/Yahoo formally require one aligned method (but expect both in practice).
• Unsubscribe: Google and Yahoo mandate RFC 8058 one-click unsubscribe; Microsoft requires a functional unsubscribe link.
• Spam-rate threshold: Gmail publishes 0.3% in Postmaster Tools; Microsoft publishes no number and monitors via SNDS.
• Reject codes: Gmail bounces with 550 5.7.26 and variants; Outlook with 550 5.7.515.

If you already brought a domain into compliance for the February 2024 rules, you are nearly done for Outlook — verify that both SPF and DKIM actually pass (Microsoft asks for both, not just one) and that your DMARC record aligns. The full background on the Google/Yahoo side is in What are the Google and Yahoo sender requirements?

Forwarding, mailing lists, and ARC

Forwarding rewrites the SMTP envelope and breaks SPF, which is why Microsoft's FAQ recommends ARC (Authenticated Received Chain) for forwarding services and mailing lists: ARC preserves the original authentication results so legitimate forwarded mail is not wrongly flagged. As a sender, the resilient configuration is an aligned DKIM signature — DKIM survives forwarding, SPF does not.

Microsoft also participates in DMARC reporting: it sends aggregate (rua) reports to the addresses in your DMARC record, so you can see how your mail authenticates at Outlook specifically. It has no plans to send forensic (ruf) reports.

How to check compliance

You can verify every hard requirement from the outside, because they all live in DNS and in the SMTP transaction:

• Run the sender requirements checker for a single-scan compliance view: SPF validity and lookup count, DKIM selectors, DMARC policy and alignment, plus the supporting infrastructure checks.
• Check each record individually with the SPF checker, DKIM checker, and DMARC checker.
• Send a real message through the email deliverability test to see exactly how SPF, DKIM, and DMARC evaluate on live mail — including alignment, which a DNS-only check cannot fully prove.
• For automation, the same check is available as a free JSON API: https://intodns.ai/api/email/sender-requirements?domain=yourdomain.com — no signup or API key required.

A compliance checklist

1. Publish SPF with only the includes you actually use, under 10 DNS lookups.
2. Configure DKIM at every sending source with your own domain as d=. Use 2048-bit keys.
3. Publish DMARC at p=none minimum with rua= reporting, and verify alignment passes for every legitimate source.
4. Make the From/Reply-To address real and able to receive replies.
5. Implement unsubscribe — one-click (RFC 8058) covers Microsoft's "functional" requirement and Gmail/Yahoo's stricter one simultaneously.
6. Register in SNDS for Microsoft visibility, plus Google Postmaster Tools and Yahoo's sender portal.
7. Clean your lists regularly and watch bounce rates.
8. Once aggregate reports are clean, move DMARC toward p=quarantine and then p=reject — Microsoft's own FAQ recommends exactly this gradual path.

When to use IntoDNS.ai

IntoDNS.ai audits a domain against the Microsoft, Google, and Yahoo bulk-sender requirements in one scan: SPF record validity and lookup count, DKIM selector presence and key strength, DMARC policy and alignment mode, plus MX, TLS, and reverse-DNS posture. If your mail is bouncing with 550 5.7.515, it tells you which of the three authentication layers is failing and gives you the exact DNS record to fix it.