Troubleshooting Office 365 DKIM and SPF email authentication failures
Updated on 18 Oct 2026: We clarified Microsoft 365 SPF and DKIM troubleshooting, DMARC domain matching, and forwarding failures.
When Office 365 shows DKIM fail and SPF softfail, use the headers to identify the failing hop before changing DNS. SPF softfail means the IP Microsoft evaluated was not authorised by the envelope sender domain's SPF record under a ~all policy, while DKIM fail means the signature did not verify against the published key and signed content. When both happen together, common causes include forwarding, a relay or gateway changing the message, missing Microsoft 365 DNS records, or a gateway IP being evaluated because Enhanced Filtering for Connectors is not configured.
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, investigate the receiving path first; a different result alone does not rule out DNS caching or intermittent lookup failures.
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 SPF and DKIM failures mean
Office 365 and Microsoft 365 receive mail through several protection and routing layers. The IP in a later Received header is not necessarily the connecting IP recorded in Authentication-Results. A DKIM signature can also 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 distinctions matter when a header shows both SPF and DKIM trouble.
|
|
|
|---|---|---|
SPF softfail | Evaluated IP is outside a ~all policy | Verify the mail path |
SPF fail | Evaluated IP is outside a -all policy | Verify the mail path and authorised senders |
SPF none | No SPF record was found for the tested domain | Check the envelope sender domain in DNS |
SPF permerror | Invalid record or too many lookups | Check duplicate records and lookup count |
SPF temperror | Temporary DNS lookup failure | Check authoritative DNS |
DKIM none | No DKIM signature was found | Check signing on external delivery |
DKIM fail | Key mismatch or changed signed content | Check selector and body hash |
SPF and DKIM fail | Missing DNS or altered relay path | Trace every hop |
DMARC fail | No passing method matches the From domain | Fix the domain match |
Fast mapping between header symptoms and the first fix to test.
Separate four situations. A pure SPF issue has a missing sender IP or include. A pure DKIM issue has incorrect CNAME records, selectors, or signing status. A forwarding issue changes the connecting IP and breaks SPF. A message modification issue changes signed content and breaks DKIM.
Microsoft Defender DKIM settings with selector CNAME records and signing status
Read the headers before changing DNS
Use the Authentication-Results header added by the receiving Microsoft 365 system, together with the Received headers for that boundary. An earlier internal result or a header supplied by an untrusted sender is not proof of the final check. Microsoft records the SPF domain and evaluated IP, the DKIM signing domain, the DMARC result, and its compauth value. Read the selector from s= in DKIM-Signature when Authentication-Results omits it. For outbound tests, inspect a fresh message delivered to an external recipient. A compauth failure does not by itself block a message because Microsoft combines it with other filtering signals.
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 had a valid DKIM signature before the forwarder changed signed content, the fix belongs 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 its reference.
- DKIM identity: Check header.d and s= in DKIM-Signature; the public-key query uses <selector>._domainkey.<signing-domain>.
- Microsoft result: Check compauth and its reason code, then confirm whether explicit DMARC passed or failed.
- Trace evidence: Use Microsoft 365 message trace to connect the header to a connector, relay hop, or NDR.
For a controlled test, send a fresh message to the email tester and compare its receiving authentication results with the Office 365 result. A difference identifies paths to investigate; compare the actual signatures and evaluated IPs before deciding which system failed.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
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, 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 ~all. Microsoft recommends -all once all legitimate sources are authorised; an unauthorised IP then returns fail. Changing ~all to -all does not fix a missing sender.
SPF record for an Exchange Online-only sending domaindns
contoso.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all"
The example is for the commercial Microsoft 365 cloud and assumes Exchange Online is the only sender. Hybrid servers and applications that send directly need their authorised public IPv4 or IPv6 addresses, or their service's documented include, in the same SPF record. Subdomains do not inherit the parent domain's SPF record.
SPF checks that matter
- One record: Publish one SPF TXT record per domain, because duplicates cause permerror.
- Lookup count: Count lookup-causing terms across nested includes, not just the includes in the top-level record. SPF permits at most ten during evaluation; ip4, ip6 and all do not use that budget.
- Actual IP: Test the IP Microsoft evaluated, then decide whether it is a sender or a gateway.
- DNS result: Treat softfail, permerror, and temperror separately because they have different causes.
Use the SPF checker to confirm the record exists, parses cleanly, and stays within 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 (SRS) can make SPF pass by rewriting the envelope sender, but it does not repair DKIM. An SRS SPF pass usually uses the forwarder's domain, which does not match the original visible From domain for DMARC. When those domains differ, a surviving DKIM signature must meet the From domain's DMARC matching rule, or DMARC still fails; trusted ARC can inform Microsoft's handling without repairing that signature. Fix connector handling or message modification where the evidence points.
SPF lookup budget
The 0-7 and 8-10 bands are operational headroom suggestions. The SPF limit is ten evaluated lookup-causing terms, including nested includes, not ten DNS packets.
Healthy
0-7 lookups
Room for a controlled sender change.
Tight
8-10 lookups
Audit includes before adding a sender.
Broken
11+ lookups
Evaluating an eleventh lookup-causing term returns 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 values, Microsoft cannot sign with your custom domain. If the records are correct and DKIM still fails, compare the public key, selector, and signed content before rotating keys.
Current Microsoft 365 DKIM CNAME patterndns
Host: selector1._domainkey Type: CNAME Target: selector1-contoso-com._domainkey.contoso.<partition>-v1.dkim.mail.microsoft Host: selector2._domainkey Type: CNAME Target: selector2-contoso-com._domainkey.contoso.<partition>-v1.dkim.mail.microsoft
The pattern above illustrates Microsoft's format for new custom domains introduced in May 2025. The partition character is assigned per domain and cannot be guessed. Existing domains can still use legacy targets under the tenant's onmicrosoft.com domain. Retrieve the exact Selector1CNAME and Selector2CNAME values in the Defender portal or with Get-DkimSigningConfig, then publish both CNAME records exactly as Microsoft supplies them.
Inspect DKIM configuration in Exchange Online PowerShellpowershell
Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Run the command above in a connected Exchange Online PowerShell session. After publishing both CNAME records, enable signing in Microsoft Defender under Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Confirm Enabled is True and Status is Valid. If Status is CnameMissing, check the correct DNS zone and whether the DNS provider appends your domain to the host name automatically. Allow cached answers to expire according to the previous TTL, then retest. Use the DKIM checker to verify selector DNS before testing live mail, because a missing selector, a key mismatch, 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 target does not match the value supplied for the tenant and domain.
- 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.
- Signed headers: An intermediary changes a signed header, such as Subject or From.
Encoding failures are real. DKIM can pass for a plain ASCII test and fail when a downstream system changes the signed bytes through character conversion, HTML entity conversion, or line wrapping. Accented characters are not themselves a DKIM error. A larger key does not fix content rewriting. Stop the downstream system from rewriting signed content, or DKIM-sign after the final modification step with a domain that meets the visible From domain's DMARC matching rule.
Fix gateway and forwarding failures
Enhanced Filtering for Connectors and trusted ARC solve different parts of a gateway failure. Use Enhanced Filtering when inbound mail reaches Microsoft 365 through a non-Microsoft gateway or on-premises server and Microsoft would otherwise check SPF against that gateway IP. Use trusted ARC when an intermediary changes a message but preserves its earlier authentication results in a valid ARC chain.
Enhanced Filtering
- Use it when the MX path sends inbound mail through a gateway before Exchange Online.
- Configure the inbound connector to skip only the verified gateway IPs in that path.
- Retest headers to confirm Microsoft evaluates the original external sender IP.
- Do not add a gateway IP to an outside sender's SPF record or guess relay-pool IPs.
Trusted ARC
- Use it when a known intermediary changes signed content before Microsoft 365 receives it.
- Trust only a verified ARC sealer that is part of the controlled mail path.
- Validate the ARC chain and preserved result in the delivered message headers.
- ARC does not repair incorrect sender DNS or make a broken DKIM signature valid again.
NDR 5.7.367 and the relay pool
If a forwarded message uses a sender outside the tenant's accepted domains and neither SPF nor DKIM for the sender's domain passes on ingress, Exchange Online can use its relay pool. Those IPs are absent from Microsoft's published SPF ranges. Check message trace for OutboundIpPoolName set to RegularRelayOutboundPool. Correct authentication on ingress, configure Enhanced Filtering for the gateway, or reduce unnecessary relay hops. If you control the sender's domain, verify its accepted-domain configuration. Adding relay-pool IPs to SPF is not the fix.
Fix DMARC failures when SPF or DKIM passes
SPF and DKIM passing individually does not guarantee a DMARC pass. At least one passing method must also use a domain that matches the visible From domain under the published DMARC matching mode.
|
|
|
|---|---|---|
SPF pass | smtp.mailfrom, the envelope sender or Return-Path domain | A third-party service uses its own bounce domain |
DKIM pass | header.d, the d= domain in DKIM-Signature | Microsoft signs with tenant.onmicrosoft.com instead of contoso.com |
Compare authenticated identities with the visible From domain.
Relaxed matching is the default for both aspf and adkim: bounce.contoso.com and contoso.com share an organisational domain. Strict matching (aspf=s or adkim=s) requires an exact domain match for that method. tenant.onmicrosoft.com does not match contoso.com under either mode.
Enable custom-domain DKIM for the domain used in From, or configure a third-party sender to use an appropriate custom MAIL FROM domain. Adding an SPF include alone does not change these identities. Check the matching rules in Microsoft's DMARC guidance.
Where DMARC monitoring fits
DMARC makes recurring failures visible at scale. A single message header records one delivery path. DMARC aggregate reports show evaluated source IPs and SPF and DKIM outcomes over time; use raw headers and message trace to establish the actual gateway or forwarding route. Suped's DMARC reporting and email authentication platform groups these results so a team can investigate each sending source and verify the fix.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
A practical workflow in Suped is to open the failing source, compare its SPF and DKIM results with the visible From domain, check the DNS or routing change against a message sample, then watch the pass rate after deployment.
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
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, compauth, and its reason code.
- Trace: Use message trace and Received headers to map connectors, gateways, forwarding, and relay hops.
- Verify SPF: Confirm the evaluated IP belongs in the SPF record, or classify it as a forwarder or gateway.
- Verify DKIM: Confirm selector DNS, signing status, public key, and whether signed content changed.
- Fix path: Remove body rewriting, sign after modification, configure Enhanced Filtering, or trust a verified ARC sealer.
- Monitor: Watch DMARC reports for the same source until authentication passes consistently.
Microsoft's troubleshooting notes distinguish SPF softfail caused by an unapproved sending IP from DKIM body-hash failure caused by 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 a fresh message passes DKIM at other receivers, fails consistently at Microsoft 365, and the evidence does not identify a sender DNS error or downstream modification. Include the full message source, message trace ID, UTC timestamp, sender, recipient, and selector. Identify the failing receiving boundary instead of assuming an internal Microsoft hop is the cause.
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.
Treating an SRS SPF pass as a DMARC pass ignores the required match to the From domain.
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.
Check DKIM canonicalization, then remove footer rewriting and encoding changes first.
Alert on new failing sources daily, because authentication failures get expensive fast.
Marketer view
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 view
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
