Outlook.com 550 5.7.515 Access Denied (Authentication Level): Causes and Fixes

Outlook.com 550 5.7.515 means the From domain failed the Microsoft high-volume sender rules for Outlook.com, Hotmail and Live. What SPF, DKIM and DMARC must pass, how to find the failing check, and how to fix it.

Quick answer

Outlook.com returns this bounce when a message to a Microsoft consumer mailbox (Outlook.com, Hotmail, Live.com, MSN and so on) comes from a domain that doesn't meet Microsoft's authentication requirements for high-volume senders:

550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level.
The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender.

Once a domain sends 5,000 or more messages to Microsoft consumer mailboxes, Microsoft expects every message using that From domain to meet all three requirements:

SPF passes and DKIM passes. Microsoft's article says both checks must pass, not one or the other.
The domain has a DMARC record. v=DMARC1; p=none at _dmarc is enough.
The message passes DMARC: SPF or DKIM (at least one) aligns with the domain in the From address.

The quickest fix is usually to sign with DKIM using your own domain at every service that sends as you, and to make sure every one of those services is in your SPF record. Start with the Email Deliverability Checker to see SPF, DKIM, DMARC and MX for your domain in one pass.

What the bounce means

The rejection is about the domain in the 5322.From address, the From address people see (Microsoft also calls it the P2 sender). Microsoft's support article says the message was rejected because that domain didn't pass the authentication level required for senders of large volumes of email to Microsoft consumer email services.

Who counts as a high-volume sender: Microsoft's support article says you send 5,000 or more email messages to Microsoft consumer email services, and all of the messages use the same domain in the From address. Microsoft's announcement and the Outlook.com Postmaster site describe it as domains sending over 5,000 emails per day.
Timeline: Microsoft announced the requirements on 2 April 2025. Its 29 April 2025 update changed the plan from routing non-compliant mail to Junk to rejecting it with 550 5.7.515, from 5 May 2025. The Outlook.com Postmaster site's announcement still describes Junk first and rejection later, but if you got this bounce the message was rejected, not delivered to Junk.
Safe senders don't help: Microsoft's FAQ says the Safe Senders list won't be honored for this enforcement, so recipients can't work around it for you. The fix is in your DNS and sending setup.
Scope: the requirement and this bounce are for Microsoft's consumer mailboxes. Mail to Microsoft 365 business mailboxes goes through Microsoft 365's own checks; if those tenants junk or quarantine your mail, see Microsoft 365 compauth=fail.

The wording varies a little: Microsoft's announcement quotes does not meet, and bounces that admins have posted use doesn't meet. Bounces posted in the comments on Microsoft's announcement also end with a link to the support article and a results line such as Spf= Fail , Dkim= Pass , DMARC= Pass. If your bounce has that line, it tells you which check failed. Microsoft doesn't document the line, so don't rely on it always being there.

Microsoft's requirements

Requirement	What Microsoft asks for	Check it with
Volume	5,000 or more messages to Microsoft consumer mailboxes using the same From domain (over 5,000 a day in the announcement).	Your sending platform's reports
SPF	Must pass for the sending domain. The DNS record should accurately list authorized IP addresses and hosts, and the message must come from an authorized source for the 5321.MailFrom (envelope sender) domain.	SPF Record Checker
DKIM	Must pass. The message is DKIM signed, and to count for DMARC the signing domain aligns with the From domain.	DKIM Checker
DMARC record	Published at `_dmarc` with a valid policy: `p=none`, `p=quarantine` or `p=reject`. At least `p=none`.	DMARC Record Checker
DMARC pass (alignment)	SPF or DKIM aligns with the From domain; only one is required, and Microsoft prefers both.	Email Header Analyzer
Third-party senders	Each service sending for you uses your domain in the envelope sender, signs DKIM with your domain, is covered by your SPF record, and passes DMARC for your domain.	DMARC Report Analyzer

Microsoft also recommends good hygiene for large senders: a valid From or Reply-To address that reflects the true sending domain and can receive replies, a functional unsubscribe link, removing invalid addresses, and accurate subject lines and headers sent only to people who consented. Those are recommendations, not the authentication check behind 5.7.515, but Microsoft says it may filter or block senders that ignore them. The bulk sender requirements checklist compares Microsoft's rules with Gmail's and Yahoo's.

