Fix Microsoft 550 5.7.515 Access Denied (NDR Error)

Microsoft's requirements for avoiding 550 5.7.515

Microsoft's current 550 5.7.515 support guidance defines a high-volume sender as a domain sending 5,000 or more messages per day to its consumer email services, using the same domain in the visible 5322.From address. This page was last verified against that guidance on August 23, 2026.

This distinction matters: moving directly to p=reject does not repair SPF, DKIM, or alignment. Microsoft explicitly accepts a valid p=none record for this requirement; the rejected message still needs to authenticate and align.

Diagnose the rejected message first

Before changing DNS, preserve:

• The complete NDR text, including the sending domain Microsoft names.
• A header from the same sending platform and From address, if you can deliver a test message elsewhere.
• The 5322.From domain visible to the recipient.
• The Return-Path or 5321.MailFrom domain used for SPF.
• The DKIM d= signing domain and selector.
• The Authentication-Results values for SPF, DKIM, and DMARC.

From: Sender <sender@example.com>
Return-Path: <bounce@example.com>
DKIM signing domain (d=): example.com
DKIM selector (s=): selector1
Authentication-Results: spf=pass; dkim=pass; dmarc=pass header.from=example.com
Microsoft recipient: user@outlook.com
Sending platform: [name]
NDR timestamp (UTC): [timestamp]

A compliant result has both SPF and DKIM passing, with at least one of those authenticated domains aligned to the visible From domain so DMARC passes:

From: alerts@example.com
Return-Path: bounce@example.com
DKIM-Signature: d=example.com; s=selector1;
Authentication-Results: spf=pass smtp.mailfrom=example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

This result is authenticated but unaligned. SPF and DKIM pass for the provider's domain, yet DMARC fails for the visible From domain:

From: alerts@example.com
Return-Path: bounce@provider-mail.example
DKIM-Signature: d=provider-mail.example; s=selector1;
Authentication-Results: spf=pass smtp.mailfrom=provider-mail.example;
 dkim=pass header.d=provider-mail.example;
 dmarc=fail header.from=example.com

Follow the evidence in this order:

1. Analyze a representative header to compare the From, Return-Path, DKIM d=, and authentication results.
2. Retest the affected message stream through the same production platform and From domain.
3. Use the Email Security Score for the public DNS baseline only. A clean DNS scan cannot prove that the rejected message used those records correctly.

How to fix Microsoft 550 5.7.515

1. Confirm the scope

Check that the recipients are on Outlook.com, Hotmail, Live.com, or MSN and that the NDR contains 550 5.7.515. A different 550 5.7.x code can indicate a different policy or reputation problem and should not be diagnosed from this guide alone.

The threshold is based on messages sent to Microsoft's consumer services from the same 5322.From domain. If Microsoft returned this exact NDR, use the named domain and authentication results as the source of truth instead of trying to estimate volume first.

2. Make SPF pass for the real Return-Path

SPF checks whether the connecting source is authorized by the domain in the Return-Path. Verify that:

• The sending service's current IP address or documented include: is present in the SPF record.
• The domain publishes only one SPF record.
• The record stays within SPF's 10-DNS-query limit.
• The provider is using the Return-Path domain you expected.

An SPF pass does not automatically produce a DMARC pass. For SPF alignment, the Return-Path domain must align with the visible 5322.From domain.

3. Make DKIM pass for every high-volume stream

Microsoft requires DKIM to pass as well as SPF. For each platform sending as the affected domain:

1. Enable DKIM signing in that platform.
2. Publish the CNAME or TXT records supplied by the platform.
3. Send a new message after DNS has propagated.
4. Confirm the header reports dkim=pass.
5. Compare the DKIM d= domain with the visible From domain.

4. Publish a valid DMARC record and fix alignment

DMARC is published at _dmarc.example.com. A valid monitoring record can look like:

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

Check the record with the DMARC checker. For the rejected message to pass DMARC, at least one of these must be true:

• SPF alignment: the authenticated Return-Path domain aligns with the visible From domain.
• DKIM alignment: the passing DKIM d= domain aligns with the visible From domain.

5. Fix every third-party sender

High-volume domains commonly send through several systems: a marketing platform, transactional service, CRM, support desk, and Microsoft 365 or Google Workspace. Repairing one does not repair the others.

Build a simple inventory with the visible From address, Return-Path, DKIM d=, selector, and result for each service. Then follow that service's current custom-domain and DKIM instructions. Microsoft specifically calls out third-party senders because they often use a provider-owned Return-Path or signing domain until branded authentication is enabled.

6. Retest the same stream

After changing DNS or provider settings:

1. Wait for the relevant DNS TTL and provider activation state.
2. Send through the same platform and From domain that failed.
3. Inspect the new header.
4. Confirm both SPF and DKIM pass.
5. Confirm DMARC passes through SPF or DKIM alignment.
6. Send to a controlled Outlook.com mailbox and preserve the result.

What will not fix this error by itself

• Changing only p=none to p=reject.
• Publishing SPF without confirming the actual Return-Path.
• Publishing DKIM records without enabling signing in the sending platform.
• Getting spf=pass or dkim=pass for a provider-owned domain that does not align.
• Running only a DNS lookup and skipping a real message header.
• Retesting from a different service than the one Microsoft rejected.

Microsoft 550 5.7.515 versus other 550 errors

Do not confuse this error with 550 5.4.1 Recipient address rejected: Access denied. The 5.4.1 error with Microsoft's AS(201806281) diagnostic is normally a recipient-directory/DBEB problem. The 5.7.515 error explicitly names the sending domain's authentication level.

Use the 550 5.4.1 guide when the NDR says the recipient address was rejected.

Where Palisade helps, and where it does not

Palisade's free tools can inspect public SPF, DKIM, and DMARC records, and the email deliverability test can evaluate a message you send to its generated address. Palisade's monitored workflow can use aggregate DMARC evidence to help operators identify senders and prioritize alignment work.

These checks cannot reproduce Microsoft's private filtering decision or guarantee acceptance. The final verification is a fresh message through the affected stream to the receiving service.

Primary sources

• Microsoft Support: Fix NDR error 550 5.7.515 in Outlook.com
• Microsoft: Outlook's requirements for high-volume senders