DKIM Signature Did Not Verify: Causes and How to Fix It

Quick answer

Signature did not verify means the receiver checked the b= signature in the DKIM-Signature header against the public key and they didn't match. Unlike body hash did not verify, the body usually isn't the problem. Unlike no key for signature, a key was found. That leaves two kinds of cause:

1. A signed header changed after signing. A gateway tagged the Subject, a mailing list rewrote From, a relay re-folded a header under simple header canonicalization, or a header the signer had locked (oversigned) was added.
2. The key doesn't match. The signer uses a private key whose public half isn't the one published at the selector, for example after a key rotation, a server rebuild, or while resolvers still hold an old record.

To tell them apart, check whether every message from that signer fails (usually the key) or only mail that went through a particular hop (usually a header change).

What the error means

RFC 6376 section 6.1.3 describes verification in steps. The verifier canonicalizes the message using c=, l= and the header names in h=, computes the hashes, then:

1. compares the body hash with bh=; if it doesn't match, the verifier SHOULD ignore the signature and return PERMFAIL (body hash did not verify);
2. checks the b= signature against the header hash using the public key and the algorithm in a=; if it doesn't validate, the verifier SHOULD ignore the signature and return PERMFAIL (signature did not verify).

In that order, reaching the second check means the body hash matched, so the fault is in what the header hash covers or in the key. The RFC lets implementations verify the header signature before the body hash, so treat this as a strong hint rather than proof, and compare the body as well if a footer is possible. The words in brackets are explanations, not fixed strings, and receivers word their comments differently.

What the header hash covers (h=)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=s2024; h=from:to:subject:date:message-id:from;
  bh=<base64 body hash>; b=<base64 signature>

RFC 6376 section 3.7 says the header hash is computed over:

1. the header fields named in h=, in the order listed, each canonicalized with the header algorithm from c=; then
2. the DKIM-Signature header itself, with every tag included (even unknown ones) and only the value of b= treated as empty.

The private key signs that hash into b=. Rules that matter when you debug it (RFC 6376 sections 3.5, 5.4 and 5.4.2):

• h= is required, can't be empty, and must include From; a signature without From in h= is ignored with PERMFAIL (From field not signed).
• Header names are matched case-insensitively. A name listed in h= that isn't in the message counts as an empty input, which lets a signer assert that the header is absent: if it is added later, the signature fails.
• When a header occurs more than once, the signer signs the physically last instance first and works upwards; listing a name twice signs two instances. Listing a name one more time than it appears (for example h=from:...:from with one From header) prevents any further instance from being added. This is often called oversigning; RFC 6376 section 8.15 uses h=from:from:... as its example.
• Headers that aren't in h= aren't signed, so adding or changing them (a new X- header, an extra Received line) doesn't break the signature.

Header canonicalization: simple vs relaxed

The first half of c= is the header algorithm. If c= is missing the default is simple/simple (RFC 6376 section 3.5).

Neither algorithm tolerates a changed value: a word added to the Subject, a different address in From, a rewritten Date. With simple, a relay that re-wraps a long Subject or To header, or changes Subject: to SUBJECT:, is enough to break the signature.

Common causes: headers changed in transit

