Outlook.com returns 5.7.515 when mail from a high-volume sender does not meet Microsoft’s authentication requirements for consumer mailboxes. The requirement is explicit: SPF, DKIM and DMARC must all be in place and the visible From domain must align.
Most common causes
- SPF does not pass for the sending path
- DKIM is missing or does not pass
- A DMARC record is missing or validation does not pass
- The visible From identity is not aligned with the authentication path used for DMARC
What to verify next
- Inspect the NDR and message authentication headers
- Map sender infrastructure for the affected domain
- Verify both SPF and DKIM for high-volume Outlook.com sending
- Confirm DMARC publication and alignment with the visible From domain
What Microsoft requires above the volume threshold
Senders delivering more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses must pass SPF, DKIM and DMARC with at least p=none, and the From domain must align with the SPF or DKIM identity. Mail that fails is rejected with this code rather than routed to junk.
Volume is measured per sending domain across all platforms, so an organization splitting traffic between several tools can cross the threshold without any single tool appearing to send in bulk.
Alignment is the part most senders miss
SPF and DKIM can both pass on identities that belong to the sending platform — the platform’s bounce domain and the platform’s signing domain — and Microsoft will still reject because neither identity is the domain in the From field. That is a DMARC alignment failure, and the platform’s own dashboard will show green checks for it.
The fix is a custom bounce domain under your domain, custom DKIM signing with your domain in the d= tag, or both. Every major platform supports at least one.
- Both SPF and DKIM passing is not enough; one must align.
- Platform dashboards show authentication, not alignment.
- A DMARC record at p=none satisfies the publication requirement.
Confirm with a real header
Send a message through the affected platform to any mailbox you control and read Authentication-Results. If dmarc=fail appears with spf=pass and dkim=pass, alignment is the problem. If the DMARC record is missing entirely, publish one — even p=none with reporting is enough to satisfy the requirement.
After the change, verify propagation and send another test. Microsoft evaluates each message independently, so delivery resumes as soon as an aligned path exists.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The threshold and requirements are Microsoft’s and can change; the rejection text carries the current reference.
- Reputation-based filtering continues to apply after authentication is correct.
Common questions
We send under 5,000 a day. Why 5.7.515?
Volume is counted per domain across every platform and over Microsoft’s measurement window. Aggregate traffic may exceed the threshold even when each tool is small.
Does p=none count as having DMARC?
Yes. Microsoft requires a published DMARC record; monitoring mode satisfies that. Alignment is still required for the message to pass.
Is this the same as Exchange Online?
No. 5.7.515 is an Outlook.com consumer requirement. Exchange Online tenants apply their own policies and return different codes.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft: Fix NDR error 550 5.7.515.