Intermittent DKIM validation failures with Office365 usually mean the mail stream is inconsistent. Some messages are signed and verified, while other messages leave through a different path, use a stale selector, hit inconsistent DNS, or get modified after Microsoft 365 signs them. When the failure rate is close to 50%, I look at split DNS or mixed routing before I blame the DKIM key itself.
The important caveat is that dkim=none and dkim=fail are different problems. dkim=none means the receiver did not find a usable signature on the message. dkim=fail means there was a signature, but verification failed. I separate those two buckets first because the fixes are different.
Short answer
A DKIM record that contains an n= tag is not the reason Office365 DKIM validation fails intermittently. The n= tag is a note field. It is valid in a DKIM TXT record and is not used in cryptographic verification.
What intermittent DKIM failure means
DKIM is deterministic for a single unchanged message. The sender signs selected headers and the body hash with a private key. The receiver fetches the public key through DNS and checks whether the signature still matches the message it received. If the exact same signed message and exact same DNS answer reach the receiver every time, the result should not randomly change.
Intermittent failure means one of those inputs changes. In Office365 cases, I usually see one of these inputs change: the signing route, the selector lookup, the message body, the headers covered by the signature, or the receiver's DNS view.
Two common header patterns
dmarc=fail (p=none sp=none pct=100) action=none header.from=example.com; dkim=none; arc=none dkim=fail reason=signature-did-not-verify
|
|
|
|---|---|---|
dkim=none | No usable signature | Signing route |
dkim=fail | Signature mismatch | Rewrite path |
temperror | Lookup problem | DNS health |
pass | Valid signature | Compare path |
Use the receiver's Authentication-Results header before changing DNS.
Why Office365 fails only some of the time
The most useful diagnostic question is not "Is the DKIM record valid?" It is "What is different about the failed messages?" A public key can validate cleanly and still fail half the mail if only half the mail uses that key path.
- DNS split: Two authoritative nameservers return different CNAME or TXT data for the same selector.
- Mixed routing: Some messages leave through Exchange Online, while others leave through a gateway, app, or legacy relay.
- Post-signing rewrite: A footer, tracking wrapper, disclaimer, encoding change, or security gateway modifies signed content.
- Selector mismatch: The message references one selector, but DNS only has the other selector or an old target.
- Old tenant setup: Older Microsoft 365 DKIM settings can differ from newer 2048-bit selector guidance.
- Receiver lookup behavior: A receiver can hit a bad DNS answer, timeout, or cached stale key while another receiver passes.
When the result is dkim=none
- Unsigned route: The message bypassed the Microsoft 365 DKIM signer.
- Disabled signing: DKIM is not enabled for that accepted domain.
- Header mismatch: The visible From domain is not the domain that was signed.
When the result is dkim=fail
- Body changed: The body hash no longer matches after a footer or wrapper was added.
- Header changed: A signed header was modified after Microsoft 365 signed it.
- Key changed: The selector points at an outdated or inconsistent public key.
Microsoft Exchange admin center DKIM settings with selector status and CNAME guidance.
Why the n tag is not the issue
The n= tag in a DKIM TXT record is a human-readable note. It can appear in the TXT record that sits behind a Microsoft 365 selector CNAME. It does not change the public key, the selector, or the verification calculation.
DKIM TXT record with a note tag
selector1._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; n=Microsoft 365 DKIM key; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
If one receiver passes the same selector and another receiver fails intermittently, the note tag is noise. I still check the record because syntax matters, but I do not stop there. A syntactically valid key only proves that the DNS record can be parsed.
Do not fix the wrong thing
Deleting n= from a valid DKIM TXT record will not repair a route that is unsigned, a message that is rewritten, or a selector that resolves differently across nameservers.
Infographic showing how signing, DNS, rewriting, and receiver checks affect DKIM.
How I diagnose the failure path
I treat intermittent DKIM failures like a sampling problem. One failed header is useful, but a small set of passed and failed headers is much better. The comparison should include the DKIM-Signature header, Authentication-Results, source IP, selector, route, and final receiver.
- Split the results: Group failures into dkim=none, dkim=fail, and DNS temporary errors.
- Compare selectors: Check whether failed mail uses a different selector or no selector at all.
- Query every nameserver: Ask each authoritative nameserver directly for the same selector record.
- Trace the route: Find whether the failed messages pass through a gateway, app relay, or connector.
- Test a plain message: Send a simple text email and compare it with the normal template or campaign.
- Monitor over time: Use aggregate DMARC data to confirm whether the fix holds after DNS caches expire.
DNS checks for selector consistencybash
dig +short CNAME selector1._domainkey.example.com dig +short TXT selector1._domainkey.example.com dig @ns1.example.net TXT selector1._domainkey.example.com +short dig @ns2.example.net TXT selector1._domainkey.example.com +short
When I want a quick public selector check, I run the public DKIM checker and compare the result with direct authoritative DNS queries. A checker is useful, but it should not replace the nameserver-by-nameserver test when failures are intermittent.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If the selector resolves consistently, I move to message mutation. Disclaimers, URL rewriting, security gateways, and line-ending changes can all break DKIM after signing. This is why a plain text test often passes while normal business mail fails.
How DMARC reports narrow the cause
DMARC aggregate reports are useful because they show patterns that individual complaints hide. If all failures cluster around one source IP, one receiver, one sending product, or one selector, that pattern gives you a fix path.
Suped's DMARC monitoring is built for this workflow. It groups Office365 sources, separates verified and unverified senders, and turns recurring DKIM or SPF failures into issues with concrete steps to fix. For most teams, Suped is the strongest practical choice because it combines DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, blocklist monitoring, real-time alerts, and multi-tenant reporting in one place.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Before I change a live selector, I also check the wider domain posture with a domain health checker. That catches adjacent problems such as missing SPF, weak DMARC policy, missing DKIM selectors, or MTA-STS gaps that can make the same incident look larger than it is.
How I read intermittent DKIM failure rates
These bands are practical triage thresholds, not a protocol rule.
Noise
Under 1%
Usually forwarding, one-off mutation, or a receiver artifact.
Investigate
1-5%
Look for a repeatable source, route, receiver, or selector.
Active fault
Over 5%
Treat as routing, DNS, or post-signing modification until proven otherwise.
A public Microsoft Answers thread shows the same diagnostic clue: dkim=none means the message was not signed in a way the receiver could use. That should send you toward signing settings and route tracing, not toward changing the body hash.
Fixes that usually resolve Office365 DKIM failures
Once the failure mode is clear, the fixes are straightforward. The mistake I see most often is changing the visible DNS record first, then discovering that the failed mail never used that selector or never reached the signer.
Microsoft 365 DKIM CNAME shape
Host: selector1._domainkey.contoso.com Type: CNAME Value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Host: selector2._domainkey.contoso.com Type: CNAME Value: selector2-contoso-com._domainkey.contoso.onmicrosoft.com.
- Publish both selectors: Microsoft 365 can rotate between selector 1 and selector 2, so both CNAMEs need to exist.
- Remove stale records: Clear old TXT records or duplicate selector entries that conflict with the CNAME design.
- Fix authoritative DNS: Make every authoritative nameserver return the same selector answer.
- Stop later rewrites: Move footers, URL wrapping, and disclaimers before signing or exclude that route.
- Unify routing: Ensure app mail, shared mailbox mail, and connector mail use the expected signing path.
- Regenerate carefully: If the tenant has old selectors, regenerate during a planned window and monitor both pass and fail rates.
The fastest stable fix
For a 50% failure pattern, I check authoritative DNS first, then route split, then post-signing modification. That order finds the highest-probability causes with the least production churn.
Flowchart for diagnosing intermittent Office365 DKIM failures.
Views from the trenches
Best practices
Compare DKIM failures by selector, source IP, sending route, and receiver before changing DNS.
Query each authoritative nameserver directly so split DNS shows up before the next send.
Keep both Microsoft 365 DKIM CNAMEs published, even if one selector is quiet today.
Common pitfalls
Treat a valid DKIM key as proof of syntax only, not proof that every message is signed.
Do not chase the n tag; it is a note field and does not participate in verification.
Do not mix signed and rewritten routes without testing the final received message headers.
Expert tips
Separate dkim=none from dkim=fail first, because the repair paths usually differ.
Test a plain text message and a normal campaign message to expose content rewriting fast.
Use DMARC aggregate data to find whether one receiver, source, or selector owns the issue.
Expert from Email Geeks says a DKIM key with an n tag can be valid because the tag is only a human-readable note and not part of verification.
2020-09-28 - Email Geeks
Marketer from Email Geeks says when roughly half of Office365 mail fails DKIM, the first check should be whether authoritative DNS servers return different selector data.
2020-09-28 - Email Geeks
What I would do next
For intermittent Office365 DKIM failures, I would not start by editing the n= tag or replacing a key that already validates. I would collect passed and failed headers, separate dkim=none from dkim=fail, query each authoritative nameserver, and confirm the route used by failed messages.
If the failures are close to half the mail, inconsistent DNS or split routing is the practical starting point. If the failures happen only after a specific gateway or campaign template, post-signing modification is the likely cause. Once those patterns are visible in DMARC data, the fix becomes a controlled DNS, routing, or content-handling change instead of guesswork.
