550 5.7.515: Microsoft wants SPF, DKIM, and DMARC before it takes your mail

What the bounce means

A 550 5.7.515 rejection is Microsoft enforcing its sender-authentication requirement at the SMTP door. The bounce usually reads like this:

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

The message never reached a mailbox and never had a chance at the junk folder. Outlook checked the sending domain's SPF, DKIM, and DMARC posture during the delivery attempt, decided it does not meet the bar Microsoft announced for 2025, and refused the message outright.

The bar Microsoft is enforcing

In 2025 Microsoft joined Google and Yahoo in requiring authentication from high-volume senders to its consumer domains (outlook.com, hotmail.com, live.com). To pass, the sending domain needs all three:

• SPF: a published record, and the message's sending IP passing it.
• DKIM: messages signed with a key the domain publishes.
• DMARC: a published policy (at least p=none), with at least one of SPF or DKIM aligned to the visible From: domain.

The enforcement threshold Microsoft publishes is roughly 5,000 messages a day to consumer Outlook addresses, mirroring the Google and Yahoo mandates from February 2024. But treat the threshold as a detail: the same missing authentication that triggers 5.7.515 above the line degrades your placement below it.

Why your domain trips it

• No DMARC record at all. The most common case. Without even p=none published at _dmarc.yourdomain.com, the requirement cannot be met, whatever SPF and DKIM do.
• Authenticated, but not aligned. A sending service passes SPF or DKIM for its domain, not yours. If neither the envelope domain nor the DKIM d= matches your From: domain, the pass does not count.
• One mechanism broken at the source. A newsletter tool with SPF set up but DKIM never enabled, or a DKIM key that was rotated away without updating DNS, leaves the message resting on a single mechanism that then fails.
• A source you forgot. A billing system or CRM sending as your domain that was never added to SPF and never given a DKIM key. Your main mail passes; that one source bounces.

How to fix it

• Find which source sent the rejected mail. The bounce hits one sending path. Read the bounced message's Authentication-Results and Received headers, or check your DMARC aggregate reports for the source IP, before changing any records.
• Publish DMARC if you have none. Start with v=DMARC1; p=none; rua=mailto:... and a reporting address you read. p=none meets Microsoft's minimum while you fix alignment with real data.
• Make the failing source align. The durable path is aligned DKIM: have the service sign with d=yourdomain.com (usually a pair of CNAMEs it gives you) and publish the key. Aligned DKIM also survives forwarding, where SPF breaks.
• Or authorize it in SPF. Add the service's include to your SPF record if its envelope domain is yours. Watch the 10-lookup limit while you are in there.
• Do not chase the threshold. Splitting volume across subdomains or IPs to duck under 5,000 a day leaves the underlying authentication broken and your deliverability degraded everywhere else.

How to confirm it is fixed

• Re-check the records with a free DMARC audit and the SPF and DKIM checkers: published, resolving, and under the SPF lookup limit.
• Send a test to an outlook.com mailbox from the source that bounced, open the message headers, and confirm dmarc=pass with an aligned spf=pass or dkim=pass. Our header analyzer reads the result in plain English.
• Watch your DMARC reports. Within a day or two the fixed source should report as aligned from Microsoft's own receivers. If it still shows unaligned, the record published but the source is not using it.

Frequently asked

What does 550 5.7.515 mean?

Outlook and Microsoft 365 rejected your message because the sending domain does not meet Microsoft's authentication requirement: SPF, DKIM, and DMARC set up so at least one of SPF or DKIM aligns with the From: domain. It is a hard rejection at the door, not a spam-folder placement.

Does 5.7.515 only apply to bulk senders?

Microsoft's published enforcement threshold targets senders of roughly 5,000 or more messages a day to consumer Outlook domains, but the authentication bar itself is worth meeting at any volume. Smaller senders with missing or broken authentication see junk-folder placement and other rejections even when they stay under the bulk threshold.

I have SPF and DKIM records, so why did I still get 5.7.515?

Having the records is not the same as passing with alignment. If the service that sent the message authenticates with its own domain, and neither the SPF envelope domain nor the DKIM d= matches your From: domain, DMARC has nothing aligned to accept. Check which source sent the rejected mail and whether its SPF or DKIM aligns with your domain, not just whether records exist.

How long after fixing my records does 5.7.515 stop?

DNS changes propagate within minutes to hours depending on your record TTLs. Once the sending source passes SPF or DKIM aligned to your From: domain, new messages stop tripping the check immediately; there is no reputation cooldown for this specific code because it keys on authentication, not sending history.