Why DMARC pass isn't enough

DMARC on its own needs only one aligned pass, SPF or DKIM. Microsoft's support article asks for more: both SPF and DKIM checks must pass, and DMARC must pass as well. So a message can pass DMARC through DKIM and still bounce with 5.7.515 because SPF failed, or pass DMARC through SPF and bounce because it wasn't DKIM signed or the signature broke. The common cases:

SPF fails, DKIM passes: the message went out through a server or service that isn't in the envelope sender domain's SPF record, or it was forwarded or relayed by another provider on the way, which changes the sending IP.
DKIM fails or is missing, SPF passes: the service doesn't sign at all, a gateway or footer changed the message after signing, or the key record is missing or wrong.
Both pass, DMARC fails: the service authenticates with its own domains (its bounce domain for SPF, its own d= for DKIM), so nothing aligns with your From domain.
No DMARC record: nothing at _dmarc.yourdomain, more than one record, or a record without a valid p= tag.

How to tell which check failed

Read the whole bounce. Note the domain in the 5.7.515 line and the results line if there is one. Check that the domain is the one you expected in From: an application, website form or device may be sending with a different From address than the one you checked.
Get a copy that was delivered. A rejected message never reaches the mailbox, so there are no headers to read for it. Send the same kind of message, through the same path, to a mailbox that accepts it (another provider, or a mailbox of your own), open its full headers, and paste them into the Email Header Analyzer. Microsoft's support article points you to the same three results: SPF, DKIM and DMARC.
Compare the domains. Microsoft's Authentication-Results format looks like this (example values from Microsoft Learn):
```
Authentication-Results: spf=pass (sender IP is 192.168.0.1) smtp.mailfrom=contoso.com;
  dkim=pass (signature was verified) header.d=contoso.com;
  dmarc=pass action=none header.from=contoso.com;
```
For 5.7.515 you need spf=pass, dkim=pass and dmarc=pass, with smtp.mailfrom or header.d (ideally both) in the same organizational domain as header.from. Other receivers word the header differently, so read the results rather than the layout.
Use your DMARC reports. Microsoft says Outlook.com sends DMARC aggregate (rua) reports to the addresses in your DMARC record (it has no plans to send forensic ruf reports). Load a few days of them into the DMARC Report Analyzer to see every IP sending as your domain, and which ones fail SPF or DKIM.

Fix 1: make SPF pass

Publish exactly one TXT record starting with v=spf1 at the envelope sender (Return-Path) domain, listing every server and service that sends for it, including the IP addresses or include values each third-party service tells you to add. Build it with the SPF Record Builder and check it with the SPF Record Checker.
Stay within 10 DNS lookups. Microsoft's FAQ warns that past 10 lookups your SPF check might fail; see how to fix SPF too many DNS lookups.
Microsoft 365 senders: follow SPF for Microsoft 365. Google Workspace senders: SPF, DKIM and DMARC for Google Workspace.
To let SPF count toward DMARC as well, set a custom return-path or bounce domain under your own domain at each sending service, so the envelope sender aligns with From.

Fix 2: sign with DKIM using your own domain

Turn on DKIM at every platform that sends as your domain, with d= set to your domain or a subdomain of it, so the signature both passes and aligns. Microsoft's checklist for third-party services is that they sign DKIM with your domain.
Microsoft 365 doesn't sign custom domains with an aligned key until you publish the selector CNAMEs and turn signing on; see DKIM for Microsoft 365. Separate mail systems can use their own selectors, which Microsoft's FAQ says is fine.
Check published selectors and key length with the DKIM Checker. If DKIM is set up but your test copy shows a failure, use the guide for the error you see: body hash did not verify, signature did not verify or no key for signature.

Fix 3: publish a DMARC record

