Outlook.com high-volume sender compliance
Outlook.com requirements for high-volume senders
Domains sending 5,000 or more messages to Microsoft consumer mailboxes must make both SPF and DKIM pass, publish DMARC and pass DMARC through an aligned authentication path. The check must use the identities from the actual message.
A high-volume sender needs to verify the domain before Outlook.com, Hotmail, Live or MSN rejects mail with an authentication error.
Outlook sender compliance SPF PASS DKIM PASS DMARC policy CONFIGURED DMARC alignment FAIL PTR / FCrDNS UNKNOWN
Scope: Outlook.com consumer mailboxes
Microsoft's high-volume rule applies when a domain sends 5,000 or more messages to Microsoft consumer email services using the same domain in the RFC 5322 visible From address. The documented receiver scope includes Outlook.com and related Hotmail, Live.com and MSN consumer mailboxes; it should not be presented as a universal Microsoft 365 tenant rule.
Required authentication and diagnostic contract
| Requirement | Evidence needed | Passing condition | Common false conclusion |
|---|---|---|---|
| SPF must pass | Actual sender IP, RFC 5321 MAIL FROM/Return-Path domain and receiver-reported SPF result. | The selected SPF path authorizes the IP and the receiver reports the message pass where headers are available. | Finding an SPF record at the visible From domain is not enough. |
| DKIM must pass | DKIM selector, signing domain, public key and message authentication result. | The message is signed and the signature passes; DNS should independently expose a usable key. | A published selector does not prove the message was signed correctly. |
| DMARC policy must exist | Visible RFC 5322 From domain and its effective DMARC policy. | A valid policy is published; p=none, quarantine and reject are acceptable policy values. | A stricter policy is not a substitute for fixing authentication alignment. |
| DMARC must pass | Visible From domain plus authenticated SPF and DKIM domains. | At least one passing authentication domain aligns with the RFC 5322 From domain. | Because both SPF and DKIM must pass, it is still possible for DMARC to fail when neither domain aligns. |
| High-volume scope | Daily volume to Microsoft consumer services and visible From domain. | User or operator confirms 5,000+ messages under the same From domain. | DNS cannot determine volume or recipient mix. |
| PTR / FCrDNS review | Actual public sender IP. | PTR exists and its hostname resolves back to the original IP. | This is valuable infrastructure evidence, but it is not one of Microsoft's documented SPF/DKIM/DMARC conditions for 550 5.7.515. |
Evidence the extended form should collect
- RFC 5322 From domain: the identity Microsoft uses for the high-volume domain and DMARC.
- RFC 5321 MAIL FROM / Return-Path domain: the identity SPF authenticates.
- Actual sender IP: required for SPF path evaluation and the separate PTR/FCrDNS review.
- DKIM selector and signing domain: needed to inspect the public key and alignment.
- Outlook-received headers or NDR: needed for Microsoft's reported SPF, DKIM and DMARC results and error code.
- Daily volume and recipient scope: confirmation that the 5,000-message consumer-mailbox threshold applies.
- Third-party sending services: identify each service that sends under the same visible From domain.
How the Outlook result should be presented
The result needs separate rows for SPF authentication, DKIM authentication, DMARC policy, SPF alignment, DKIM alignment and receiver-reported DMARC. Combining them into one green "DMARC record found" result hides the failure that produces many 550 5.7.515 rejections.
SPF PASS, not aligned
The sender IP is authorized for the Return-Path domain, but that domain does not align with the visible From domain. SPF passes while the SPF route cannot make DMARC pass.
DKIM PASS, aligned
The receiver reports a valid signature whose signing domain aligns with the visible From domain. This route can satisfy DMARC alignment.
DMARC CONFIGURED
A valid policy exists. Keep this separate from a message-level pass until alignment evidence is available.
PTR UNKNOWN
No sender IP was supplied, or a transient lookup prevented FCrDNS verification. Do not tie this unknown directly to 550 5.7.515.
Third-party senders need branded authentication
A CRM, support desk, newsletter platform or transactional provider may use its own Return-Path or DKIM domain by default. For Microsoft's requirement, configure the service so the actual messages pass both authentication methods and at least one authenticated domain aligns with your visible From domain. Verify each service independently; one working platform does not validate every stream under the domain.
Correct the failing evidence in order
- Use Outlook headers or the NDR to identify the real sender IP, Return-Path, DKIM signing domain and reported results.
- Make SPF pass for the sender IP and actual MAIL FROM domain without creating a second SPF record or dropping other legitimate services.
- Enable valid DKIM signing for the actual stream and publish the provider-issued key or CNAME at the exact selector owner.
- Publish a valid DMARC policy and make at least one passing authentication identity align with the visible From domain.
- Send a new message through the same service and verify receiver-reported SPF, DKIM and DMARC; DNS propagation alone is not final proof.
Test the actual Outlook sender path
Supply the From domain, Return-Path domain, sender IP, DKIM identity and representative Outlook evidence. The diagnostic should isolate authentication, alignment and infrastructure observations.
Frequently asked questions
Who is a high-volume sender for Outlook.com?
Microsoft applies the requirement when 5,000 or more messages are sent to its consumer email services using the same domain in the RFC 5322 From address.
Do both SPF and DKIM need to pass for Outlook high-volume mail?
Yes. Microsoft requires both SPF and DKIM checks to pass, a valid DMARC policy to be published, and DMARC to pass through at least one aligned authentication method.
Is PTR part of the Outlook 550 5.7.515 authentication rule?
Microsoft’s documented 550 5.7.515 high-volume authentication rule is specifically SPF, DKIM and DMARC. PTR is useful separate sending-infrastructure evidence and should not be mislabeled as the cause of that code without supporting evidence.
Related email diagnostics
Primary sources: Microsoft Support: Fix NDR error 550 5.7.515 in Outlook.com, Microsoft: Outlook's requirements for high-volume senders.