Troubleshooting Office 365 DKIM and SPF email authentication failures
Michael Ko
Co-founder & CEO, Suped
Published 8 Aug 2025
Updated 4 Jun 2026
9 min read
Summarize with
When Office 365 shows DKIM fail and SPF softfail, I treat it first as a routing, forwarding, or message-change problem, then as a DNS problem. The direct answer is that SPF softfail means the IP Microsoft evaluated was not authorised by the envelope sender domain's SPF record, while DKIM fail means the signature could not be verified against the signed message. When both happen together, the usual causes are forwarding, a relay or gateway changing the message, missing Microsoft 365 DNS records, or Microsoft 365 evaluating a later hop instead of the original sending IP.
The fastest path is to save the raw headers, compare the Authentication-Results line across two recipients, verify the sending IP against SPF, then check whether DKIM passes before any footer, encoding, disclaimer, or forwarding step changes the message. If DKIM passes at another mailbox provider but fails only after Office 365 receives or forwards the message, I stop editing DNS and investigate the receiving path.
Immediate triage
Do not rotate DKIM keys or add random SPF includes until the headers prove which hop failed. Authentication failures get harder to debug after every DNS change.
- Headers: Copy the full message source from the affected message before changing anything.
- Recipient: Test one Office 365 recipient and one non-Microsoft recipient with the same message.
- Path: Look for forwarding, connectors, transport rules, disclaimers, and security gateways.
What the failure usually means
Office 365 and Microsoft 365 receive mail through several protection and routing layers. That means the IP shown in a later Received header is not always the IP that should be tested for SPF. It also means a DKIM signature can be valid when it leaves the sender, then fail after the message body changes. Microsoft documents SPF, DKIM, DMARC, ARC, and composite authentication in its Microsoft authentication guidance, and those details matter when a header shows both SPF and DKIM trouble.
|
|
|
|---|---|---|
SPF softfail | Relay IP not allowed | Fix SPF |
DKIM fail | Signature mismatch | Check body changes |
Both fail | Forwarded or altered | Trace hops |
DMARC fail | No matching pass | Fix SPF or DKIM |
Fast mapping between header symptoms and the first fix to test.
I separate four situations. First, a pure SPF issue where the sender IP or include is missing. Second, a pure DKIM issue where CNAME records, selectors, or signing status are wrong. Third, a forwarding issue where SPF breaks because the forwarder becomes the connecting IP. Fourth, a message modification issue where DKIM breaks because the signed body no longer matches.
Microsoft Defender portal DKIM configuration screen
Read the headers before changing DNS
The Authentication-Results header is the source of truth. Admin screens are useful, but the header tells you which domain was tested, which IP was tested, which DKIM selector was used, and whether Microsoft stamped compauth as pass, softpass, none, or fail. I always read the earliest trustworthy Received header and the final Authentication-Results header together.
Example failed Microsoft 365 authentication headertext
Authentication-Results: spf=softfail (sender IP is 203.0.113.25) smtp.mailfrom=contoso.com; dkim=fail header.d=contoso.com; dmarc=fail header.from=contoso.com; compauth=fail reason=001
That header does not prove the original sender was wrong. It proves Microsoft evaluated 203.0.113.25 for the envelope sender domain and could not verify the DKIM signature. If 203.0.113.25 belongs to a forwarder or gateway, SPF failed for a predictable reason. If the message also had a valid DKIM signature before the forwarder touched it, the right fix is in the forwarding or modification layer.
- Envelope sender: Check smtp.mailfrom, not only the visible From address in the message.
- Header domain: Check header.from because DMARC uses the visible From domain as the anchor.
- DKIM domain: Check header.d and the selector so you know which DNS record was queried.
- Microsoft result: Check compauth because Microsoft can score authentication beyond SPF and DKIM alone.
For a controlled test, I send a fresh message to the email tester and compare that clean result with the Office 365 recipient result. If the clean test passes and Office 365 fails, the break sits between those two paths.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Fix Office 365 SPF softfail
For mail sent directly through Exchange Online, the SPF record must authorise Microsoft's sending service. For most Office 365 tenants, that means the domain has one SPF TXT record that includes spf.protection.outlook.com. A softfail happens when the checked IP is outside the allowed sources and the policy ends in a softfail qualifier.
Basic Office 365 SPF recorddns
contoso.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com ~all"
SPF checks that matter
- One record: Publish one SPF TXT record per domain, because duplicates cause permerror.
- Lookup count: Keep SPF below the ten DNS lookup limit before adding another include.
- Actual IP: Test the IP that Microsoft evaluated, then decide whether it is a sender or a forwarder.
Use the SPF checker to confirm the record exists, parses cleanly, and stays under the lookup limit. If you need a broader view of DMARC, SPF, and DKIM together, run a domain health check before changing production DNS.
Forwarding is the common trap. SPF checks the connecting server, so a forwarded message often fails SPF even when the original sender published a correct record. Sender Rewriting Scheme can make SPF pass by rewriting the envelope sender, but it does not repair DKIM. If the visible From domain has no passing DKIM signature after forwarding, DMARC still fails. For Microsoft-only internal routing, I prefer fixing connector handling, ARC, or the message path instead of adding SRS as a blanket fix.
SPF lookup risk
Use lookup count as an early warning before Office 365 SPF softfail becomes permerror.
Healthy
0-7 lookups
Room for a controlled sender change.
Tight
8-9 lookups
Audit includes before adding a sender.
Broken
10+ lookups
SPF can return permerror.
Fix Office 365 DKIM failures
For Office 365 outbound mail, custom-domain DKIM needs two selector CNAME records and DKIM signing enabled for the domain. If those records are missing, stale, or pointed at the wrong tenant, Microsoft cannot sign with your domain. If the records are correct and DKIM still fails, the message was changed after signing or the receiving system queried the wrong selector.
Typical Microsoft 365 DKIM CNAME patterndns
Host: selector1._domainkey Type: CNAME Target: selector1-contoso-com._domainkey.contoso.onmicrosoft.com Host: selector2._domainkey Type: CNAME Target: selector2-contoso-com._domainkey.contoso.onmicrosoft.com
After publishing the CNAME records, confirm the selectors resolve and then enable signing in the Microsoft Defender portal. I use the DKIM checker to verify selector DNS before testing live mail, because a missing selector and a body-hash mismatch need different fixes.
DNS problem
- Selector: The selector in the header has no matching CNAME in DNS.
- Tenant: The CNAME points at the wrong onmicrosoft.com tenant.
- Signing: DKIM is not enabled for the custom domain.
Message-change problem
- Footer: A relay adds a disclaimer or tracking footer after signing.
- Encoding: Special characters are converted after the signature is created.
- Dot lines: Lines starting with a period expose old MTA body handling bugs.
Encoding failures are real. I have seen DKIM pass for a plain ASCII test and fail once accented characters, HTML entity conversion, or line wrapping gets introduced. The fix is not a bigger key. The fix is to stop the downstream system from rewriting the signed body, or to DKIM-sign after the final modification step with the same domain shown in the visible From address.
Where DMARC monitoring fits
DMARC is where this becomes visible at scale. A single message header tells you what happened once. DMARC reports tell you which Office 365 sources, forwarders, gateways, and third-party senders keep failing over time. For most teams, Suped is the best overall DMARC platform for this job because Suped's product turns aggregate reports, DNS state, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability signals into source-level issues with practical fix steps.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The workflow I want is simple: see the failing source, confirm whether SPF or DKIM is the actual problem, read the recommended DNS or routing fix, then verify that the pass rate improves. Suped's product also helps with hosted SPF, SPF flattening, hosted DMARC, hosted MTA-STS, real-time alerts, and MSP multi-tenancy when one team manages many domains.
A useful DMARC signal
If DKIM failures appear only after a specific relay or forwarding route, focus on that route. If they appear across all recipients, check selector DNS and signing status first.
A practical troubleshooting runbook
I use this sequence when Office 365 shows DKIM fail and SPF softfail together. It keeps the investigation tied to evidence instead of guessing at DNS.
- Collect: Save the raw header from the failed Office 365 message and a passing comparison message.
- Identify: Find smtp.mailfrom, header.from, header.d, selector, sender IP, and compauth.
- Verify SPF: Confirm the evaluated IP belongs in the SPF record, or classify it as a forwarder.
- Verify DKIM: Confirm selector DNS, signing status, and whether the body was changed after signing.
- Fix path: Remove body rewriting, sign after modification, or configure trusted relay handling.
- Monitor: Watch DMARC reports for the same source until authentication passes consistently.
Microsoft's troubleshooting notes make the same practical distinction: SPF softfail points at a missing or changed sending source, while DKIM body-hash failure points at modification after signing. If authentication passes but mail still lands in junk, treat that as a placement issue and use a separate Outlook deliverability guide rather than continuing to edit SPF or DKIM.
Flowchart for troubleshooting Office 365 SPF and DKIM failures
When to open a Microsoft ticket
Open a Microsoft ticket when the same DKIM signature verifies everywhere else, the message is not modified by your own relays, and only Office 365 reports failure against an internal Microsoft hop. Include the raw headers, message trace ID, timestamp, sender, recipient, and selector.
Views from the trenches
Best practices
Save raw headers before editing DNS so each SPF, DKIM, and DMARC result stays traceable.
Test a clean Microsoft 365 send and a forwarded send, then compare the signed body and sender IP.
Keep SPF records under the lookup limit before changing DMARC policy for production mail.
Common pitfalls
Treating every Office 365 internal hop as the SPF source sends troubleshooting off track.
Adding SRS without same-domain DKIM fixes SPF symptoms while DMARC still fails later.
Changing DKIM selectors before checking body modification hides the real failure point.
Expert tips
Compare headers at two recipients to separate Microsoft filtering from sender DNS mistakes.
Use relaxed DKIM canonicalization, then remove footer rewriting and encoding changes first.
Alert on new failing sources daily, because authentication failures get expensive fast.
Marketer from Email Geeks says DKIM passing at other receivers points away from sender DNS and toward the Office 365 receiving path.
2019-07-09 - Email Geeks
Marketer from Email Geeks says SPF softfail can happen when Microsoft evaluates a relay IP from the headers instead of the original sender.
2019-07-09 - Email Geeks
The practical fix
Office 365 DKIM and SPF failures are fixable when the investigation starts with headers. SPF softfail asks, "Why did this IP send for this envelope domain?" DKIM fail asks, "Why does this signed message no longer match the public key and body hash?" DMARC asks whether at least one of those passing results uses the same domain as the visible From address.
For a one-off incident, compare the raw headers, fix the sending path, and retest. For a domain with recurring failures, use Suped's product to monitor DMARC, SPF, DKIM, forwarding sources, hosted SPF, alerts, and blocklist (blacklist) signals in one place. That gives you the pattern, not only the broken message.
