Fixing "550 5.7.515 Access denied" from Microsoft

Since 2025, Microsoft 365 and Outlook.com enforce sender authentication for high-volume senders and increasingly for everyone else. The bounce looks like this:

550 5.7.515 Access denied, sending domain example.com does not
pass DMARC verification and has no DMARC record

Despite the wording, the root cause is rarely DMARC alone. Microsoft is telling you that your domain failed the whole authentication triad: SPF that covers the sending server, a DKIM signature aligned with your From: domain, and a DMARC record tying them together.

Why it happens

The most common trigger is sending through a provider (a CRM, a newsletter tool, a printer/scanner relay) that was never authorized in your DNS. SPF then fails or is unaligned, there is no DKIM signature for your domain, and once DMARC cannot find an aligned pass, Microsoft refuses the message outright rather than spam-foldering it.

Diagnose it

Run your domain through the Microsoft compliance check below. It grades exactly the requirements Microsoft enforces — SPF presence and quality, DKIM keys, DMARC record, rDNS — and shows which item is failing. Also confirm the specific sending service is listed inside your SPF (open the SPF tool and expand the include tree).

Fix it

1. Add the sending service to SPF — its documentation names the include, e.g. v=spf1 include:spf.protection.outlook.com include:_spf.yourcrm.com ~all (one record only, stay under 10 lookups).

2. Turn on DKIM signing at every service that sends as your domain and publish the selector records they give you. For Microsoft 365 itself, enable DKIM in Defender → Email authentication and add the two selector1/selector2 CNAMEs.

3. Publish DMARC, starting in monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain. Once reports show aligned passes, move to p=quarantine, then p=reject.

Re-send a test after DNS propagates (minutes to an hour). The 5.7.515 rejections stop as soon as an aligned pass exists.