550 5.7.515 in Outlook: Why Email Bounces When DMARC Passes

Your bounce reports SPF=Pass and DMARC=Pass. Outlook still refuses the message with 550 5.7.515. If the same diagnostic shows DKIM=Fail, those results are not contradictory.

Outlook.com's authentication requirements for high-volume senders include:

• successful SPF;
• successful DKIM;
• DMARC.

Passing DMARC through SPF does not compensate for a failed DKIM check under these requirements. See(https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com)[Microsoft's 5.7.515 troubleshooting guidance](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com).

Read the Failure as a Complete Statement

 
The following supplied example uses a placeholder domain:

smtp;550 5.7.515 Access denied
sending domain example.com does not meet the required authentication level
The sender's domain in the 5322.From address does not meet requirements
Spf=Pass, Dkim=Fail, DMARC=Pass

Here, 5322.From means the visible From address.

The diagnostic tells you that:

• the required authentication level was not met;
• it does not say DMARC failed;
• SPF passed;
• DMARC passed;
• DKIM failed.

Provided these results describe the same evaluation, SPF supplied the aligned pass needed for DMARC. DKIM remains the failed requirement.

Investigate the signer and delivery route rather than weakening the DMARC policy.

Microsoft's published scope is its consumer services, including:

• Outlook.com;
• Hotmail;
• Live.com;
• MSN.

Its high-volume requirements concern domain-level sending, so count the applications using the same From domain rather than only the mailbox that produced this bounce.

Do not classify an incident by the Outlook desktop application: the receiving mail service matters. A valid p=none policy is permitted, but authentication must still pass. See(https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com)[Microsoft Support](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com).

Start With the Application That Sent the Rejected Message

 
Suppose an employee's ordinary email works, but invoices from the accounting system bounce. Testing another employee email repeats the healthy route. It says little about the accounting system.

Instead:

1. Open the failed delivery event in the application or email provider.
2. Record:

• the From address;
• outbound service;
• time;
• message identifier.

3. Compare a failed invoice with a newly generated invoice test, not a message composed in a different application.

If a gateway, relay, or forwarding service sits between the application and Microsoft, include it in the investigation.

Keep the original NDR: a later test is useful evidence, but it cannot reconstruct the receiver's earlier DNS cache or processing state.

If DKIM Failed, Verify Signing and the Published Key

 
Inspect a fresh message for a DKIM signature.

Record:

• the signing domain (d=);
• the selector (s=).

Those values identify the DNS name to check:

<selector >._domainkey.<signing-domain>

Then work through the sending service's configuration:

1. Confirm signing is enabled for the domain used by this application.
2. Compare the provider-generated DNS values with the published records.
3. Check the selector used on the actual message, including any recent key rotation.
4. Investigate gateways that add footers or alter signed content after the message leaves the signer.

For a Microsoft 365 sender, use the CNAME targets generated for your own tenant and domain, and complete the DKIM enablement step. Merely creating DNS entries is not the whole setup. See(https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)[Microsoft 365 DKIM configuration](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure).

For another ESP, use that ESP's domain-authentication settings. Do not copy Microsoft 365 signing records into a setup that sends through a different provider.

The(https://dmarkoff.com/tools/dkim-checker)[DMARKOFF DKIM Checker](https://dmarkoff.com/tools/dkim-checker) can inspect the public record for a given domain and selector. A successful lookup does not verify the cryptographic signature of the bounced message.
 
Run DKIM Check
 

If SPF Failed Instead, Inspect the Envelope Domain

 
A different NDR may show:

• SPF=Fail;
• DKIM=Pass;
• DMARC=Pass.

In that case, follow the SPF branch rather than making DKIM changes.

To investigate:

1. Identify the SMTP envelope sender.
2. Identify the actual outbound IP.
3. Check whether the sending system is authorized for that envelope domain.

A company may use Microsoft 365 for employee mail while an external platform sends campaigns from separate infrastructure.

Use one SPF policy per evaluated hostname, preserve legitimate senders, and check DNS lookup limits.

Adding an include to the wrong domain cannot fix the envelope domain evaluated by the receiver. See(https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)[Microsoft's SPF configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure).

Do Not Confuse 5.7.515 With 5.7.509

 
Microsoft documents 5.7.509 for a different condition:

DMARC verification failed and the sending domain has a reject policy.

In that case, investigate the lack of an aligned authentication pass.

By contrast:

• 5.7.515 concerns the required authentication level and can appear alongside a DMARC pass.
• 5.7.509 indicates that DMARC itself failed while the sending domain uses a reject policy.

That distinction changes what you repair. See the(https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online)[Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online).

Close the Incident With a New Test

 
After making the repair:

1. Send a small test through the repaired application to the affected provider.
2. Retain:

• the passing authentication results;
• delivery event;
• configuration change.

If the same error persists despite verified authentication, escalate with the complete diagnostic and exact sending details.

For recurring checks, use(https://dmarkoff.com/)[DMARKOFF](https://dmarkoff.com/) to review authentication by sending source.
 
Start 14-day Free Trial
 
Look beyond the overall DMARC pass rate: an independently failing SPF or DKIM path can matter to delivery even when the other method keeps DMARC green.