Outlook now hard-rejects non-compliant bulk mail with 550 5.7.515, and Safe Senders cannot override it. Diagnosing the bounce and fixing the authentication behind it.
When Microsoft announced its Outlook sender requirements last spring, rejection was the promised second phase with no date attached. The date came and went: since late last year, non-compliant bulk mail to Outlook consumer domains is refused outright, and January's bounce logs across the industry are full of the code that proves it. This is the field guide to 550 5.7.515: what triggers it, what makes it unusual, and the repair sequence that clears it.
550 5.7.515 Access denied, sending domain [example.com] does not
meet the required authentication level. Ensure SPF, DKIM and DMARC
are correctly configured for your domain.What triggers it
The check is the announced triad, enforced: domains sending roughly 5,000 or more messages a day to outlook.com, hotmail.com, and live.com addresses must pass SPF, carry a validating DKIM signature, and publish DMARC at p=none minimum with the From: domain aligned to at least one passing mechanism. Fail the bar and the mail is refused at SMTP with a permanent 5xx, not foldered, not deferred. The rejection is per message and mechanical: fix the authentication and subsequent mail flows, with no reputation penalty box appended for the offense itself.
Diagnosing in the right order
From bounce to root cause
- 1
Confirm the scope from your own logs
Group the 5.7.515 bounces by sending stream and domain. All streams failing points at the domain layer (DMARC record, SPF record); one stream failing points at that stream's signing or envelope configuration.
- 2
Read a delivered specimen elsewhere
Send the failing stream to a Gmail account and read Authentication-Results. It will name the broken mechanism precisely: spf=permerror, dkim=fail with an identifier mismatch, or dmarc=fail on alignment.
- 3
Check the DMARC aggregate reports
Microsoft's reports show the same traffic with policy_evaluated results, confirming whether SPF, DKIM, or alignment is the gap across real volume rather than one test message.
- 4
Fix the named mechanism
The usual suspects, in frequency order: a stream signing with the ESP's domain instead of yours (alignment), an SPF record over the lookup limit (permerror), a missing DMARC record on a subdomain used in From:, and a DKIM key broken by DNS mangling.
- 5
Verify and resume
Confirm the fix in headers, then resume normal sending to Microsoft. Rejections stop as soon as messages pass; there is no waiting period to serve.
The cases that surprise people
Forwarded mail: a message that left you compliant can arrive at Outlook through a forwarder that broke SPF and DKIM, and enforcement does not care whose fault the path was. The residue is small and mitigated where forwarders seal with ARC, but a trickle of 5.7.515 on forwarded traffic is the new normal, the same accepted cost as DMARC enforcement itself. Subdomain campaigns: the 5,000-a-day assessment and the authentication check follow the sending identity, and a marketing subdomain that never got its own DKIM configured fails alone while the root sails on, which is exactly the isolation subdomain strategy promises, working as designed against you. And low-volume senders: below the threshold the same failures cost placement rather than delivery, so a clean bounce log is not evidence of clean authentication.
The larger pattern, closed
With Microsoft's rejection phase live, the arc that began with Gmail and Yahoo in February 2024 is complete at all three major consumer providers: announce, folder, reject. Unauthenticated bulk email to the mainstream inbox is no longer degraded; it is refused, everywhere that matters. The senders reading this with clean logs did the work in 2024 and 2025 and noticed nothing this winter, which was always the point. For everyone else, the fix is a day of DNS and configuration work that this publication's authentication archive documents end to end, and the bounce message itself tells you where to start.
Frequently Asked Questions
We got 5.7.515 on some messages but not others to the same recipient. Why?
Does p=none really satisfy the DMARC part?
Is there an exception process or mitigation contact?
Does this apply to Microsoft 365 business tenants?
Key Takeaways
- Microsoft now permanently rejects non-compliant bulk mail to consumer domains with 550 5.7.515
- The check runs before Safe Senders, so recipient allowlisting cannot override it
- Diagnosis is mechanical: headers at a non-Microsoft mailbox plus DMARC reports name the failing mechanism
- Alignment gaps, SPF permerrors, and unsigned subdomains are the common causes, and fixes clear rejections immediately
- The 2024 enforcement arc is now complete at all three major providers: unauthenticated bulk mail is refused, not filtered
Related articles
Half-Year Review: Email in the AI Inbox Era
Six months that rearranged the reading layer: Gemini in Gmail, Microsoft rejecting outright, DMARC finally a standard. What the first half of 2026 means for senders.
Backscatter: The Bounces You Never Sent
When spammers forge your domain as their envelope sender, the bounces come to you. What backscatter is, why it happens, and how to stop causing and receiving it.
DMARCbis Is Published: What RFC 9989 Changes
After eleven years, DMARC is a real standard: RFC 9989, 9990, and 9991 replace RFC 7489. What is different, what stays, and the short list of actions for senders.