Begin with the receiver’s result
Send a new test through the same provider, account, and message stream that is failing. At the receiving mailbox, open the original message source and inspect theAuthentication-Resultsheader added by that receiver, plus everyDKIM-Signatureheader. A message can carry multiple signatures. Use the receiving provider’s results rather than a same-named header supplied earlier in the message, which may not be trustworthy.
- dkim=pass means that signature verified with a public key found for its selector and signing domain. Record its
s=selector andd=domain. - dkim=fail means a signature was evaluated but did not verify. The receiver’s detailed result, if available, helps distinguish a missing key from a bad signature or a message change.
- dkim=none usually means the receiver did not find a signature to evaluate. Check the sender’s signing settings before changing DNS.
Query the key named by that message
DKIM key lookup uses the signature’ss=selector andd=signing domain. If a sample message containss=mail2026; d=brand.example, query this exact owner name:
dig +short TXT mail2026._domainkey.brand.exampleCompare the returned record with the provider’s current published-key instructions. Check that the selector and domain are exact, the TXT value includes a usable public key, and the value has not been replaced or revoked. If the provider gave you a CNAME instead, verify the CNAME at this owner name and follow its target as the provider directs. DNS control panels can append the zone name automatically, so the public query is evidence of what receivers can actually look up.
The example uses the reservedbrand.exampledomain and is not a real sender record. For background on record format, selector setup, and key rotation, see the DKIM Record Guide.
Match the symptom to the next check
No DKIM signature, or an unexpected signing domain
Evidence to inspect
In the newest message source, look for a DKIM-Signature header and the receiver-added Authentication-Results entry. Note whether the receiver reports dkim=none, and record the signature d= domain when a signature is present.
Next action
In the sending provider, check the exact product, account, and mail stream used for this message. Confirm DKIM signing is enabled and the intended From domain is verified for that stream. Ask the provider to enable or correct signing there; publishing a DNS key alone does not make an unsigning stream sign.
The selector or published DNS record does not match
Evidence to inspect
Compare s= and d= in the message’s DKIM-Signature with the DNS owner name you query: <selector>._domainkey.<d-domain>. Check the full public TXT answer, or the CNAME target if your provider instructed you to delegate the selector with CNAME.
Next action
Query the exact selector and signing domain from the failed message, not a familiar default selector or only the visible From domain. Correct a typo, wrong DNS zone, stale key value, missing record, or incorrectly configured CNAME using the provider’s current record instructions. Then query public DNS again.
The signer’s private key and DNS public key are out of sync
Evidence to inspect
If the exact selector resolves but the receiver still reports dkim=fail, compare the active selector/key status in the provider’s signing settings with the public key currently published at that DNS name. Check for a revoked or malformed record, a truncated/copied key, or a recent key replacement.
Next action
Have the provider confirm which active key is signing this stream, then publish the matching public-key record exactly as supplied. Never send or paste the private key into a DNS tool, support ticket, or public checker.
A key rotation switched over before DNS was ready
Evidence to inspect
Compare the s= selector on messages sent before and after the change with the records that currently resolve for each selector. Look for a new selector with no public key, or an old selector removed while messages signed with it are still being delivered or verified from cache.
Next action
Follow the provider’s rotation sequence: publish the new selector record, confirm it resolves, switch signing to the matching key, and send a fresh test. Keep the old record for the provider’s stated transition period; remove it only when old signatures no longer need verification.
A message changed after it was signed
Evidence to inspect
Compare the receiver’s result for a direct test message with the result after forwarding or mailing-list processing. If the provider reports a body-hash mismatch, inspect added footers, rewritten links, MIME changes, or other body edits; if the signature check fails, inspect signed headers and intermediary rewrites too.
Next action
Send a fresh message directly from the provider to a test mailbox before forwarding it. If only the altered copy fails, review the intermediary’s rewriting behavior and configure signing after final message changes where that system supports it. DKIM canonicalization tolerates some formatting changes, but not every transformation.
DKIM can pass while DMARC fails
DKIM validation asks whether a signature verifies with the public key selected bys=andd=. DMARC separately checks whether an authenticated identifier aligns with the domain in the visibleFrom:header. A valid signature from an unrelated provider domain can therefore pass DKIM but fail DKIM alignment.
If the receiver reports DKIM pass and DMARC fail, compare the signature’sd=with the From domain, then check the DMARC record’sadkimalignment mode. Relaxed mode permits the same organizational domain; strict mode requires an exact domain match. Also inspect SPF: DMARC passes when at least one authenticated SPF or DKIM identifier both passes and aligns. If neither aligns, ask the sending provider how to sign with an aligned domain or use an aligned envelope sender. For the policy and alignment details, continue to the DMARC Record Guide.
Confirm the provider setup, then retest
- In the provider’s sending settings, inspect the exact account and stream, verified From domain, DKIM enabled/status indicator, active selector, and current DNS instructions. Provider labels differ; confirm which key and domain the provider says it uses for this message type.
- Correct the provider or DNS mismatch using that provider’s documented values. Do not copy a private key into DNS or replace an active key until the provider’s rotation steps are clear.
- After public DNS resolves as expected and the provider shows signing enabled, send a fresh message through the same stream to an external test mailbox. Inspect that new message’s receiver-added Authentication-Results and signature again. Confirm the expected selector, a DKIM pass, and—when DMARC is the issue—an aligned result for DKIM or SPF.
The checks here are performed by you: this page does not connect to your receiving mailbox, DNS zone, or provider account, and it cannot change DNS records or signing settings. For the broader protocol setup context, read the Email Authentication Guide.
Standards references
- RFC 6376: DKIM Signatures defines the signature fields and selector-based key lookup.
- RFC 8301: DKIM cryptographic algorithm and key updates updates algorithm and RSA key-size requirements.
- RFC 9989: DMARC defines authenticated identifier alignment with the Author domain.