Why are emails intermittently failing SPF and DKIM authentication with new Microsoft standards?
Michael Ko
Co-founder & CEO, Suped
Published 10 Aug 2025
Updated 5 Jun 2026
9 min read
Summarize with
Yes, SPF and DKIM failures can look intermittent under Microsoft's newer sender authentication enforcement. The usual reason is that Microsoft is not evaluating the same delivery path every time. DNS lookup timing, nested SPF includes, forwarding, internal Microsoft routing, per-recipient handling, and DKIM message changes can differ between two messages that appear identical at the sender side.
The direct answer is this: a correct SPF include or a passing DKIM test does not prove that every Microsoft delivery attempt will pass. It proves that one path passed at one point in time. A bounce showing SPF=Fail or Dkim=Fail means Microsoft saw that result for that specific message, at that specific receiving hop. The fix is to stop treating the record as a static object and start tracing the message path, the DNS resolution tree, and the affected recipients.
The short answer
When Microsoft rejects a message with 5.7.515 and still shows DMARC as passing, I read the SPF or DKIM result as the clue, not the whole verdict. Microsoft has stricter sender checks, and a low-rate failure can still create synchronous bounces.
- SPF: A nested include, DNS timeout, lookup limit, or forwarding hop can make the same IP pass once and fail later.
- DKIM: A changed body, rewritten header, stale selector, or receiver-side verification issue can break one message while others pass.
- DMARC: A DMARC pass in the bounce does not cancel Microsoft's separate rejection decision.
What the Microsoft 5.7.515 bounce means
Microsoft's Microsoft authentication guidance explains that SPF, DKIM, DMARC, and ARC work together, and that Microsoft 365 also uses composite authentication. That matters because the SMTP rejection is not just a raw DNS parser result. It is Microsoft's decision after it has checked sender identity, sender domain, message headers, and other receiver-side signals.
The pattern has also appeared in a Microsoft Q&A thread where the bounce text calls out the 5322.From domain and then prints individual SPF, DKIM, and DMARC results. I do not treat that as random wording. It is a structured clue about the signal Microsoft disliked.
The important nuance is that SPF and DKIM themselves did not change. What changed is enforcement. Microsoft is more willing to reject mail that fails the authentication level it expects for the visible From domain, especially on Outlook.com and Microsoft-hosted recipients. That makes old edge cases visible as bounces instead of quiet junking or acceptance.
Common Microsoft bounce pattern
550 5.7.515 Access denied sending domain example.com does not meet the required authentication level Spf= Fail , Dkim= Pass , DMARC= Pass
The confusing part is the combination. Many senders see SPF=Fail, Dkim=Pass, and DMARC=Pass, or the inverse with DKIM failing and SPF passing. That does not mean the bounce is impossible. It means Microsoft saw one authentication method fail, saw enough of DMARC to mark the domain match as passing, and still rejected under the sender requirements it applied to that mailbox or domain.
|
|
|
|---|---|---|
SPF fail | Source IP failed | SPF tree |
DKIM fail | Signature failed | Selector |
DMARC pass | Domain matched | Headers |
5.7.515 | Rejected by  Microsoft | Bounce |
Compact reading of common Microsoft authentication bounce combinations.
Why the same sender passes once and fails later
I start with the assumption that the message is not actually identical at the receiver side. The visible From address and sending IP can be the same, but the Microsoft ingress server, recipient mailbox path, forwarding state, DNS resolver answer, and DKIM-verifiable content can change. That is enough to make the failure feel random.
Sender-side causes
- DNS: A resolver can time out or return a stale nested include during the SPF lookup.
- Limit: An SPF tree can pass until one branch pushes the lookup count over ten.
- Forwarding: A recipient rule or gateway can relay the message and make SPF fail at the next hop.
- DKIM: A footer, encoding change, or header rewrite can invalidate one signed message.
Receiver-side causes
- Load path: Different Microsoft front-end or filtering nodes can process separate messages.
- Mailbox: One recipient can have forwarding or tenant rules that another recipient lacks.
- Timing: A short DNS outage can affect a tiny number of messages inside a large send.
- Policy: Microsoft can apply stricter treatment to some recipient domains or sender states.
This explains the classic symptom: one or two Microsoft bounces out of thousands, with the same sender accepted later by the same contact. If the rate is tiny, the sender authentication setup can still be healthy. The question is whether the failures cluster by recipient, by Microsoft region, by selector, by Return-Path, or by time window.
Flowchart showing where SPF or DKIM can fail before Microsoft accepts or rejects a message.
How to prove which cause applies
I do not start by editing DNS. I first collect evidence from a failed message and a successful message sent through the same production stream. A seed test helps, but a production test through the email tester is useful because it shows the actual headers, authentication results, and message structure that a receiver has to evaluate.
The evidence needs to be specific. A screenshot that says SPF passed is not enough. Capture the non-delivery report, SMTP code, Microsoft server name, sending IP, Return-Path domain, 5322.From domain, DKIM selector, and full Authentication-Results headers.
- Capture: Save the full bounce text, not just the final SPF or DKIM result.
- Compare: Put one failed message beside one passed message from the same sending pool.
- Trace SPF: Resolve every include and redirect until the sending IP match is proven.
- Check DKIM: Confirm the selector, public key, body hash, and signed headers for the failed mail.
- Segment: Separate failures by recipient domain, tenant, region, and time of send.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If every failed message shares one recipient domain or tenant, look for forwarding, tenant policy, or Microsoft-side handling. If failures hit the same sender across unrelated Microsoft recipients at the same time, look harder at DNS reliability, SPF lookup depth, and DKIM selector availability.
Microsoft Defender for Office 365 message trace showing SPF, DKIM, DMARC, and delivery status.
Check SPF beyond the visible include
SPF troubleshooting has to follow the whole resolution tree. Seeing the sending IP inside one include is only a starting point. The receiver still has to query DNS, follow each include or redirect, stay under the ten lookup limit, and reach the same result before the SMTP transaction ends.
A focused SPF checker helps find multiple SPF records, too many DNS lookups, missing includes, unsafe flattening, and records that pass for one branch but fail on another. I pay special attention to third-party includes because the sender does not control their uptime or DNS shape.
Short SPF example
example.com TXT "v=spf1 ip4:203.0.113.10 include:_spf.example -all"
A correct include is not enough
If the include path has intermittent DNS failures or lookup count pressure, Microsoft can receive a different answer than the one you saw during a manual check. Hosted SPF and SPF flattening reduce this risk when they are managed with monitoring rather than copied once and forgotten.
- Lookup: Stay under ten DNS lookups after every nested include is counted.
- Record: Publish one SPF TXT record at the domain that appears in Return-Path.
- Vendor: Monitor included senders because their DNS changes can affect your domain.
SPF risk bands
Operational bands I use when deciding how urgently to clean an SPF tree.
Low risk
0-5 lookups
One record, stable includes, and fewer than six DNS lookups.
Watch
6-8 lookups
Several third-party includes or a tree that changes often.
High risk
9-10 lookups
Near the SPF limit or dependent on unreliable nested DNS.
Check DKIM when Microsoft says DKIM failed
For DKIM failures, the first question is whether the message that Microsoft verified is byte-for-byte compatible with the DKIM signature. A test message can pass because no one modified it. A production message can fail because a footer, tracking layer, gateway, charset conversion, or header rewrite changed a signed part.
A DKIM checker is the fastest way to confirm that the selector exists, the key is valid, and the public DNS record is readable. After that, use the failed message headers to check which selector Microsoft tried to verify and whether the body hash matches the final message.
DKIM and DMARC DNS examples
s1._domainkey.example.com CNAME s1.example.dkim.example _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:d@example.com"
- Selector: Make sure the selector in the failed header exists in public DNS.
- Key: Use a current key length and remove stale selectors after rotation finishes.
- Body: Look for appended content or tracking rewrites after signing.
- Double sign: During migrations, use two DKIM signatures so one valid signature survives.
Use DMARC data to separate noise from a real fault
One clean test does not give enough coverage. DMARC aggregate data shows whether Microsoft is reporting isolated authentication failures, a specific source with a pattern, or a broader domain problem. Good DMARC monitoring also shows whether SPF and DKIM pass with the domain that users see in the From header.
This is where Suped's product fits the workflow. Suped brings together DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, issue detection, and blocklist (blacklist) monitoring in one place. For this specific Microsoft problem, the strongest practical use is tracking whether the failure is isolated, recurring, or tied to one sender.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
I use the issue view to separate verified sources from unverified sources, then compare Microsoft-reported results against other receivers. For MSPs and teams with many domains, Suped's multi-tenant dashboard matters because the same Microsoft symptom often appears as a few failures across several customers rather than one obvious outage.
What to group first
A practical order for grouping low-rate Microsoft authentication bounces.
Recipient domain
90Sending IP
80DKIM selector
70Time window
65What to fix first
If the bounce rate is tiny, I avoid emergency DNS edits unless the evidence points to a real fault. The safer order is to document the failure, prove the resolution path, remove obvious SPF and DKIM fragility, then monitor whether the Microsoft failures continue.
If the bounce rate is visible to users or concentrated in one Microsoft recipient domain, treat it as a delivery incident. That means preserving samples, escalating with complete headers, and temporarily routing critical mail through a path with known passing SPF and DKIM if your infrastructure allows it.
|
|
|
|---|---|---|
First | Save samples | Keeps proof |
Second | Trace SPF | Finds DNS risk |
Third | Verify DKIM | Finds key faults |
Fourth | Monitor DMARC | Shows pattern |
Fix order for intermittent Microsoft SPF and DKIM failures.
A practical fix sequence
- Fast win: Remove duplicate SPF records and stale DKIM selectors.
- Durable fix: Move fragile SPF management into a hosted workflow with change tracking.
- Proof: Use DMARC reports and bounces together, because either source alone is incomplete.
- Avoid: Do not weaken DMARC policy just because Microsoft printed one SPF or DKIM failure.
Views from the trenches
Best practices
Capture the bounce, recipient, sending IP, Return-Path, and full headers before changing DNS.
Compare passes and failures by recipient domain so forwarding patterns do not get hidden.
Keep both SPF and DKIM healthy because Microsoft can reject on either failed signal.
Common pitfalls
Checking only the visible SPF include misses DNS timeouts, lookup limits, and nested records.
Assuming DMARC pass cancels every Microsoft rejection leads teams to miss 5.7.515 detail.
Treating one clean seed test as proof hides failures that happen on a receiver path.
Expert tips
Review the SPF resolution trace and record which lookup branch Microsoft had to follow.
Double-sign DKIM during migrations so one valid signature survives routing changes cleanly.
Track low-rate Microsoft bounces separately so a small rate does not disappear in totals.
Expert from Email Geeks says intermittent Microsoft SPF failures often require the full SPF resolution trace, not a quick check of the top-level include.
2025-05-16 - Email Geeks
Expert from Email Geeks says a 5.7.515 rejection means Microsoft saw the failing state when it received that exact message.
2025-05-16 - Email Geeks
The practical answer
Intermittent Microsoft SPF and DKIM failures usually come down to path differences, not a mystical random failure. The record can be correct and still fail for a specific Microsoft receipt if DNS resolution, forwarding, receiver routing, or message mutation differs at that moment.
The clean way through is evidence first: collect bounces, compare passed and failed headers, trace SPF all the way down, verify the DKIM selector used by the failed mail, and monitor DMARC data over time. Suped's product is the best overall fit for this workflow when a team needs one place for DMARC monitoring, hosted SPF, hosted DMARC, MTA-STS, alerts, issue steps, MSP reporting, and reputation visibility.
