How to test DKIM and fix common DKIM failures

DKIM problems surface in three places: the Authentication-Results header of delivered mail, the DMARC aggregate reports that show verification outcomes across all your traffic, and DNS queries against the published keys. This entry covers the verification workflow for changes, the verdict vocabulary, and the handful of misconfigurations behind nearly every DKIM failure in the wild.

The verification workflow

Testing DKIM end to end

1
Check the key in DNS
Resolve the selector externally and confirm the record is intact: one string or correctly split, v=DKIM1, complete p= value.
dig TXT s2026a._domainkey.example.com +short
2
Send real mail to a Gmail account
Open "Show original": Gmail displays a DKIM PASS/FAIL summary with the signing domain, plus the full Authentication-Results header for detail.
3
Confirm the identifiers, not just the verdict
dkim=pass with header.i showing your domain is success. A pass for the ESP's platform domain verifies their signature, not your alignment.
4
Watch DMARC aggregate reports
Reports over the following days show DKIM outcomes across all receivers and all streams, catching the sender you forgot to test.

Validator services (MxToolbox DKIM lookup, dmarcian, EasyDMARC, and reflector addresses that mail you back a verification report) package the same checks with parsing help. They accelerate the reading; the identifiers still need your judgment.

Reading the verdicts

DKIM results in Authentication-Results

Feature	Meaning	First move
dkim=pass	Signature verified against the published key	Confirm the d= domain is yours for alignment
dkim=fail (body hash)	Body changed after signing	Trace the path for gateways, lists, footers
dkim=fail (signature)	Signed headers changed, or wrong key at the selector	Check recent key changes and header-modifying hops
dkim=neutral / none	No signature present or not evaluable	The stream is not signing; fix the signer config
dkim=temperror	DNS lookup for the key failed transiently	Investigate DNS availability if it persists
dkim=permerror	Key record malformed or unusable	Fix the published record; it fails everywhere until then

The usual suspects

The mangled DNS record

A 2048-bit key split across quoted strings, then truncated or re-quoted by a DNS console, verifies nowhere while looking plausible in the editor. The external dig check after every record change exists for exactly this failure, which remains the most common self-inflicted DKIM outage.

The selector mismatch

The signer signs with s=tx1 while DNS carries the key at tx-1, or a vendor migration changed the selector and only one side got the memo. The signature's s= tag and the DNS record name must match exactly; read the s= from a delivered message and query precisely that name.

The rotation gap

An in-place key swap creates a window where mail signed with the old key meets DNS serving the new one, failing verification for hours. The additive rotation pattern, new selector first, switch signing second, retire last, exists to make this window impossible.

The unsigned stream

Marketing mail signs perfectly while the CRM, the billing system, or the notification service sends unsigned, discovered only when DMARC reports show dkim=none sources or when enforcement starts eating their mail. Every stream needs signing configured individually, and the aggregate reports are the inventory of which ones actually are.

Failures that are really path modifications

Body hash mismatches on mail that left you intact point at the path: disclaimer gateways, link-rewriting security products, mailing lists. Intermittent failures across receivers point at simple canonicalization meeting header re-folding. Both diagnoses and their fixes live in the canonicalization entry; neither is fixed by touching your keys.

Frequently asked questions

How long after a DNS change until DKIM verifies?

One TTL: resolvers serve the cached record until it expires. Publishing new keys under new selectors sidesteps caching entirely, since no resolver holds a stale copy of a name that did not exist.

My ESP dashboard says DKIM is verified but mail still fails. Why?

The dashboard checks that their expected DNS records resolve; it does not verify actual signatures on actual delivered mail. Test with a real message to a Gmail account and read the headers; the dashboard is a prerequisite check, not proof.

Should test failures on forwarded mail worry me?

Not by themselves: forwarding through modifying intermediaries legitimately breaks signatures, which is exactly why DMARC accepts either aligned mechanism. Worry when direct delivery fails.

What is the fastest way to find which of my streams are unsigned?

DMARC aggregate reports, grouped by source: every legitimate sending service appears there with its DKIM outcome. Sources showing none or fail with your domain in the From header are the work list.

Key takeaways

Verify twice: the key in DNS from an external resolver, and a real signature in delivered headers
A pass only helps DMARC when the d= domain is yours; read identifiers, not just verdicts
The classic breakages: mangled split TXT records, selector mismatches, in-place rotation gaps, and unsigned streams
Body hash mismatches usually indict the delivery path, not your configuration
DMARC aggregate reports are the continuous DKIM test across every stream and receiver; alert on permerror and new unsigned sources