DKIM Signature Not Verified — Troubleshooting Guide

Why Is My DKIM Signature Failing?

A DKIM signature fails verification when the receiving server cannot validate the cryptographic signature in your email header against the public key in your DNS. This can happen because the DNS record is missing, the keys do not match, the message was modified in transit, or the signature has expired.

Here are the most common causes, ordered by how often we see them.

Cause 1: DKIM DNS Record Is Missing or Incorrect

The most basic failure: the public key is not where the receiving server expects it.

How to check:

dig +short TXT selector._domainkey.yourdomain.com

Replace selector with your actual DKIM selector (e.g., google, s1, smtp, k1). If the result is empty, your record is missing.

How to fix:

1. Log in to your email service provider and find the DKIM key it generated for you
2. Copy the public key value
3. Create a TXT record at selector._domainkey.yourdomain.com with the key
4. Verify with dig again

Common mistakes:

• Wrong selector name — check your ESP's documentation for the exact selector
• Extra spaces or line breaks in the DNS record value
• Using a CNAME record when your ESP expects a TXT record (or vice versa)

Cause 2: Key Mismatch (Rotated or Regenerated Keys)

If you regenerated your DKIM keys in your ESP but did not update the DNS record, the private key used to sign and the public key used to verify will not match.

How to fix: Update the DNS record with the new public key from your ESP's dashboard. After DNS propagation, new emails will verify correctly.

Cause 3: Message Modified in Transit

DKIM signs specific parts of the email (headers and body). If anything modifies those parts after signing, the signature becomes invalid.

Common modifiers:

• Email gateways that add footers or disclaimers
• Mailing list software that adds [ListName] to subject lines
• Anti-virus scanners that rewrite URLs
• Forwarding services that re-encode message content

How to fix: Ensure DKIM signing happens at the last hop before the message leaves your infrastructure. If you use an email gateway, configure it to either not modify messages or to re-sign with DKIM after modifications.

Cause 4: DNS Record Is Too Long (Truncated)

2048-bit DKIM keys produce values longer than 255 characters. DNS TXT records have a 255-character string limit. The value must be split into multiple strings within a single TXT record:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA" "remainder_of_key_here..."

Some DNS providers handle this splitting automatically. Others require you to manually split the value. If your provider truncates the value without splitting, the key will be incomplete and verification will fail.

How to fix: Check your DNS provider's documentation for handling long TXT records. If needed, switch to a 1024-bit key (less secure but fits in a single string) or use a provider that supports long TXT values.

Cause 5: Signature Has Expired

DKIM signatures can include an expiration timestamp (x= tag). If the receiving server processes the email after the expiration time, verification fails.

How to fix: This is usually caused by delayed email delivery (message sat in a queue for hours or days). Check whether your ESP sets an x= tag and whether the expiration window is reasonable. Most ESPs do not set expiration, so this is rare.

Cause 6: Wrong Canonicalization

DKIM supports two canonicalization modes that determine how strictly the signature matches the message:

• simple — No modification tolerance. Even minor whitespace changes break the signature.
• relaxed — Tolerates minor whitespace differences in headers and body.

If your DKIM signature uses c=simple/simple and any server in the delivery chain makes even a trivial formatting change, the signature breaks.

How to fix: Configure your ESP to use c=relaxed/relaxed. This is the most compatible setting and is what most ESPs use by default.

How to Read DKIM Failure Details in Email Headers

Look for the Authentication-Results header:

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.d=yourdomain.com header.s=selector1;

The parenthetical text tells you the specific failure:

Error Message	Meaning
body hash did not verify	Message body was modified after signing
signature verification failed	Public key does not match the signing key
no key for signature	DNS record not found for the selector
key too small	Key length is below the receiver's minimum (usually 1024 bits)
signature expired	The x= expiration time has passed

FAQ

How do I find my DKIM selector?

Check the DKIM-Signature header in a sent email. The s= tag contains the selector:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google; ...

In this example, the selector is google.

Can I have multiple DKIM selectors for one domain?

Yes. Each sending service typically uses its own selector (e.g., Google uses google, SendGrid uses s1 or s2). Each selector has its own DNS record and key pair. This is how multiple services can sign emails for the same domain independently.

Does DKIM failure always mean DMARC fails?

No — DMARC only fails if both DKIM and SPF alignment fail. If SPF is properly aligned with your domain, DMARC can still pass even when DKIM fails. However, relying solely on SPF is risky because SPF breaks on forwarding.

How often should I rotate DKIM keys?

There is no strict requirement, but rotating every 6–12 months is a good practice. When you rotate, update the DNS record first, wait for propagation, then switch the signing key. Keep the old DNS record active for a few days to handle in-flight messages.