DKIM Fail — Diagnosis and Solutions

What DKIM Fail Means

DKIM fail occurs when the receiving server cannot verify the email's digital signature. Either the signature doesn't match the public key in DNS, the message was altered in transit, or the public key in DNS is missing or corrupted.

The DKIM check result is recorded in the Authentication-Results header of the received email:

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

A DKIM fail alone doesn't necessarily mean the email won't be delivered. It depends on the domain's DMARC policy:

• If DKIM fails but SPF passes and is in alignment, DMARC can still evaluate the email as pass.
• If both DKIM and SPF fail (or neither is aligned), DMARC fail is inevitable — and with a p=quarantine or p=reject policy, the email won't be delivered.

DKIM fail is therefore always a signal that requires investigation, even if DMARC currently passes.

How DKIM Verification Works

To understand the causes of failure, you need to know what the receiving server checks:

1. Finds the domain (d=) and selector (s=) in the DKIM-Signature header.
2. Queries DNS for the TXT record at {selector}._domainkey.{domain} to retrieve the public key.
3. Computes the hash of the signed headers and message body according to the canonicalization rules (c= tag).
4. Compares the computed hash with the value in the signature — if they match, DKIM passes.

Failure can occur at any of these steps. The error message in Authentication-Results tells you exactly where.

Most Common Causes of DKIM Fail

Missing DNS Record (no key for signature)

The receiving server queries {selector}._domainkey.{domain} and DNS returns NXDOMAIN — the record doesn't exist.

Causes:

• The selector was never added to DNS (typically after a DNS migration or provider change)
• Typo in the record name — selector1._domainkey vs. selektor1._domainkey
• The record was accidentally deleted
• DNS propagation hasn't completed yet (after a recent change)

Verify the record exists using the DKIM analyzer or the command line:

dig mail2024._domainkey.example.com TXT +short

If the command returns no output, the record doesn't exist in DNS.

Message Body Modified (body hash did not verify)

The most common cause of DKIM fail. The error message body hash did not verify means the body hash computed by the recipient doesn't match the bh= value in the DKIM signature. The message was altered after signing.

What typically modifies the email body:

• Outbound gateways and filters — antispam, antivirus, DLP (Data Loss Prevention) systems that process outgoing mail after DKIM signing
• Email signatures and disclaimers — servers that append legal disclaimers or signatures to the message body after signing
• Mailing lists — add footers, headers, or change formatting
• Forwarding — some servers reformat the message during a forward
• Encoding — character set or transfer encoding changes (e.g., from quoted-printable to base64)

Solution: identify which system modifies the message and either move DKIM signing after that system (so the final version gets signed) or ensure the system doesn't alter signed parts.

Incorrect Canonicalization

The c= tag in the DKIM signature determines how strictly the content is compared. The format is headers/body:

If you see c=simple/simple in the DKIM-Signature and DKIM is failing, try switching to c=relaxed/relaxed. This setting tolerates minor modifications that mail servers make during transit — whitespace reduction, removal of trailing blank lines in the body, and converting header names to lowercase.

The canonicalization setting is changed in the signing server's configuration (OpenDKIM, Postfix, Exchange). For hosted services (Google Workspace, Microsoft 365), it's typically set to relaxed/relaxed and cannot be changed.

Incomplete or Truncated Key in DNS

2048-bit RSA keys exceed the 255-byte limit for a single DNS string defined in RFC 1035. The value must be split into multiple strings:

mail2024._domainkey.example.com TXT ("v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQE..."
    "...FAAOCAQ8AMIIBCgKCAQEA...")

Some DNS panels handle splitting automatically, others don't. If you paste the key as a single string without splitting, DNS may truncate it — resulting in an invalid public key and dkim=fail.

Check: compare the key length in DNS with the length of the key generated by your provider. If they differ, the record is incomplete.

Private/Public Key Mismatch

The public key in DNS doesn't match the private key the server uses for signing. This typically happens during:

• Key rotation — the server is already signing with a new key, but DNS still has the old public key (or vice versa)
• Misconfiguration — the server is configured with a different key than the one whose public key is in DNS
• Configuration copying — during migration to a new server, the old private key was copied, but DNS has the key from the new installation

Solution: generate a new key pair, publish the public key in DNS under a new selector, and configure the server to sign with the new private key.

Revoked Key

An empty p= value (no key) in the DNS record signals an intentionally revoked selector:

mail2024._domainkey.example.com TXT "v=DKIM1; p="

This is the standard procedure during key rotation (RFC 6376, Section 3.6.1). However, if the server still signs with the revoked selector, every email gets dkim=fail.

Solution: either update the server to use the new selector, or restore the public key in DNS.

Signature Expiration

The x= tag in the DKIM signature sets an expiration time. After it passes, the verifier rejects the signature even if it's otherwise valid. Expiration typically occurs with messages delayed in queues (graylisting — temporary rejection prompting redelivery) or during temporary recipient errors.

Most configurations don't use x=. If you have it set and see DKIM fail on delayed messages, consider extending the expiration period or removing the x= tag.

Weak or Unsupported Algorithm

RFC 8301 requires senders to use at least 1024-bit RSA keys and recommends (SHOULD) at least 2048 bits. Signatures must use the rsa-sha256 algorithm. Older configurations may use:

• 1024-bit RSA keys — most verifiers still accept them, but they're considered insufficient; upgrading to 2048 bits is recommended
• rsa-sha1 — deprecated hash algorithm; RFC 8301 prohibits (MUST NOT) its use for both signing and verifying

Solution: regenerate the key with at least 2048 bits and use rsa-sha256 or ed25519-sha256.

How to Determine the Cause of DKIM Fail

Authentication-Results Header

The quickest way to diagnose a specific email. Find the Authentication-Results header in the received email — it contains the DKIM check result and the reason for failure:

DMARC Reports

Aggregate DMARC reports provide a summary of DKIM results across your entire domain — not just individual emails. Look for records with dkim=fail in the reports:

1. Identify the IP address — does it belong to your server or a known sending service?
2. Check the selector — does it match the configured selector?
3. Verify the domain — does d= match the domain in the From header?

If you have DMARC reports directed to SPF Monitor, you don't need to manually parse XML — the visualization shows problematic senders in one place.

Diagnosis via Analyzer

The SPF Monitor DKIM analyzer checks the DNS record for a given selector and domain:

• Record existence in DNS
• Syntax and validity of the public key
• Key type and length
• Key status (valid / revoked)

For a complete check, send a test email and inspect the headers — the analyzer verifies DNS but can't see whether the server actually signs messages or whether the message passes through a system that modifies it in transit.

Solutions by Failure Type

Preventing DKIM Failures

• Use relaxed/relaxed canonicalization — tolerates common transit modifications and minimizes false positive failures.
• Sign after all modifications — DKIM signing must be the last step before sending. If you have antispam, disclaimers, or other filters, place them before DKIM.
• Monitor DKIM results — regularly check DMARC reports. DKIM failures can appear suddenly — after a server update, DNS change, or filter rule modification.
• Rotate keys safely — when rotating, first publish the new key in DNS, switch the server to the new selector, and only revoke the old key after verifying the new one works. Never revoke a key before the new one is fully operational.
• Use at least 2048-bit RSA keys — RFC 8301 recommends this (SHOULD). The mandatory minimum is 1024 bits, but 2048 bits is today's standard. ed25519 keys offer better performance, but verifier support is still limited.
• Verify after every change — after a DNS migration, mail server change, or adding a new sending service, always verify the DKIM record and send a test email.

Run a complete analysis of your domain to check SPF, DKIM, and DMARC configuration in one place.