Diagnostic tutorial for DKIM failures: signature verification problems, missing keys, body hash mismatches, and alignment issues. Includes diagnostic commands, failure type decision tree, and solutions for the most common UK deployment issues.
dkim=faildkim=permerrordkim=temperrordkim=noneFrom Authentication-Results header:
Authentication-Results: mx.google.com;
dkim=fail [email protected] header.s=2026q2 header.b=abc123Note:
fail, permerror, temperror, or none.dkim=failSignature does not verify. Five common causes:
A forwarder, spam filter or gateway modified the message body (added disclaimer, rewrote links, converted encoding). Body hash no longer matches signed version.
Diagnostic: compare the received message body with what was sent. Look for inserted text (disclaimer footers), changed encoding, or link-wrapping.
Fix: avoid the modifying intermediary, or use ARC-signing forwarders. For receiving mail that must flow through a modifying gateway, ensure the gateway supports ARC.
A signed header was modified (typically Subject or To). Hash fails.
Fix: identify which header changed; reduce the h= list to exclude headers that intermediaries commonly modify. Minimum safe set: from, to, subject, date, message-id.
Sender signed with simple/simple but message underwent whitespace normalisation. Switch to relaxed/relaxed in DKIM signing config. See DKIM-Signature Header Reference.
Signer uses a private key whose matching public key is not the one at selector._domainkey. Often occurs after rotation where server was updated but DNS was not.
Diagnostic:
dig TXT 2026q2._domainkey.firm.co.ukConfirm the public key matches what the signing server is using. Often the fix is waiting for DNS propagation or correcting the selector's published key.
Rare. Charset conversions, MIME re-encoding, or non-standard processing can corrupt signed content. Debug with raw headers and a DKIM verifier tool.
dkim=permerrorDKIM record itself is broken. Causes:
p= tag. Check DNS record; ensure p= present with valid key.selector._domainkey.domain, not a variation.p= empty) when selector should be active. Check that *._domainkey wildcard is not overriding.dkim=temperrorTransient DNS failure. Usually self-resolving. Same diagnostics as SPF temperror — check DNS hosting health, resolver variations, DNSSEC chain.
dkim=noneNo DKIM signature present on message. Either:
The most common DKIM failure mode. Body hash is computed at signing and included as bh= in the signature. Verifier recomputes and compares. Any body modification breaks the match.
Common body modifiers in UK mail flows:
| Source | Modification |
|---|---|
| Corporate inbound gateways (Mimecast, Proofpoint) | Disclaimer footers, link rewriting |
| University mail relays | Subject prefixes, footers |
| Mailing list software | Footer with list info |
| Antivirus scanners | "Scanned clean" markers |
| Encoding converters | Base64 to quoted-printable |
| Content filters | Spam-check markers |
Solutions:
relaxed canonicalisation — tolerates whitespace changes.dkim=?
├── pass → no action
├── fail
│ ├── Body/header modified → ARC or avoid modifier
│ ├── Canonicalisation too strict → switch to relaxed/relaxed
│ ├── Key mismatch → verify DNS publication vs signing config
│ └── Byte-level corruption → investigate MIME/charset
├── permerror → fix DNS record (p=, base64, location)
├── temperror → DNS health; usually self-resolves
└── none
├── Your own mail → configure DKIM signing
├── Third-party sender → custom-domain DKIM delegation
└── Stripped by gateway → check gateway config# Retrieve DKIM public key
dig TXT 2026q2._domainkey.firm.co.uk
# Check all DKIM selectors at domain
# (requires knowledge of selector names; try common ones)
for sel in 2026q1 2026q2 default k1 s1 selector1 selector2; do
dig +short TXT "$sel._domainkey.firm.co.uk"
done
# Test DKIM from command line
openssl dkim-verify -f sample-message.eml # if available
# Check message's DKIM headers
# (in mail client: View Source / Show Original)
# Send test and inspect
echo "Test" | mail -s "DKIM Test" [email protected]Mailchimp default signs with d=mcsv.net. DMARC fails because mcsv.net does not align with firm.co.uk. Fix: configure Mailchimp's custom domain authentication via CNAME-delegated DKIM.
Recipient forwards your mail via corporate gateway that adds a footer. DKIM body hash fails. If ARC deployed end-to-end, receiver validates via ARC; otherwise mail fails DMARC. Deploy ARC on any forwarder you operate; encourage receivers to honour ARC chains.
Platform generates DKIM key and provides DNS record; customer forgets to publish at their DNS provider. Authentication-Results shows dkim=permerror or none. Fix: verify DNS record is published correctly at selector._domainkey.domain.
Outlook.com sometimes rewrites certain headers in transit (Reply-To for anti-phishing). If signed by sender, DKIM fails. Reduce h= list to exclude frequently-rewritten headers.
Rotated from 2026q1 to 2026q2; revoked 2026q1 too quickly. Mail signed just before rotation with q1 but delivered after revocation = dkim=permerror. Fix: lengthen overlap window (30-60 days between new key active and old key revoked).
Legacy key size; some modern receivers produce permerror or negatively weight. Rotate to RSA-2048 or Ed25519 immediately.
Q: Why does DKIM fail only at certain receivers?
A: Different receivers apply canonicalisation differently or treat body-hash mismatches with varying strictness. Usually indicates marginal signatures — move to relaxed/relaxed, minimal header list.
Q: Should I sign with multiple DKIM keys simultaneously?
A: Yes during rotation (old + new selectors active). Steady-state: RSA-2048 + Ed25519 side by side is acceptable for receiver compatibility.
Q: Does signing more headers improve security?
A: Marginally. Primary security comes from signing From; additional headers prevent specific injection. Signing too many headers increases fragility to benign modifications.
Q: How do I know my signing is using relaxed canonicalisation?
A: Inspect an outbound message's DKIM-Signature header. c= tag shows canonicalisation mode.
Q: Can DKIM fail because of DNS cache issues?
A: Yes — if selector recently rotated and resolver has stale cache. Usually self-resolves within TTL. For emergency: reduce TTL before rotation.
Q: Is it safer to use Ed25519 DKIM exclusively?
A: Not quite yet in 2026 — some receivers still prefer RSA or treat Ed25519 less favourably. Dual-signing (RSA + Ed25519) is best compatibility.