Microsoft's example is a TXT record at host _dmarc with the value v=DMARC1; p=none. Adding an aggregate report address lets you see who sends as your domain:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Generate one with the DMARC Record Generator and confirm it with the DMARC Record Checker (one record, starts with v=DMARC1, has a valid p= tag), or query the TXT record with DNS Lookup. p=none meets the requirement but doesn't protect the domain from spoofing; Microsoft's FAQ calls p=reject the most effective policy once legitimate sources are aligned, and advises moving gradually from none to quarantine to reject. DMARC for Microsoft 365 walks through that rollout.

Fix 4: align third-party senders

Microsoft's support article lists what to check for each service that sends on your behalf (marketing, CRM, ticketing, invoicing):

the envelope sender (MAIL FROM) address uses your domain;
DKIM signs messages with your domain;
your domain's SPF record includes the IP addresses or include values the service requires;
DMARC is evaluated for your domain.

Microsoft's FAQ adds that you still need SPF, DKIM and DMARC in your own DNS when a vendor sends for you, because authentication is tied to your domain. Most services do this with a few CNAME or TXT records they give you for DKIM and a custom bounce domain. The DMARC fail with SPF pass guide covers relaxed vs strict alignment and third-party senders in detail.

Fix 5: forwarding, relays and From addresses you don't own

Forwarding and mailing lists: forwarding changes the sending IP, so SPF often fails, and Microsoft wants SPF to pass. Microsoft's FAQ says forwarding can break DMARC alignment and recommends ARC for forwarding and mailing lists, because ARC preserves the original authentication results. If you run the forwarder, rewrite the envelope sender to your own domain and cover the forwarding servers in its SPF record, don't change the body or signed headers so DKIM survives, and add ARC if your platform supports it.
Your own relays: if a smart host, scanner, on-premises server or application sends straight to the internet, make sure its IP is in SPF and that it (or the relay it goes through) signs DKIM with your domain.
A From domain you don't control: only the owner of a domain can publish its SPF, DKIM and DMARC records. If a website form, app or device sends with someone else's address in From (a free webmail address, for example), put your own domain in From and the other address in Reply-To.

Verify the fix

Run the domain through the Email Deliverability Checker, then check the individual records with the SPF Record Checker, DKIM Checker and DMARC Record Checker.
After a DNS change, confirm public resolvers see the new record with the DNS Propagation Checker before you resend.
Send a new message through each path that bounced and paste the headers of a delivered copy into the Email Header Analyzer. Look for spf=pass, dkim=pass and dmarc=pass, with your domain in header.d and ideally in smtp.mailfrom.
Watch a week of aggregate reports in the DMARC Report Analyzer: every legitimate source should pass SPF and DKIM, with at least one aligned.

FAQ

What does 550 5.7.515 Access denied mean?

Outlook.com rejected the message because the domain in the From address did not meet Microsoft's authentication requirements for high-volume senders to its consumer mailboxes (Outlook.com, Hotmail, Live.com, MSN). Microsoft expects SPF and DKIM to pass, a DMARC record of at least p=none, and a DMARC pass with SPF or DKIM aligned with the From domain.

Why do I get 5.7.515 when DMARC passes?

Microsoft asks for more than a DMARC pass. Its support article says both SPF and DKIM checks must pass, and the message must also pass DMARC. A message that passes DMARC through DKIM but fails SPF, for example after forwarding or from a server missing from SPF, can still be rejected.

Is a DMARC policy of p=none enough for Outlook.com?

Yes. Microsoft's example record is v=DMARC1; p=none, and its announcement asks for at least p=none, aligned with SPF or DKIM. Microsoft still calls p=reject the most effective protection once every legitimate source is aligned, and advises moving gradually from none to quarantine to reject.

Can the recipient add me to Safe Senders to stop 5.7.515?

No. Microsoft says the Safe Senders list will not be honored for the high-volume sender enforcement. The sending domain has to fix SPF, DKIM and DMARC.

How do I fix 5.7.515 for mail sent by a third-party service?

Set the service up to use your domain: a return-path or bounce address under your domain, DKIM signing with your domain, and its IP addresses or include value in your SPF record, so DMARC passes for your domain. Microsoft's support article lists these checks, and its FAQ says the records are still needed in your DNS when a vendor sends for you.

Outlook.com 550 5.7.515 Access Denied: What It Means and How to Fix It