550 5.7.515 Access Denied (Outlook.com)

Problem

Your mail to an outlook.com, hotmail.com, live.com, or msn.com address bounces with 550 5.7.515 Access denied, sending domain [yourdomain] does not meet the required authentication level. This isn’t a spam-score judgment, a blocklist, or a full mailbox. Microsoft is enforcing a hard rule: the domain in your visible From address has to authenticate itself with SPF, DKIM, and DMARC, and yours didn’t clear that bar. It bit you now, probably, because you crossed a volume threshold Microsoft watches — or because you always relied on a sending service whose authentication was never actually tied to your domain. The distinction that matters is passing versus aligning, and 5.7.515 is entirely about alignment.

Symptoms

• The bounce (NDR) reads 550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level, and the rejecting host is a Microsoft consumer mail server (*.outlook.com / *.hotmail.com).
• Delivery to Gmail, Yahoo, and your own corporate mail still works — only Outlook.com consumer addresses reject.
• It started around or after May 5, 2025, or right after your volume to Microsoft consumer mailboxes climbed past a few thousand messages a day.
• Mail sent through a third-party platform (marketing, CRM, transactional, help desk) is more likely to fail than mail sent directly from your own server.

What This Error Actually Means

On May 5, 2025, Microsoft began enforcing authentication requirements for high-volume senders to its consumer mailboxes — senders pushing more than 5,000 messages a day to Outlook.com. It follows the same playbook Google and Yahoo rolled out in February 2024. The requirement is three parts: publish SPF, publish DKIM, and publish DMARC (at least p=none), and the message must pass DMARC — meaning SPF or DKIM has to authenticate a domain that aligns with the domain in the 5322.From header (the address a human sees).

That word “aligns” is where nearly every 5.7.515 lives. SPF and DKIM can both pass on the sending infrastructure’s domain while telling Microsoft nothing about your domain. A marketing platform sends with its own return-path (SPF passes for the platform) and signs with its own DKIM key (DKIM passes for the platform). Two green checks, and yet DMARC — which only counts authentication that aligns with the From domain — sees nothing aligned. To Microsoft, the message is unauthenticated, and it returns 5.7.515. The rule isn’t “did some authentication pass.” It’s “did authentication for the domain in the From line pass.”

Top 3 Causes

1. The From domain has no aligned authentication - The single most common case. You send through a third-party service that passes SPF on its own bounce domain and signs DKIM with its own domain. Neither aligns with your From address, so DMARC has nothing to validate and Outlook.com rejects. The fix is branded authentication: a custom DKIM signature using your domain (usually a CNAME the vendor provides) and/or a custom return-path so SPF is evaluated against your domain.
2. No DMARC record at all - SPF and DKIM can be perfect, but if the From domain publishes no DMARC record, there’s no policy for Microsoft to evaluate alignment against, and a high-volume sender fails the requirement. A p=none record with aligned SPF or DKIM satisfies the rule; publishing DMARC is not optional at volume.
3. DKIM broken or missing on the path that actually sends - You authenticated your main mail flow but forgot a sender: an invoice platform, a notifications service, a subsidiary. That path signs with no key or a broken selector, DMARC fails for it specifically, and only mail from that source draws 5.7.515 while everything else delivers.

Diagnose with DechoNet

• Email Check reads the three records Microsoft is enforcing — SPF, DKIM, and DMARC — for your From domain in one pass, from the outside, the same way a receiving server does. It shows whether each record exists and is syntactically valid, whether DMARC is published, and whether your setup can even produce aligned authentication. If the domain has no DMARC record, or SPF/DKIM point only at a third party with nothing tied to your own domain, that’s your 5.7.515 in plain sight — before you file a ticket with Microsoft or your sending vendor.

Resolution Checklist

• Read the NDR for the exact From domain Microsoft named. The fix applies to that domain — the one in the visible From, not your server’s hostname or return-path.
• Confirm all three records exist for that domain: an SPF record, a DKIM key for the selector your mail actually signs with, and a DMARC record (p=none is enough to satisfy the requirement, though p=reject is the real goal).
• Fix alignment, not just passing. For every sending service, enable DKIM signing with your domain (the vendor’s branded-DKIM / CNAME setup) or a custom return-path so SPF authenticates your domain. At least one aligned identifier must pass DMARC.
• Inventory every source that sends as your domain — marketing, CRM, billing, transactional, support, that one script nobody documented — and verify each one produces aligned authentication. 5.7.515 often comes from the one sender you forgot.
• After changes, send a test to an Outlook.com address and read the Authentication-Results header in the received message: you want dmarc=pass with spf=pass or dkim=pass on your domain, not just any pass.

When to Escalate

• If your own domain publishes valid, aligned SPF/DKIM/DMARC and mail still bounces 5.7.515, take it to your sending platform: they may not be applying your branded authentication to the actual outbound messages, which is a configuration issue on their side.
• If only mail through one vendor fails while direct mail delivers, that vendor’s path isn’t aligned. Hand them the failing Authentication-Results and ask them to enable DKIM signing for your domain.
• If everything looks aligned and passing but Microsoft still rejects, use Microsoft’s sender support channels — but only after your Email Check shows the three records clean, so you’re not escalating a problem that’s actually in your own DNS.