Microsoft 550 5.7.515: How to Fix Outlook.com Authentication Rejections

Enforcement

Introduction

Error 550 5.7.515 Access denied means Outlook.com rejected your message because the domain in the From address did not meet Microsoft's authentication requirements for high-volume senders. To fix it, make SPF and DKIM pass, publish a DMARC record (p=none is enough), and make sure SPF or DKIM aligns with the From domain.

This guide is the troubleshooting companion to our overview of Microsoft's Outlook sender requirements. It shows how to read the bounce and headers, find which check is failing, and fix it on Microsoft 365, Google Workspace, marketing platforms and on-premises relays. For the protocol background, start with the DMARC guide.

Key takeaways

• The bounce text is 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. It applies to Outlook.com, Hotmail.com and Live.com recipients.
• Microsoft requires SPF pass, DKIM pass, and DMARC of at least p=none that passes with SPF or DKIM aligned to the From domain.
• The Authentication-Results header of a test message to an Outlook.com mailbox tells you which of the four is failing.
• A common cause is a third-party sender that signs DKIM with its own domain or uses its own bounce domain, so nothing aligns.
• MSPs should search delivery logs for 5.7.515 across the portfolio and start with clients that send newsletters or transactional mail through an email service provider.

What does the 550 5.7.515 error mean?

It is a permanent rejection from Outlook.com's consumer service. Microsoft's support article for the error explains it as: "The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender." The message was not delivered or junked; it was refused during SMTP.

Microsoft's announcement on the Microsoft Defender for Office 365 blog gives the exact bounce text:

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

The support article shows the same code without the semicolon, with the domain in place of the placeholder. Either way, the domain named is the From domain to investigate.

Who receives this error?

The rules target high-volume senders to Microsoft's consumer mailboxes: outlook.com, hotmail.com and live.com. The blog post says: "For domains sending over 5,000 emails per day, Outlook will soon require compliance with SPF, DKIM, DMARC." The support article counts 5,000 or more messages to Microsoft consumer email services that use the same domain in the 5322.From address, so every platform sending as that domain adds to the total.

The post also states that "This applies to Outlook.com – our consumer service." Mail to Microsoft 365 business mailboxes is filtered by Exchange Online Protection under its own rules.

When did Microsoft start rejecting mail?

Microsoft published the requirements on Apr 02, 2025. The original plan was to route non-compliant mail to Junk. An "April 29th Update" replaced that: Microsoft wrote that "we have made a decision to reject messages that don't pass the required authentication requirements," taking effect "on May 5th as originally stated." So rejection, not junking, has been the enforcement action since enforcement began. The post also says the Safe Sender list "won't be honored", so asking recipients to add you as a safe sender does not help.

What exactly does Microsoft check?

Microsoft lists three authentication requirements, and the support article says all messages from a high-volume domain must meet them:

The alignment part is where most rejections come from. SPF can pass for an email service provider's bounce domain and DKIM can pass for the provider's own domain, yet DMARC still fails because neither matches your From domain. Why DMARC fails when SPF passes covers that case in detail, and DMARC alignment explained covers relaxed and strict modes.

Microsoft also recommends practices beyond authentication: a valid From or Reply-To address that can receive replies, a functional unsubscribe link, regular removal of invalid addresses, and accurate subject lines sent only to recipients who consented. It reserves the right to filter or block senders that ignore them.

Which part is failing? A fix path decision table

Send a test from the affected platform to an Outlook.com mailbox you control, or read the headers of a returned copy, and match the result. Microsoft's support article starts the same way: check the headers, then DNS, then third-party services.

How do I read the Authentication-Results header?

Look for three domains and three results. Microsoft Learn's DMARC configuration page gives this example of a failing message:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

SPF passed for bounces.adatum.com and DKIM passed for adatum.com, but the From domain is contoso.com. Neither aligns, so DMARC fails. This is the classic third-party sender pattern behind a 5.7.515 bounce. Paste a full header into the email header analyzer to see the three domains side by side, or follow the email header triage guide.

