DKIM Failure: How to Diagnose and Fix It

By Samuel ChenardAugust 9, 2023Updated September 30, 20266 min read

Ask AI to explain

In brief

Diagnose DKIM failure from received email: check the selector, public key, body hash and signing path, then retest the affected sender before changing DNS.

DKIM Failure: How to Diagnose and Fix It

A DKIM failure means a receiver could not verify a message's DKIM signature. To fix it, use the received message's authentication result and signing details to identify whether the problem is the key lookup, signing configuration, or message processing before changing DNS.

Start with one failed message from the affected application. A website form, an employee mailbox, and a billing service can use different sending routes even when their From addresses share a domain.

What should you collect from the failed message?

A useful DKIM diagnosis starts with the original received message, not a screenshot saying "DKIM authentication failed." Save the full source privately and record:

The receiving system's Authentication-Results, including the exact DKIM result and any reason.
The DKIM-Signature header's signing domain (d=) and selector (s=).
The sending application, recipient system, timestamp, and any relay or forwarding step.
Whether the same sender fails consistently or only on one route.

Use results added by your receiving service. A message can contain authentication headers from other systems, and an arbitrary header is not trustworthy just because it says Authentication-Results. RFC 8601 defines this trust boundary.

The email header analyzer can help inspect the header evidence. Remove private addresses and unrelated sensitive fields from a copy before sharing it; preserve the original privately for diagnosis. Redacting a message changes the evidence, so do not treat the edited copy as a cryptographic verification test.

Which DKIM result needs which fix?

The DKIM result determines the next check. none, fail, temperror, and permerror describe different conditions; the receiver's accompanying explanation narrows them further. See the DKIM result definitions in RFC 8601.

Evidence in the received message	Next check
`dkim=none`, with no DKIM signature	Check whether signing is enabled for that sending service and domain. An unsigned message has no signature to verify.
`dkim=temperror`, with a DNS timeout or other temporary lookup reason	Investigate the named lookup and DNS availability. Retest after the temporary condition clears; a timeout alone does not justify replacing the key.
`dkim=permerror`, or an explicit missing, malformed, or unusable key reason	Inspect the exact selector record and sender configuration. Preserve the complete error because permanent errors can have different causes.
An explicit body-hash mismatch	Follow the body hash did not verify guide. Compare the signing and receiving stages before assigning a cause.
`dkim=fail` without a useful reason	Confirm the selector and key, then investigate signed content and the sending path. The result alone cannot identify which component broke verification.
`dkim=pass` with `dmarc=fail`	Inspect alignment and the SPF result using the DKIM alignment guide. Do not replace a working key just to address alignment.

For the meaning of the literal status, see the dkim=fail glossary entry. If you only have an error phrase and a domain name, the domain-labelled DKIM failure guide explains which evidence is still missing.

How do you check the exact DKIM selector and key?

A DKIM key lookup uses the selector and signing domain from the message. For example, s=mail2026 and d=example.com identify mail2026._domainkey.example.com. This is an illustrative lookup name, not a record to publish. The relationship is defined in RFC 6376 section 3.6.2.

Technical exampletext

dig TXT mail2026._domainkey.example.com +short

On Windows:

Technical exampletext

nslookup -type=TXT mail2026._domainkey.example.com

Compare that answer with the affected sending service's current configuration. If the provider delegates the selector through a CNAME, inspect the target's TXT answer too. Do not substitute a selector guessed from the provider's name for the one in the failed message.

The DKIM checker is useful for public DNS evidence. A domain-only scan may miss the selector used by your sender; finding a key does not prove that the received message's signature verifies.

When the public key and active signer disagree, correct the affected configuration using the sender's documented procedure. Identify other active sending streams before removing records. Key replacement needs a coordinated transition so messages already signed with the old key remain verifiable; RFC 5863 section 3.5 discusses the selector life cycle.

If the receiver reports an algorithm or key-size problem, inspect that evidence specifically. For RSA DKIM, RFC 8301 requires at least 1024-bit keys, recommends at least 2048 bits for signers, and prohibits rsa-sha1. A key's age alone does not diagnose a failed message.

What if DNS is correct but DKIM still fails?

A valid DKIM DNS record leaves several other checks unresolved. Confirm that the affected application actually used the matching private key, then compare a controlled message before and after the suspected processing step.

For an explicit body-hash error, the receiver's computed body hash did not match bh= under the signature's rules. The dedicated body-hash walkthrough covers canonicalization, MIME changes, and signer implementation checks. Ordinary formatting changes do not all have the same effect: DKIM's canonicalization rules tolerate some differences. RFC 6376 sections 3.4 and 6.1.3 define those rules and verification steps.

For other signature failures, compare the signed headers and signing configuration as well as the body. Keep the exact receiver reason attached to the test; "DNS looks right" is not enough to select a repair.

A forwarding service or mailing list can change signed content. Subject edits and added footers are examples worth investigating when that route is affected, as described in RFC 6377. Confirm the change with message evidence before moving signing after a required modification or removing the offending rewrite. Forwarding settings and message encryption are not universal DKIM repairs.

How do you confirm that the DKIM repair worked?

Validate a DKIM repair by sending a new test from the affected application through its normal route. Use the same kind of message that failed, including its template and any relay, rather than substituting a personal mailbox.

Inspect the newly received message and identify the intended signing domain and selector.
Check for dkim=pass on that signature in the trusted receiver result.
Check DMARC separately against the visible From domain. A passing signature from an unrelated domain does not establish DKIM alignment; RFC 7489 section 3.1.1 explains the relationship.
Repeat the affected forwarding route if the failure only occurred there.

The email deliverability test provides a test destination when your affected sender can send to it. A direct test does not validate an additional forwarding hop that it bypasses.

What should you send to support if DKIM still fails?

An unresolved DKIM failure needs a reproducible example. Give your sending provider the failure timestamp, sending service, exact receiver response, signing domain and selector, and the route that reproduces it. Include whether a direct test passes while a relayed message fails.

Share redacted header evidence first. If support needs the original message for verification, use its approved private support channel. Never share your DKIM private key.

Does DKIM failure mean your domain is blocklisted?

A DKIM failure does not establish that a domain is blocklisted. Signature verification and a receiver's reputation or filtering decision are separate parts of handling email. A message can pass DKIM and still go to spam. RFC 5863 section 2.5 explains how filtering uses authentication results alongside other inputs.

If authentication passes but delivery remains poor, continue with the email deliverability guide and the actual rejection or placement evidence.