• Subject tagging. A gateway, mail-flow rule or mailing list that prefixes the Subject with a tag such as [EXTERNAL], [SPAM] or a list name changes a header that signers are advised to include (RFC 6376 section 5.4 highly advises signing Subject), so the signature breaks whenever Subject is in h=.
• From rewriting. From MUST be signed (section 5.4), so a mailing list or forwarder that rewrites From, for example to the list's own address, always breaks the original signature. Only a new signature from the intermediary's own domain can cover the rewritten message.
• Other signed headers rewritten. Any relay that rewrites a header listed in h= (To, Cc, Reply-To, Date, Message-ID, the MIME headers) breaks the signature in the same way. Section 5.4 tells signers not to sign headers likely to be legitimately modified or removed in transit, such as Return-Path.
• Headers added that the signer locked. If the signer oversigned a name (or listed one that was absent, such as Reply-To or a List-* header), a hop that adds that header breaks the signature. That is the intended protection, so the fix is in the forwarding path, not the signer.
• Re-ordered headers. RFC 6376 section 5.4 notes that RFC 5322 only prohibits re-ordering trace fields (such as Received) and Resent-* blocks. Sections 5.4 and 8.12 warn that re-ordering signed headers that occur more than once breaks signatures, and that signing existing DKIM-Signature headers is error-prone because MTAs may re-order them.
• Re-folding or case changes with c=simple. Line-wrapping, whitespace and header-name case changes only break signatures that use simple header canonicalization.
• The DKIM-Signature header itself altered. Every tag in it is part of the header hash, so a hop that edits, re-wraps (under simple) or truncates the DKIM-Signature header breaks it.
• Signed Authentication-Results removed. RFC 8601 section 5 requires a receiving MTA to remove Authentication-Results headers that claim to come from inside its own trust boundary but didn't arrive from a trusted MTA, and notes that this can invalidate signatures that covered them.

Common causes: the key doesn't match

• Wrong private key on the signer. The server or service signs with a private key whose public half was never published at that selector: a new key generated during a rebuild or migration, a key file copied from another server, or several signing servers sharing one selector with different keys. Every message from that signer fails, while the body hash still matches.
• Key rotated without updating DNS, or DNS updated too early. RFC 6376 section 3.1 describes rotation by selector: publish the new public key under a new selector, switch signing to it, keep both keys published for a transition period while signed mail may still be in transit, then remove the old one. Section 5.2 adds that the old public key should be kept for a reasonable validation interval, because verifiers can defer checking.
• A selector reused for a new key, with stale caches. If you replace the key at an existing selector, resolvers that cached the old record keep returning it until its TTL runs out, so messages signed with the new key fail against the old key, and old mail still in transit fails against the new one. RFC 6376 section 3.1 calls reusing a selector for a new key ill-advised for this reason: a failure can no longer be told apart from a forgery. Assign new keys to new selectors.
• More than one key record at the selector. Section 6.1.2 lets a verifier pick any one of several key records, in no defined order, so a stale record left beside the new one can make verification fail some of the time, depending on which record the verifier uses.
• Hosted keys: the record doesn't point where the provider expects. Microsoft 365 and Google Workspace hold the private key themselves. If the selector CNAME or TXT record doesn't match what your admin console currently shows (for example after a new key was generated in the console), copy the value again; see DKIM for Microsoft 365 or SPF, DKIM and DMARC for Google Workspace.

Common causes: algorithm and key length

• rsa-sha1. RFC 8301 section 3.1 says signers MUST sign using rsa-sha256, and rsa-sha1 MUST NOT be used for signing or verifying; signatures made with it have permanently failed evaluation. Not every receiver enforces this the same way, but a signature with a=rsa-sha1 should be treated as failing. RFC 8601 registers header.a so a receiver can report the algorithm and make such signatures easy to spot.
• Short RSA keys. RFC 8301 section 3.2 says signers MUST use RSA keys of at least 1024 bits and SHOULD use at least 2048 bits, verifiers MUST be able to validate keys from 1024 to 4096 bits, and verifiers MUST NOT consider signatures with RSA keys under 1024 bits valid. A 512-bit or 768-bit key fails no matter how correct the signature is.
• a= and k= don't fit. The key record's k= (default rsa) must suit the signature's a=; if not, RFC 6376 section 6.1.2 says PERMFAIL (inappropriate key algorithm). If the key record has an h= tag that doesn't list the signature's hash (for example h=sha1 with a=rsa-sha256), it is PERMFAIL (inappropriate hash algorithm). Receivers may report these as fail, policy or permerror.

Step 1: Read Authentication-Results and find the hop

