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 notification 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 on May 5, 2025. If your domain doesn’t meet the requirements, Microsoft returns this permanent 550 rejection — not a temporary deferral, not a soft bounce. The full error string in your bounce log typically looks like:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet
the required authentication level. For more information, please go to
https://aka.ms/BulkEmailErrorCodes 5.7.515.

The requirements Microsoft enforces:

  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 DKIM signature aligned to your From: domain
  3. A DMARC record must exist — at minimum p=none; enforcement policy is not yet required
  4. Alignment — SPF or DKIM must align to the From: domain

Who this affects — and who it does NOT

This is the confusion that generates the most support questions about this error.

Affected: Senders of 5,000 or more messages per day to consumer Microsoft mailboxes — @outlook.com, @hotmail.com, @live.com, and other personal Microsoft account addresses.

Not affected: Mail to Microsoft 365 business mailboxes — accounts like person@yourcompany.com that run on Exchange Online. This enforcement applies to consumer accounts only.

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 email addresses typically won’t see this error from Microsoft’s side.

If your own team is getting bounces from @yourcompany.onmicrosoft.com addresses, this policy is not the cause — look at something else.

Fix checklist

Step 1: Check your DMARC record

dig TXT _dmarc.yourdomain.com +short

A missing DMARC record alone causes the 550. The fix is to add a minimal record at _dmarc.yourdomain.com:

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

p=none satisfies Microsoft’s minimum requirement. If you want 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 yourdomain.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. Exceeding that limit causes SPF permerror — which also counts as a failure. 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.yourdomain.com +short

If nothing comes back, DKIM is not 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. Log into your email provider and enable DKIM signing for your custom domain — it’s a one-time setup that generates a TXT or CNAME record for you to publish.

Step 4: Confirm alignment

Alignment means the domain in your DKIM d= tag — or the domain in your SPF Return-Path — matches the domain in your From: header.

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

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

Not sure where your domain stands right now? The free domain checker shows your current DMARC record, SPF setup, and whether alignment is possible — without needing to send 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–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. Both major consumer mailbox providers now require the same baseline: SPF pass, DKIM pass, and a DMARC record.

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 as well. The requirements are nearly identical; 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 surfaces broken senders in your reports the moment they appear, so you catch a failing provider before your outlook.com users do.