550 5.7.515: Sending Domain Doesn't Meet the Required Authentication Level (Outlook.com)

550 5.7.515 means Outlook.com rejected your message because the domain in your From address didn't meet Microsoft's authentication requirements for high-volume senders. To get through, mail from that domain has to pass SPF, pass DKIM, and pass DMARC with at least one of them aligned to the From domain. Fix the authentication on whatever service sent the bounced mail and the rejections stop.

The bounce reads:

550 5.7.515 Access denied, sending domain example.com does not meet
the required authentication level.

You'll sometimes see it written as 550; 5.7.515 depending on how your ESP formats bounces. Same error.

What it means

In April 2025 Microsoft announced new requirements for domains sending high volumes to its consumer mailboxes (Outlook.com, Hotmail.com and Live.com), with enforcement starting May 5, 2025. The original plan was to send non-compliant mail to Junk first. Before enforcement began, Microsoft updated the announcement and said it would reject that mail instead. 5.7.515 is that rejection.

Microsoft's support article defines a high-volume sender as one sending 5,000 or more messages to its consumer services from the same From domain (the announcement put it as more than 5,000 a day). Once you're over that line, every message from the domain has to meet the requirements, not just the bulk mail.

The requirements, per Microsoft:

Note the first two rows. Microsoft asks for SPF and DKIM to pass, on top of DMARC. DMARC on its own only needs one of them. That difference is behind a lot of 5.7.515 bounces: a message can pass DMARC on SPF alone, get accepted at other providers, and still be refused by Outlook.com because there's no DKIM signature.

The error is about the domain in the visible From header (the 5322.From, in RFC terms), not the envelope sender your ESP uses for bounces.

Common causes

Most likely first:

1. No DKIM, or DKIM signed by someone else's domain. Many ESPs sign with their own domain by default (d=esp-mail.example) until you set up custom DKIM. That signature passes DKIM but isn't aligned with your From domain.
2. A sending service you forgot about. The marketing platform is set up correctly, but the CRM, help desk or billing system sending as your domain isn't. The bounces come from that one stream.
3. No DMARC record. Without a _dmarc TXT record, DMARC can't pass, no matter how good SPF and DKIM are.
4. Neither SPF nor DKIM aligns. SPF passes on the ESP's bounce domain and DKIM passes on the ESP's signing domain, so both "pass" but DMARC fails. Custom bounce (Return-Path) domains and custom DKIM fix this.
5. SPF broken by too many lookups. Once your record needs more than 10 DNS lookups, SPF returns a permanent error for everything. See SPF's 10-lookup limit.

How to fix it

1. Identify the stream. Look at which messages bounced: which platform sent them and which From domain they used. Often it's one system, not your whole program.
2. Check a real message's headers. Send a message from that system to an Outlook.com or Hotmail address and open the full headers. The Authentication-Results header shows spf=, dkim= and dmarc= results and the domains each was checked against. Paste it into the header analyzer if it's hard to read.
3. Set up DKIM on your domain. In the sending platform, enable custom DKIM (sometimes called domain authentication) and publish the CNAME or TXT records it gives you. Confirm the signature's d= matches your From domain or its parent domain.
4. Fix SPF. Make sure the platform's IPs or include: are in the SPF record of the Return-Path domain, and count your lookups with the SPF analyzer. Setting a custom Return-Path on your own domain gives you aligned SPF as a bonus.
5. Publish DMARC if you haven't. v=DMARC1; p=none; rua=mailto:dmarc@example.com meets Microsoft's minimum and gets you reports. The DMARC generator will build one. If you need the background, start with what DMARC is.
6. Repeat for every service that sends as your domain. Your DMARC aggregate reports list every source using your domain, which is the fastest way to find the ones you forgot.

There's no delisting form for 5.7.515. Microsoft checks each message as it arrives, so once your authentication is right, the next message gets through.

How to confirm it's fixed

Send a test from each fixed system to an Outlook.com address and check the headers again. You want spf=pass, dkim=pass and dmarc=pass all on the same message, with DKIM's header.d matching your From domain. Then watch your bounce logs for 5.7.515 over the next few sends. The email checker is a quick way to confirm the DNS side is in place.

If DMARC still fails after the changes, DMARC fail: why it fails and how to fix it walks through the alignment cases one by one.

How to keep it from coming back

• Treat "add a new sending tool" as a DNS change that needs DKIM and SPF set up before the first send.
• Read your DMARC aggregate reports at least monthly, so a new unauthenticated source shows up as a report line instead of a bounce.
• Watch your SPF lookup count every time you add an include:.
• Microsoft also recommends the basics alongside authentication: valid From and Reply-To addresses, a working unsubscribe link and regular list cleaning. They don't cause 5.7.515, but they decide where your accepted mail lands. Google and Yahoo have similar requirements, and fixing authentication once covers all three.

When to get help

If your headers show passes everywhere and Outlook.com still returns 5.7.515, or you can't work out which of a dozen sending services is failing, it's worth having someone look at your setup and DMARC data with you.

FAQ

Do I need p=reject or p=quarantine to avoid 5.7.515?

No. Microsoft's minimum is a DMARC record with p=none, as long as messages actually pass DMARC. Move to enforcement when your reports show all legitimate mail passing, not to satisfy this rule.

Why does Gmail accept the same message?

Providers check slightly different things. Microsoft's support article says both SPF and DKIM must pass on top of DMARC, which is stricter per message than DMARC alone. A message that passes DMARC on aligned SPF but carries no DKIM signature is the classic case that gets accepted elsewhere and bounces at Outlook.com.

Does 5.7.515 apply to Microsoft 365 business mailboxes?

Microsoft documents 5.7.515 for Outlook.com and its consumer domains. Microsoft 365 tenants have their own checks, such as 5.7.509, which means your domain failed DMARC and has a p=reject policy.

I send fewer than 5,000 messages. Do I need to worry?

The rule targets high-volume senders, but SPF, DKIM and DMARC are worth having at any volume. They're also what Gmail and Yahoo expect, and they make your mail easier to trust everywhere.