Open the received copy (view the original or the message source) and paste the full headers into the Email Header Analyzer. An illustrative example of what to look for (your receiver's wording will differ):

Authentication-Results: mx.receiver.example;
  dkim=fail (signature did not verify) header.d=example.com
    header.s=s2024 header.a=rsa-sha256 header.b=AbCdEf12;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass header.from=example.com

• Use the right Authentication-Results header. RFC 8601 section 4.1 says the header is prepended (added at the top) and must not be re-ordered, so the topmost one is normally from the last receiver. Each one starts with an authentication service identifier (here mx.receiver.example) naming who did the check. Trust only the ones added by your own receiving system; earlier ones were added by other hops and could be forged.
• Identify the signature. header.d is the signature's d= and header.s its selector. header.a (registered by RFC 8601) shows the algorithm, and header.b (RFC 6008) gives at least the first eight characters of b=, which tells two signatures from the same domain apart.
• Find where it last passed. If an intermediary (a forwarder, list or gateway) added its own Authentication-Results or an ARC-Authentication-Results header showing dkim=pass for the same signature, the change happened at that hop or later. Use the analyzer's route table (oldest hop first) to list every server between the signer and the receiver.
• Here DMARC still passes only because SPF passed and aligned. Once the message is forwarded, SPF usually fails too, so a broken signature turns into a DMARC failure.

Step 2: Compare the signed headers with what was sent

1. Copy the h= list from the failing signature and, for each name, compare the received header with your sent copy (or a copy taken before the suspect hop). Look for a Subject tag, a changed From or Reply-To, rewritten addresses, a different Date or Message-ID.
2. Count instances: if a header listed in h= now appears more often than when it was signed, or a name in h= was absent when signed but is present now, a hop added it.
3. Check the first half of c=. With simple, look for re-wrapped lines or changed case in the signed headers too.
4. Isolate the path: send a test straight from the signing platform to an outside mailbox, skipping the list, forwarder or gateway. If that copy passes, the skipped hop is the cause; if it fails too, check the key (Step 3).

Step 3: Check that the published key matches the signer

# The key the receiver sees (compare several resolvers)
dig +short TXT s2024._domainkey.example.com
dig @1.1.1.1 +short TXT s2024._domainkey.example.com
dig @8.8.8.8 +short TXT s2024._domainkey.example.com
dig TXT s2024._domainkey.example.com +noall +answer

# The public half of the RSA private key your own signer uses
openssl rsa -in /path/to/dkim-private.pem -pubout -outform DER | openssl base64 -A

# Windows
Resolve-DnsName -Name s2024._domainkey.example.com -Type TXT

• The openssl output should match the p= value once the quoted strings in the TXT answer are joined with no spaces. If it doesn't, the signer and DNS disagree: publish the matching key under a new selector, or point the signer at the right private key.
• The +noall +answer form shows the remaining TTL. Different answers from different resolvers mean a recent change is still being cached; wait at least that long, or better, use a new selector.
• Exactly one TXT record should come back. Decode it with the DKIM Record Explainer to check k=, any h= tag and the key length, and run the domain through the DKIM Checker with the selector from s=.
• For Microsoft 365, Google Workspace or another hosted sender you can't see the private key, so compare the record with what the admin console shows instead.

Fixes

• Sign after the last header change. If your own gateway or a rule adds a Subject tag, disclaimer header or rewritten address after your mail platform signs, have the last hop sign with your domain instead (usually with its own selector), or make the change before signing. Exempt outbound signed mail from Subject tagging rules.
• Tag inbound mail after authentication, not before. When your own inbound gateway tags the Subject before the mailbox platform checks DKIM, the mailbox sees a broken signature. Check authentication at the first hop, or have the gateway add ARC and configure the mailbox platform to trust it if both support it (RFC 8617, Experimental). The body hash guide covers ARC and inbound gateways in more detail.
• Use relaxed header canonicalization. c=relaxed/relaxed survives header re-wrapping and whitespace or case changes that break simple. It doesn't help with changed values.
• Sign the right headers. Always sign From (required) and, as RFC 6376 advises, Date, Subject, Reply-To, Sender and the MIME headers. Don't sign headers that are routinely modified in transit, such as Return-Path and Received, and avoid signing existing DKIM-Signature headers.
• Republish or rotate the key properly. Publish the public key that matches the signer's private key, keep one key record per selector, give every signing server for a selector the same key, and rotate to a new selector instead of replacing a key in place. Keep the old key published until mail signed with it has had time to be verified.
• Move off rsa-sha1 and short keys. Sign with rsa-sha256 and a 2048-bit RSA key, as RFC 8301 recommends. If your DNS host can't store a 2048-bit key in one string, split it into several quoted strings in the same TXT record; see no key for signature for how that goes wrong.
• Keep aligned SPF as a second route to DMARC. You can't stop other people's lists and forwarders rewriting From or Subject. A custom return-path on each sender keeps DMARC passing for direct mail; see the DMARC alignment guide and check it with the SPF Record Checker.

Verify the fix

1. Confirm the selector's key with the DKIM Checker and decode it with the DKIM Record Explainer: one record, k=rsa, 2048 bits, no h= tag that excludes sha256.
2. If you changed or added a key record, check it from many public resolvers with the DNS Propagation Checker before relying on it.
3. Send a new message through each path (direct, through the gateway, through the list or forwarder) to an outside mailbox, paste its headers into the Email Header Analyzer, and look for dkim=pass with header.d set to your domain and dmarc=pass. A message that already arrived keeps its old result.
4. Watch a week of aggregate reports in the DMARC Report Analyzer and check the policy with the DMARC Record Checker; every source should show DKIM pass for your d= domain.

Audit hundreds of domains at once

Need SPF, DMARC and MX checks across a whole client list? Run the Bulk SPF / DMARC / MX Auditor on Apify ($2 per 1,000 domains).

Related tools and guides

Read d=, s=, h= and each DKIM result with the Email Header Analyzer, check published selectors and key length with the DKIM Checker, decode a key record with the DKIM Record Explainer, confirm a key change across resolvers with the DNS Propagation Checker or query it with DNS Lookup. Related guides: DKIM body hash did not verify, DKIM no key for signature, DKIM for Microsoft 365, SPF, DKIM and DMARC for Google Workspace and DMARC fail with SPF pass (alignment).

FAQ

What does DKIM signature did not verify mean?

The receiver found the public key and checked the b= signature against the hash of the signed headers, and they did not match. RFC 6376 calls this PERMFAIL (signature did not verify). Usually a header listed in h= changed after signing, or the published key does not match the private key the signer used.

How is signature did not verify different from body hash did not verify?

Body hash did not verify means the message body no longer matches the bh= hash, so something changed the body. Signature did not verify is the next check in the RFC order: the body hash matched, but the b= signature over the signed headers and the DKIM-Signature header failed, which points to changed headers or a key mismatch.

Can a Subject tag like [EXTERNAL] break DKIM?

Yes, if Subject is in the h= list, which it almost always is. Any change to the value of a signed header breaks the signature, whatever the canonicalization. Relaxed header canonicalization only tolerates whitespace, line wrapping and header name case changes.

Why did DKIM start failing right after I rotated the key?

The signer and DNS disagree. Either the signer switched to the new private key before the new public key was visible, or the key was replaced at the same selector and resolvers still cache the old record. RFC 6376 recommends a new selector for each new key and keeping the old key published during the transition.

Is rsa-sha1 or a 1024-bit DKIM key still acceptable?

rsa-sha1 is not: RFC 8301 says it must not be used for signing or verifying. RSA keys of 1024 bits are still the minimum signers must use and verifiers must accept, but RFC 8301 says signers should use at least 2048 bits. Keys under 1024 bits must not be considered valid.

Want the full kit?

Runbooks, checklists and helpdesk templates: IT Admin Packs on Gumroad.