Start with the signature: it names the exact DNS key you must test
A DKIM public key is not stored at a universal ‘DKIM record’ name. The signature carries a signing domain in d= and a selector in s=. Together they form the lookup name selector._domainkey.signing-domain.
The useful reframe is to follow the failed message. RFC 6376 defines the DKIM signature tags, selector mechanism, public-key retrieval and verification process. RFC 6376 A dashboard can show a key for one selector while the application signs with another. Querying default._domainkey from habit can therefore produce a correct answer for the wrong route.
Obtain the raw original from the receiver or an event-level signature record from the sending provider. Copy d=, s=, the algorithm, canonicalisation, signed-header list, body hash and signature timestamps when present. Preserve the receiver’s DKIM result and reason. Record the application, account, UTC time and message ID before editing DNS.
If you have ever spent an afternoon adding a ‘DKIM record’ and watched signatures still fail, the missing piece is usually the selector and signing domain named inside the signature itself. Because a domain can sign under several selectors, testing the wrong name gives you a perfect ‘pass’ for the wrong key. Reading the signature correctly is the difference between a quick fix and a failed round of guesswork, and it is the same evidence you need for aligning DKIM with your From domain.
Use the result added inside the receiver’s trust boundary
Find Authentication-Results in the delivered original. RFC 8601 defines this field and the authentication service identifier that names the evaluating environment. RFC 8601 Use the field your receiving service added, not any similarly named field that arrived from an untrusted source.
Copy the exact result: pass, fail, none, policy, temporary error or permanent error, plus any comment. Preserve header.d and selector details. ‘DKIM failed’ is too broad for repair. A missing key, malformed record, revoked key, body-hash mismatch and signature verification failure have different owners.
Messages can carry several signatures. Match results to domains and selectors rather than deleting all DKIM records. One signature may pass while another fails, and the passing signer may or may not align with the visible From domain for DMARC.
Full headers can expose personal addresses, internal hosts and identifiers. Keep the original restricted. Share a redacted extract with stable placeholders, retaining the signing domain and selector only when necessary. If no trusted receiver result is available, stop and collect one controlled message before changing production.
Build and query the selector name exactly
If the signature says d=example.co.uk and s=mail2026, query TXT at mail2026._domainkey.example.co.uk. Preserve dots, case-insensitive domain labels and the complete selector value. Do not add the visible From domain unless it is the actual d= value.
Use a DNS client and, where useful, Google Admin Toolbox Dig to retrieve the public record. Google Admin Toolbox Dig Record the resolver, UTC time, CNAME chain, TXT answer and TTL. Query the authoritative nameserver when caches or delegation are in doubt.
A DNS panel may append your zone automatically. Check that a record entered as a full name did not become mail2026._domainkey.example.co.uk.example.co.uk. If the selector uses CNAME delegation, follow the target and verify its answer; do not replace it with a guessed TXT key.
Do not publish private keys. DKIM DNS contains a public key, commonly in a p= value. The matching private key belongs in the sending service. If a ticket or document includes private-key material, stop, restrict access and follow your security incident process.
Separate absent, malformed and stale DNS answers: each has a different owner
No public answer can mean the record was never published, was published at the wrong name, was removed too early, or is hidden by delegation trouble. Compare the exact signature time with DNS change records and TTLs. A later successful query does not prove the key existed when the receiver checked.
A record can exist but be unusable. Check tag syntax, key data, service type or hash restrictions where present, and whether the key has been revoked with an empty p= value. RFC 6376 defines key-record interpretation and verifier behaviour. DKIM key records
If a CNAME is used, check for loops, broken targets and conflicting data at the selector owner. If TXT is split into quoted character strings by DNS presentation, join the strings as the DNS client does rather than treating them as separate keys.
The trade-off in rotation is overlap versus exposure. Keeping old selectors long enough for queued mail to verify supports continuity; leaving abandoned keys indefinitely expands unmanaged inventory. Use distinct selectors, recorded activation and retirement times, and evidence that old mail has cleared before deletion.
Separate key publication from signing activation
A correct public key does not prove the message used the matching private key. Compare the observed selector and domain with the provider account that generated the DNS instruction. A record copied from another account or region can look valid while every signature from this route fails.
If the receiver reports dkim=none, the route may not have added a signature. Publishing more keys does not activate signing. Enable DKIM in the actual application or relay and verify that the feature, From domain and account are covered. Some services require a separate verification control after DNS publication.
If the signature exists but cryptographic verification fails while the body hash matches, investigate key mismatch, malformed signature data, unsupported algorithm or incorrect signing implementation. Check whether the provider rotated its private key without publishing the corresponding public key, or whether DNS was rolled back to an older value.
Never upload or send a private key for comparison through an ordinary support ticket. Ask the sending platform to confirm the key fingerprint or regenerate an account-specific pair through its secure control. Record selector ownership so future administrators know which service may rotate it.
Treat a body-hash mismatch as a message-path question
DKIM computes a hash of the canonicalised body and signs selected header data. If a receiver reports a body-hash mismatch, the message body it evaluated did not match the signed body hash under the stated canonicalisation. RFC 6376 defines simple and relaxed canonicalisation and the bh=, h= and c= tags. DKIM canonicalisation and hashes
Trace systems after signing: outbound gateways, disclaimers, mailing lists, link rewriters, security products and MIME conversions. Compare a copy captured immediately after signing with the final received copy where authorised. A footer, changed Subject or rewritten body can matter depending on signed fields and canonicalisation.
Do not assume relaxed canonicalisation tolerates arbitrary modification. It normalises specified formatting differences, not substantive text or link changes. Do not remove important headers from signing solely to tolerate an uncontrolled gateway. Move signing after the required modification or configure the intermediary through a supported design.
Keep message content private. Use a synthetic test with no customer data. If the only failing example is sensitive, stop and involve the mail-security owner under controlled access rather than forwarding it to multiple suppliers.
A body-hash mismatch is often the least obvious cause because the signature is fine: something after signing modified the content. Outbound gateways, disclaimers, mailing lists and relaying services are the usual suspects. If the message path involves forwarding or mailing-list handling, that is where to look before touching any DNS.
If an intermediary altered the signed message, the forwarding and mailing-list guide explains why authentication can change between observation points.
Make one correction with selector lifecycle notes
Choose the correction that matches the evidence: publish the missing account-specific key, correct the owner name, repair a CNAME target, activate signing, align the provider account with the selector, complete a controlled rotation, or prevent modification after signing.
Before DNS work, save the existing public and provider values, TTL, owner and rollback. Check for an active record at the requested selector. Do not overwrite another sender’s key. Ask the provider for a new selector if there is a collision.
Publish exactly what the service generated for your account. Query it publicly, then complete any provider verification. For rotation, keep old and new selectors distinct and let the sender choose the new selector. Remove the old key only after queued messages and all routes have moved.
Stop if the requested value conflicts with current DNS, the service cannot identify which private key it uses, a shared gateway modifies mail unpredictably, or the change affects several critical systems. Escalate with the observed signature and public query rather than trying random selector names.
Whichever fault you find, the fix should be a single owned correction with a recorded rollback: not a sequence of edits that make the cause impossible to isolate. When you need to follow the signed header fields around a real message, the email headers guide helps you read them confidently.
Prove the new signature on the same route
After public DNS and service activation are complete, send one plain, non-sensitive message through the same application, account, From domain, outbound gateway and recipient provider. Capture the new raw original.
Confirm a DKIM signature is present. Check that d= and s= are the intended domain and selector. Query that exact selector again. Confirm the trusted receiver reports dkim=pass for the same signer. If DMARC matters, separately confirm that the passing signer aligns with the visible From domain.
This is exact verification: right route, right signature, right public key, trusted pass. A green DNS test alone does not cover private-key use or content survival. A provider badge alone does not cover final receipt. Also test one route using another active selector so the change has not broken it.
If failure remains, preserve both originals and the new reason. Stop and escalate when the result changes unpredictably, timestamps indicate signing-clock problems, algorithms are unsupported, or provider evidence conflicts with the receiver. Send redacted signatures, results, DNS answers, UTC times and route details. Include the selector’s authoritative answer and CNAME target, if any, as observed near the send time. Ask the provider to identify which private-key version signed the event without asking it to disclose the private key itself. If a gateway may have changed content, provide hashes or controlled before-and-after samples through the approved security channel rather than emailing confidential production messages around support teams. DKIM is repaired only when the receiver validates the signature the real sender produced.
Proving the repair means confirming the right signature, the right public key and a trusted receiver pass on the same route: which is the verification standard used across SPF and other record repairs on this site.
Sources and further reading
- RFC 6376: DomainKeys Identified Mail
- RFC 8601: Message Header Field for Indicating Message Authentication Status
- Google Admin Toolbox: Dig