How do I fix 550 5.7.515 on each sending platform?

The fix depends on which system sends the rejected mail. Identify the platform from the bounce or the Received headers first.

Microsoft 365 tenant

1. SPF: the domain's record needs include:spf.protection.outlook.com. Microsoft's SPF guidance gives v=spf1 include:spf.protection.outlook.com -all for a domain that only sends from Microsoft 365.
2. DKIM: Microsoft Learn's DKIM page says that "no DKIM signing occurs for outbound mail from custom domains" until you configure it. Only *.onmicrosoft.com is signed automatically, which does not align with your custom domain. In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, publish the two CNAME records it shows, then enable signing.
3. CNAME format: new custom domains added since May 2025 use targets such as selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft; older domains use selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Copy the exact values from the portal or Get-DkimSigningConfig, because the old and new formats cannot coexist for the same selector.
4. DMARC: publish a record for the custom domain, and one for the *.onmicrosoft.com domain as Microsoft recommends.

A gateway in front of Microsoft 365 can break DKIM or SPF; see DMARC behind an email gateway. The full tenant rollout is in DMARC for Microsoft 365 clients.

Google Workspace

1. SPF: Google's documented record for a Workspace-only domain is v=spf1 include:_spf.google.com ~all.
2. DKIM: in the Admin console go to Menu > Apps > Google Workspace > Gmail > Authenticate email, generate a 2048-bit key with the default google selector, publish the TXT record, then click Start authentication. Google says it can take up to 48 hours to start working.
3. DMARC: publish _dmarc for the domain. Outbound Workspace mail normally aligns on both SPF and DKIM once the above is done.

Third-party email service provider or marketing platform

This is a frequent source of 5.7.515, because newsletters and transactional mail are what push a domain past the volume threshold. Microsoft's support article asks you to confirm that the service:

• uses your domain in the 5321.MailFrom (return-path) address;
• signs messages with DKIM using your domain;
• is included in your SPF record, by IP or include;
• makes DMARC validation use your domain.

In practice, complete the platform's domain authentication: publish the DKIM selector records it gives you, and set up a custom return-path or bounce subdomain (for example bounce.example.com) if it offers one. DKIM alignment alone is enough for DMARC, so prioritise it when a platform cannot use your return-path domain. Platform-specific walkthroughs: Mailchimp, SendGrid, and the general third-party sender approach.

On-premises server, application or SMTP relay

Line-of-business applications, CRMs and on-premises Exchange often send directly from their own IP address without DKIM.

• Add the IP to SPF with an ip4: mechanism, as in Microsoft's example v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all.
• Get the mail DKIM signed with your domain, either by configuring DKIM on the server or relay itself, or by routing the mail through a platform that signs for the domain. Confirm the result in a test header rather than assuming.
• Consider a subdomain for high-volume application mail, such as notify.example.com, with its own SPF, DKIM and DMARC records, so its reputation and configuration stay separate.

How do I verify the fix?

Verify by sending a fresh test from each affected platform to an Outlook.com mailbox and confirming that the Authentication-Results header shows SPF, DKIM and DMARC passing with an aligned domain. Check the DNS records first, because a test only proves the platform you sent from. A short checklist:

1. Check the records: SPF analyzer for lookups and syntax, DKIM validator for each selector, DMARC checker for the policy.
2. Send a test from each platform to an Outlook.com, Hotmail.com or Live.com mailbox you control.
3. Open the message source and confirm spf=pass, dkim=pass, dmarc=pass, with header.d or smtp.mailfrom matching header.from.
4. Watch DMARC aggregate reports for a few days. Microsoft's FAQ confirms Outlook sends aggregate (rua) reports to the address in your DMARC record, so failing sources from Outlook.com will show up there.
5. Ask the platform to retry or resend the bounced campaign only after the tests pass.

The fixes are DNS changes, so allow for TTLs and propagation before concluding a change did not work.

What should an MSP do across its client portfolio?

