Outlook 550 5.7.515 "access denied": how to fix

If your email to Outlook.com, Hotmail, Live.com or MSN addresses comes back with this bounce, Microsoft has decided your domain doesn't meet its authentication rules for high-volume senders:

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

The rejection is about the domain in your From address, not about one message or one recipient. The fix is the same three DNS records that Gmail asks for, with one difference covered below.

Who this applies to

Microsoft's rules apply to domains that send more than 5,000 messages a day to Microsoft's consumer mailboxes (Outlook.com, Hotmail, Live.com, MSN). They took effect on 5 May 2025.

Microsoft first sends non-compliant mail from those domains to the Junk folder. If the problem isn't fixed, messages may be rejected with 5.7.515. Once your domain is over the threshold, the requirements apply to every message sent with that From domain, including the low-volume ones such as invoices and password resets.

What Microsoft requires

All three must be in place:

SPF passes. Your SPF record lists every server that sends for you.
DKIM passes. Messages are signed, and the public key is published in your DNS.
DMARC passes. A DMARC record is published (p=none is enough), and at least one of SPF or DKIM is aligned with the From domain.

The minimum DMARC record looks like this:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The difference from Gmail: for its higher tier, Google asks for SPF, DKIM and DMARC, but accepts DMARC passing through either SPF or DKIM. Microsoft's page says SPF and DKIM must both pass. A setup where DKIM passes but SPF fails, for example mail from a service that isn't in your SPF record, can satisfy DMARC and still fall short here.

Step 1: read the headers

Find a message from the affected stream that reached an Outlook.com mailbox (it may be in Junk), or send a test to one you control. Open the message headers and look at the authentication results:

Authentication-Results: spf=pass (sender IP is 203.0.113.10)
 smtp.mailfrom=example.com; dkim=pass (signature was verified)
 header.d=example.com; dmarc=pass action=none header.from=example.com;

Check three things:

spf= and dkim= both say pass.
smtp.mailfrom= (the Return-Path domain) or header.d= (the DKIM domain) matches the From domain, or is a subdomain of it.
dmarc=pass.

Step 2: fix what failed

SPF fails

Find the sending IP in the headers and the service it belongs to.
Add the service to your SPF record using the value from its setup guide.
Keep to one SPF record per domain, and stay within SPF's limit of 10 DNS lookups. See SPF "too many DNS lookups".

DKIM fails or is missing

Turn on DKIM signing in each service that sends as you: Microsoft 365, Google Workspace, your marketing platform, CRM, helpdesk, billing system.
Publish the DKIM records each one gives you.
Make sure each signs with your domain (header.d=example.com), not the service's own domain.

DMARC fails or there is no record

Publish the record above if you have none.
If DMARC fails while SPF and DKIM pass, the passes are for someone else's domain. Set the service to use your domain in the Return-Path (often called a "custom bounce domain" or "custom MAIL FROM"), and to sign DKIM with your domain.

Third-party senders

Microsoft's guidance is that any service sending for you should use your domain in the MAIL FROM address, sign with your DKIM key and be included in your SPF record. Check each service, not only your main mailbox provider.

Step 3: confirm and keep watching

Send a new test to an Outlook.com address and check the headers again. Then read your DMARC aggregate reports for a week or two. They list every source sending as your domain and whether it passed, which is how you find the forgotten tool that will trigger the next bounce.

When everything passes, p=none meets Microsoft's rule but still lets anyone spoof your domain. DMARC p=none to p=reject shows how to tighten it safely. If Gmail is bouncing your mail too, see Gmail 550 5.7.26. Bounced with 5.7.509 instead? That's DMARC p=reject: see 550 5.7.509.

Check your domain

The free scan checks your SPF, DKIM and DMARC records and shows what would fail at Outlook.com and Gmail. For single checks, use the DMARC checker and the SPF lookup counter.

Outlook 550 5.7.515 "access denied": fix SPF, DKIM and DMARC