DKIM Signature Not Verified

When an email's DKIM signature fails verification, the receiving mail server can't confirm the message is authentic. This often results in emails landing in spam or being rejected entirely. The good news is that most DKIM verification failures come down to a handful of causes, and you can track them down without deep technical expertise.

This guide walks you through reading the relevant headers, understanding why failures happen, and fixing them.

Browse all Troubleshooting guides.

How to Read Authentication-Results Headers

Every email that arrives at a major provider like Gmail, Outlook, or Yahoo includes an Authentication-Results header added by the receiving server. This header tells you exactly what happened during verification.

Here's what a failing result looks like:

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

The key pieces to look for:

dkim=fail - The signature did not pass verification
The reason in parentheses - Tells you specifically what went wrong (e.g., "body hash did not verify," "signature verification failed," "no key for signature")
header.d= - The domain that signed the message
header.s= - The selector used to look up the public key in DNS

How to view email headers

In Gmail, open the message and click the three dots menu, then "Show original." In Outlook, open the message properties. Look for the Authentication-Results header near the top.

A passing result looks like dkim=pass. If you see dkim=fail, the reason text and the d= and s= values are your starting point for diagnosis.

Common Causes of DKIM Verification Failure

Most DKIM failures fall into one of these categories:

Public and private key mismatch

The public key published in your DNS doesn't match the private key your mail server uses to sign. This happens after key rotation if only one side is updated, or if the DNS record was pasted incorrectly.

Message modified in transit

Something changed the email headers or body after your server signed it. Security gateways, antivirus scanners, and corporate email appliances are common culprits.

Body hash failure

The email body was altered after signing, so the computed hash no longer matches the signed hash. Footer injections, HTML rewriting, and encoding changes all trigger this. See DKIM body hash errors for an in-depth look.

Expired signature

DKIM signatures can include an expiration timestamp in the x= tag, as defined in RFC 6376 Section 3.5. If the email is delivered or checked after that time, verification fails even if everything else is correct.

Selector mismatch

The selector in the DKIM-Signature header doesn't match any DNS record. This can happen when you change selectors during key rotation but forget to update the mail server configuration.

Canonicalization issues

If your signing server uses simple canonicalization, even minor whitespace changes during transit will break the signature. Switching to relaxed makes signatures more resilient. See RFC 6376 Section 3.4 for canonicalization algorithms.

Failure Type	Header Clue	Most Likely Cause
body hash did not verify	dkim=fail (body hash)	Message body changed after signing
signature verification failed	dkim=fail (signature)	Key mismatch or corrupted DNS record
no key for signature	dkim=fail (no key)	Wrong selector or missing DNS record
signature expired	dkim=fail (expired)	Delayed delivery past the x= timestamp
key revoked	dkim=fail (revoked)	DNS record has empty p= tag

How Email Forwarding and Mailing Lists Break DKIM

Forwarding and mailing lists are the most common reasons DKIM breaks for messages that were signed correctly at the source.

Email forwarding can break DKIM in two ways. If the forwarding server modifies headers that were included in the signature (like the Subject line), the header hash fails. If it alters the body - adding forwarding notices or changing encoding - the body hash fails.

Mailing lists almost always break DKIM. List software like Mailman or Google Groups typically adds footers (unsubscribe links), modifies the Subject line (adding list tags like [list-name]), and sometimes rewrites the From address. Any of these changes will invalidate the original DKIM signature.

Forwarding and mailing list breakage is a known limitation of DKIM. The industry solution is ARC (Authenticated Received Chain), which preserves original authentication results across forwarding hops. Gmail, Microsoft, and Yahoo all support ARC.

If your emails primarily fail DKIM after passing through a forwarding service, the issue may not be with your DKIM setup at all. Focus on making sure your direct emails pass, and consider that forwarded mail will rely on ARC support at the receiving end.

Check your current DKIM configuration

Generate and verify DKIM key pairs to rule out key mismatch issues.

Open DKIM Creator

Step-by-Step Diagnosis Workflow

When you discover that DKIM is failing, work through these steps in order:

Read the Authentication-Results header

Open the raw headers of a failed email. Find the Authentication-Results header and note the exact failure reason, the d= domain, and the s= selector. This tells you what type of failure you're dealing with.

Verify the DNS record exists

Look up {selector}._domainkey.{yourdomain.com} as a TXT record using a DNS lookup tool. If no record is found, either the selector is wrong or the record was never published.

Check for key mismatch

Compare the public key in your DNS record with the private key your mail server is using. If you recently rotated keys, confirm both sides were updated. Look for truncated base64 strings or extra characters in the DNS record.

Send a direct test email

Send a simple plain-text email directly to a Gmail or Outlook address - no forwarding, no mailing lists. Check the headers on that message. If this passes, your signing setup is correct and the failures are caused by intermediaries.

Map the email path

Look at the Received: headers to trace every server the message passed through. Identify any security gateways, spam filters, or forwarding services that may be modifying the message after signing.

Check canonicalization settings

Look at the c= tag in your DKIM-Signature header. If it says simple/simple, switch to relaxed/relaxed to tolerate minor whitespace changes during transit.

Review your mail pipeline order

Make sure DKIM signing happens last in your outbound mail pipeline - after any disclaimers, antivirus scanning, or content filtering. Anything that modifies the message after signing will break verification.

When to Regenerate Your DKIM Keys

Not every failure requires new keys, but there are clear situations where regeneration is the right move:

Your DNS record is corrupted or truncated - Rather than trying to patch it, generate a fresh pair. If the issue is record length, see DKIM record too long
You're using a 512-bit or 768-bit key - Modern standards require at least 1024 bits, and 2048 bits is strongly recommended per RFC 6376 Section 3.3.3
You suspect your private key has been compromised - Generate new keys immediately with a new selector
Key rotation is overdue - If you've used the same key for over a year, rotating is good practice
You can't determine which private key matches your DNS record - Start clean with a new pair

When you regenerate, always use a new selector name. This lets you publish the new key alongside the old one, avoiding a gap where no valid key exists.

Never delete the old DNS record before your mail server is updated to sign with the new key. Emails signed with the old key that are still in transit will fail verification if the old record is removed too early.

References

RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures

A valid DKIM setup starts with properly generated keys and correct DNS records.

Generate DKIM keys that pass verification

Create 2048-bit RSA key pairs with best-practice settings. Free, instant, and ready for your DNS.

Generate DKIM Keys

DKIM Signature Not Verified: How to Diagnose and Fix