Treat 5.7.515 as a portfolio audit, not a ticket-by-ticket fix. Clients rarely know their volume to consumer mailboxes, and a business-to-consumer client crosses 5,000 a day much sooner than a business-to-business one.

1. Search for the code. Ask clients and check any logs you manage for 5.7.515 bounces. Each hit names a failing domain.
2. Find the volume senders. Use DMARC aggregate reports to see which domains send at scale and through which platforms. A multi-tenant platform such as DMARC AI for MSPs processes these rua reports per client domain.
3. Prioritise newsletters and ESPs. Marketing, ticketing, invoicing and e-commerce platforms are where alignment is most often missing.
4. Fix under change control. Record each SPF, DKIM and DMARC change with client approval, and keep SPF under the 10-lookup limit.
5. Explain it to the client in plain terms. Mail to Outlook.com customers is being refused because a platform sends as their domain without proving it. The fix is DNS, not a Microsoft support ticket.
6. Plan beyond p=none. Compliance stops the bounces; it does not stop spoofing. Microsoft's own FAQ describes moving from none to quarantine to reject once legitimate sources align, which matches the NCSC's email security guidance. Under RFC 9989 that path uses the policy steps themselves, not a percentage ramp.

How does this relate to Google and Yahoo's requirements?

The core is identical. Google's email sender guidelines require senders of more than 5,000 messages per day to Gmail accounts to set up SPF, DKIM and DMARC (policy can be none) with the From domain aligned to SPF or DKIM, effective February 1, 2024. Yahoo's sender best practices ask bulk senders for SPF and DKIM and a DMARC policy of at least p=none that passes, with the same alignment rule.

Google and Yahoo add one-click unsubscribe and a spam rate below 0.3%, which Microsoft lists only as a recommended practice. A domain fixed for Microsoft is usually most of the way to Google and Yahoo compliance, and the reverse is also true. See Google and Yahoo sender requirements for their details. If Gmail is bouncing the same mail, our guide to Gmail's 5.7.26 and related authentication codes shows which check each code points to. Yahoo's bounces work differently: many are reputation deferrals rather than authentication rejections, as explained in what Yahoo's TS and PH bounce codes mean.

Is 5.7.515 the same as a 550 5.7.1 DMARC rejection?

No. Microsoft Learn documents 550 5.7.1 as the rejection when Microsoft 365 receives a message that fails DMARC and the sender's domain publishes p=reject. That is the sender's own policy being enforced. A 5.7.515 bounce comes from Outlook.com's high-volume rules and can happen even when your DMARC policy is p=none.

Frequently asked questions

Does p=none fix the 550 5.7.515 error?

Only if DMARC also passes. Microsoft requires a DMARC record of at least p=none, but the message must pass DMARC through aligned SPF or DKIM. Publishing p=none while a platform signs with its own domain and uses its own bounce domain still produces the rejection.

Why do I get 5.7.515 when SPF and DKIM both pass?

Because DMARC needs alignment. SPF may pass for the provider's return-path domain and DKIM may pass for the provider's signing domain, while your From address uses your own domain. Configure the platform to sign DKIM with your domain, or use a custom return-path subdomain under your domain.

Can Microsoft support remove a 5.7.515 block?

The rejection is driven by authentication results, so the fix is in your DNS and sending platforms, not a delisting request. Microsoft also states that recipients' Safe Senders lists are not honoured for this enforcement. Once SPF, DKIM and aligned DMARC pass, new messages are evaluated on that basis.

Does 5.7.515 affect mail to Microsoft 365 business mailboxes?

No. Microsoft says the high-volume requirements apply to Outlook.com, its consumer service, covering outlook.com, hotmail.com and live.com addresses. Business tenants on Exchange Online Protection apply their own DMARC handling, which can reject failing mail with 550 5.7.1 when the sender publishes p=reject.

Related reading

• Microsoft Outlook sender requirements: the overview
• Why DMARC fails when SPF passes
• DMARC for Microsoft 365: an MSP implementation guide
• How to move from DMARC monitoring to enforcement safely