Microsoft “550 5.7.515 Access denied, sending domain does not meet the required authentication level” — what it means and how to fix it

Emails you sent to outlook.com, hotmail.com, or live.com addresses are bouncing. The bounce contains the exact string 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Every affected recipient is a hard reject. The message was dropped, and resending won’t help until you fix what’s causing it.

Here’s what’s happening and how to fix it.

Decoding the error

Microsoft added bulk sender authentication enforcement for consumer mailboxes on May 5, 2025. In Microsoft’s own announcement, the company states it decided “to reject messages that don’t pass the required authentication requirements detailed above. The rejected messages will be designated as ‘550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.’” The same announcement describes a phased rollout: non-compliant mail first went to Junk, with rejection to follow at a later date. If you’re seeing the 550, rejection is live for your mail, and Junk-folder placement is no longer the worst case.

Per that same announcement, the requirements for domains sending 5,000+ messages a day to Microsoft consumer mailboxes are:

  1. SPF must pass: your sending IP must be authorized in your domain’s SPF record
  2. DKIM must pass: the message must carry a valid signature
  3. A DMARC record must exist, at least p=none. RFC 9989 §4.7 treats a record with no p tag as p=none; the minimum is a published DMARC record, and spelling out p=none removes any doubt.
  4. DMARC alignment: SPF or DKIM must align to the From: domain (RFC 9989 §3.2.10)

Who this affects, and who it does NOT

This is the most common confusion about this error.

Affected: senders of 5,000+ messages a day to consumer Microsoft mailboxes: @outlook.com, @hotmail.com, @live.com, and other personal Microsoft accounts.

Not affected: mail to Microsoft 365 business mailboxes on Exchange Online (person@example.com). Microsoft’s high-volume-sender enforcement targets its own consumer mail service.

What this means practically: a B2C product sending onboarding emails, password resets, or invoices to users who signed up with an @hotmail.com address will hit this wall. A B2B tool sending to corporate addresses typically won’t see this particular error from Microsoft’s side.

If your own team is getting bounces from @yourcompany.onmicrosoft.com addresses, this policy isn’t the cause. Look elsewhere.

Fix checklist

Step 1: Check your DMARC record

dig TXT _dmarc.example.com +short

A missing DMARC record alone causes the 550. Add a minimal record at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:your-rua-address@example.com

p=none satisfies Microsoft’s minimum. To move from monitoring to enforcement later, so unauthorized senders using your domain get rejected, the full process is in moving from DMARC p=none to p=reject without killing legitimate email.

Step 2: Check your SPF record

dig TXT example.com +short | grep "v=spf1"

Your sending service’s IP range must be included. Common includes for transactional and marketing platforms:

# Postmark
include:spf.mtasv.net

# SendGrid
include:sendgrid.net

# Amazon SES
include:amazonses.com

# Mailchimp / Mandrill
include:servers.mcsv.net

# Resend
include:_spf.resend.com

If you use several sending services, check that the total number of DNS lookup mechanisms stays under 10. RFC 7208 §4.6.4 requires a permerror above that limit, which counts as an SPF failure regardless of your record’s content. This post walks through what happens when you cross the limit and how to fix it.

Step 3: Verify DKIM is configured

Find your DKIM selector by inspecting an outbound message’s raw headers. In Gmail choose “Show original”; in Outlook choose “View > View message source.” Look for DKIM-Signature: ... s=<selector>. The s= value is your selector.

Then verify the key is published in DNS:

dig TXT <selector>._domainkey.example.com +short

Nothing back means DKIM isn’t configured at the DNS layer: either the key was never published, or you’re sending via a provider’s shared signing domain rather than your own. Enable DKIM signing for your custom domain in your provider’s dashboard; it’s a one-time setup that generates a TXT or CNAME record to publish.

Step 4: Confirm alignment

Alignment means the domain in your DKIM d= tag (RFC 6376 §3.5), or the domain in your SPF Return-Path, matches the domain in your From: header.

If you’re sending via a provider on its default shared sending domain (a sendgrid.net DKIM signature on mail sent From: you@example.com), alignment fails. Switch to custom domain sending so the DKIM signature carries your domain.

For a quick check, send a test message to a Gmail address and view “Show original.” The Authentication-Results: header shows dmarc=pass or dmarc=fail and which mechanism failed.

Not sure where your domain stands right now? A free domain checker can show your current DMARC record, SPF setup, and whether alignment is possible, without sending any mail.

Verifying the fix

After updating DNS:

  1. Send a test message to an @outlook.com or @hotmail.com address. Successful delivery means SPF, DKIM, and alignment all passed.
  2. Check Microsoft’s SNDS tool (Smart Network Data Services at sendersupport.olc.protection.outlook.com/snds/). After registering your sending IPs, it shows reputation signals from Microsoft’s side.
  3. Read your DMARC reports. Within 24 to 48 hours of your next sending window, aggregate reports show authentication pass rates by source IP. A clean report confirms the fix is holding.

Why now, if you already fixed Gmail

Microsoft’s May 2025 enforcement followed Google’s February 2024 requirements by about 15 months, and both now require the same baseline: SPF pass, DKIM pass, a DMARC record, and alignment on at least one mechanism.

If you fixed things for Gmail last year and assumed Microsoft was fine, it was, until May 2025. If you’re fixing Microsoft now, use the same session to double-check your Gmail compliance. See the Gmail 550 5.7.26 fix for the equivalent checklist against Google’s requirements. A domain that passes both is the same domain, configured the same way.

The next 550 wave won’t warn you. It’ll just stop your mail. DMARC Guardian reads your reports and flags failing senders as soon as they show up in the data, so you catch a broken provider before your outlook.com users do.

Check your domain’s DMARC, SPF, and alignment status free →