How to Fix “DKIM Signature Is Not Valid” and “Body Hash Not Verified” Errors

If you received the “DKIM signature is not valid” error, there’s a problem with your DKIM configuration that needs fixing. These errors usually come down to an incorrect DKIM DNS record entry, delays in DNS propagation, errors during DKIM signature evaluation, or alterations made to the message after it was signed. 

This guide walks through each cause and its fix, with a dedicated section on the closely related “DKIM-signature body hash not verified” error, which points to a specific and very fixable problem.

About DKIM Signatures

DKIM adds a cryptographic signature to your email headers, and the receiving server checks that signature against a public key published in your DNS. If the two don’t match, you get the “DKIM signature is not valid” error. For a full explanation of how the protocol works, see our guide on what DKIM is.

Since most people hitting this error already have DKIM set up and just need to fix what broke, the rest of this page focuses on diagnosis and fixes rather than fundamentals.

When Can DKIM Fail with “Your DKIM Signature Is Not Valid” Error?

You’ll see the “Your DKIM signature is not valid” message when the DKIM authentication check fails. Here are the common reasons:

• The DKIM signature domain and sender domain don’t align.
• The DKIM public key record published in DNS isn’t correct.
• The DKIM public key record isn’t published in DNS at all.
• The server fails to reach the sender’s domain DNS zone for lookup, a common situation with unreliable hosting providers.
• The DKIM key length is insufficient. Modern providers expect 2048-bit keys, and older 1024-bit keys are increasingly distrusted, while very short keys are rejected outright.
• The message was modified during auto-forwarding.

All of these, except the last one, are technical issues you can resolve directly. The forwarding case is different, because you can’t control whether a recipient’s server appends a compliance footer or otherwise rewrites the message. So what happens when those auto-forwarded messages fail both SPF and DKIM, and your DMARC policy is set to reject?

This used to be a genuine problem for receiving servers trying to handle legitimate but unauthenticated forwarded mail. The current stopgap is the Authenticated Received Chain (ARC) protocol, which lets each mail server in the chain record the authentication results it saw, so the final recipient can still recognize that the message was authenticated before forwarding modified it. ARC was always an experimental workaround, though, and the industry is now moving past it. A separate April 2026 IETF draft has proposed reclassifying ARC as a historic standard, because its lessons are being folded into DKIM2, a new version of DKIM being developed at the IETF (draft-ietf-dkim-dkim2-spec) that fixes forwarding within the core protocol rather than bolting a second mechanism on top. Instead of asking receivers to trust an intermediary’s account of what it saw, DKIM2 has each hop record exactly what it changed as a reversible recipe, so the verifier can undo those changes and re-check the original sender’s signature. That’s still being standardized, so ARC remains the practical answer today, but it’s worth knowing the forwarding problem has a real fix on the way.

How to Fix the “DKIM Signature Is Not Valid” Error

Even with DKIM records in place, you can still see an invalid signature error. Here are the fixes, matched to each cause listed above.

Fix 1: Troubleshoot Incorrect DKIM DNS Entries

Once you’ve created the DKIM TXT record and added it to your DNS configuration, an invalid signature error often traces back to a mistake in that record. To find it:

• Use PowerDMARC’s DKIM lookup to check your record.

• Enter your domain name and selector, or leave the selector blank to let the platform auto-detect it, then click Check.

• The tool analyzes your DKIM DNS entry and highlights any errors in your record syntax.

To fix the record, log in to cPanel or whichever DNS management console you use, open the Advanced DNS Zone Editor under Domains, select your domain, go to Edit DNS Records, correct the DKIM record value, and save.

Fix 2: Wait Out DNS Propagation Delays

You can also see errors right after changing your DNS settings. This is normal: DNS propagation takes up to 24 to 48 hours, and the exact time depends on the TTL value set in the record. Give it a few days to propagate fully, and in the meantime, track the status with our DNS propagation checker.

Fix 3: Realign the DKIM Signature Domain with Your Sending Domain

Open the DKIM-Signature header on a failing message and check the d= value against your visible From address. If they don’t match, your sending service is signing with its own domain rather than yours, which breaks alignment and fails the check. The fix is to configure that service to sign with your domain. Most email platforms have a “custom DKIM” or “authenticate your domain” setting for exactly this, and our guide on how to set up DKIM covers the process.

Fix 4: Regenerate a Key That’s Too Short

If your provider is still signing with a 1024-bit (or shorter) key, regenerate it at 2048 bits, which is the current standard that Google and other major providers expect. You can generate a new key pair in your ESP’s admin console or with our DKIM generator, publish the new public key to your DNS, and confirm it resolves correctly using our DKIM record lookup tool.

Fix 5: Resolve a DNS Server That Can’t Be Reached

If the receiving server can’t reach your DNS to look up the public key, DKIM fails no matter how well everything else is configured. Test whether your record is reachable with a DNS propagation checker. If your hosting provider’s DNS is slow or unreliable, consider moving DNS hosting to a dedicated provider such as Cloudflare or Amazon Route 53.

Fix 6: Handle Messages Modified During Auto-Forwarding

orwarding modifications break DKIM, and there isn’t always a sender-side fix. If you control the forwarding server, enable ARC signing (and in Microsoft 365, add reputable forwarders to your Trusted ARC Sealers list in Defender) so legitimate forwarded mail isn’t discarded. If you don’t control it, this is expected behavior, not a misconfiguration: your DMARC aggregate reports will show these failures, and the right move is to account for them in your policy and keep monitoring rather than chase everyone.

Note: ARC is a temporary fix and not a permanent solution. DKIM2 is being designed to fix forwarding at the protocol level, so this whole category of failure should shrink as it rolls out. Keep any existing ARC setup running to support legacy gateways in the meantime, but there's little reason to invest heavily in new ARC engineering now.

Why Do You See “DKIM-Signature Body Hash Not Verified”?

The “DKIM-signature body hash not verified” error means the body hash the receiving server calculates doesn’t match the value stored in the bh= tag of the DKIM-Signature header. In plain terms, the body of the email that the receiver checked is not identical to the body your server signed. Something changed the message in between.

This is worth understanding precisely, because it’s frustratingly common and it usually means your DKIM setup is otherwise correct. The body hash check happens before the full signature check, so when the body hash fails, the entire DKIM evaluation fails, and the receiver won’t even move on to verifying the cryptographic signature itself.

Common Causes of Body Hash Failures

• An email gateway or filter added content after DKIM signing: Disclaimers, legal footers, tracking pixels, unsubscribe blocks, antivirus banners, and marketing footers inserted by an outbound gateway after the message was already signed will all change the body and break the hash. This is the single most frequent cause.
• A mailing list or forwarding server modified the body: Mailing list software routinely appends unsubscribe footers or rewrites the subject line, and forwarding servers can strip or add headers. Both alter the signed content.
• A character encoding or line-ending mismatch: If the message is signed using one encoding (for example, UTF-8 with a byte-order mark) and the receiving server interprets it differently, or if line endings shift between CRLF and LF somewhere in transit, the byte-level content no longer matches, and the hash fails.
• DKIM signing happens too early in the outbound mail flow: This is the root cause behind most of the above. If your system signs the message before a downstream component modifies it, the body hash will fail every time.
• An incorrect or rotated private key: If the signing key no longer matches the public key published in DNS, verification fails.

How to Diagnose a Body Hash Failure

Work through these steps to narrow down where the modification is happening:

1. Send the same test message to Gmail, Outlook, or Hotmail, and one internal mailbox. Keep the content, links, and route identical across all three.
2. Check the Authentication-Results header at each receiver. If the body hash fails at all three, the problem is on your sending side. If it fails only at one (Outlook is the usual culprit), the issue is more likely MIME structure or character encoding than your signing configuration.
3. Review your mail flow order and confirm whether DKIM signing happens before or after any outbound content modification.
4. Verify the DKIM DNS record, confirming the selector and public key match what’s in the failing signature, using our DKIM record lookup tool.
5. Send a plain-text test with no tracking, footer, or attachments. If that message passes where your normal mail fails, you’ve identified the modification by elimination.

How to Fix Body Hash Failures

• Sign the message last, after every content modification: This is the most common and most effective fix. Change the order from “compose, DKIM sign, add disclaimer, send” to “compose, add disclaimer, DKIM sign, send,” so you’re signing the exact message the recipient will receive.
• Configure outbound gateways not to modify the message body: Or set them to re-sign with DKIM after they’ve finished making changes.
• Standardize your encoding to UTF-8 without a byte-order mark and keep CRLF line endings stable throughout the send path. This matters most for Exchange and Microsoft 365 environments.
• Use relaxed canonicalization (c=relaxed/relaxed): This tolerates minor whitespace and formatting differences that would otherwise break a signature under strict “simple” canonicalization. It won’t rescue a signature when a whole disclaimer or footer is added, but it eliminates failures caused by trivial formatting changes.

Outlook and Microsoft 365-Specific Body Hash Failures

A recurring pattern, and one that fills Microsoft’s own support forums, is a message that passes DKIM at Gmail and Yahoo but fails at Outlook or Hotmail. This usually shows up on messages that contain attachments or embedded images, and it points to how Microsoft’s system handles MIME structure and character encoding rather than a problem with your signing setup.

The clearest way to confirm this is to compare the Authentication-Results header of the same message at both receivers. The pass and fail look like this:

None

# At Gmail (passes)

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1;
spf=pass; dmarc=pass

# At Outlook (fails on the identical message)

Authentication-Results: protection.outlook.com;
dkim=fail (body hash did not verify)
header.d=yourdomain.com header.s=selector1;
spf=pass; dmarc=fail (p=none)

When you see a DKIM failure, the fastest way to understand it is to read the message’s own authentication headers rather than guessing at the cause.

How to Read the Authentication-Results Header

In Gmail, open the message, click the three-dot menu, and select “Show original.” Find the Authentication-Results header and look for the dkim= result. It will read pass, fail, or neutral, and it’s usually followed by a reason string such as “body hash did not verify,” “signature did not verify,” or “key too short.” That reason string tells you which category of problem you’re dealing with, and therefore which fix above applies.

While you’re reading the header, the DKIM-Signature tags are useful reference points:

v=  DKIM version (e.g., v=1)

a=  signing algorithm (e.g., a=rsa-sha256)

d=  signing domain (check this against your From address for alignment)

s= selector, used to locate the public key in DNS

h= the headers included in the signature

bh= the body hash (the value that fails in a “body hash not verified” error)

b=  the cryptographic signature itself

Comparing the d= value against your visible From domain confirms alignment, the s= selector tells you which DNS record to check, and a bh= mismatch confirms the body was altered after signing.

If the source turns out to be one you don’t recognize, check whether it belongs to your authorized senders, review it against your DMARC failure reports to see what kind of mail it’s sending, and check whether the IP appears on any blacklists. 

If it’s a legitimate sender, set up DMARC correctly to authorize it. If it isn’t, that’s a spoofing signal worth acting on.

I’ve Fixed the “DKIM Signature Is Not Valid” Error. What Next?

To strengthen your DKIM setup from here:

1. Sign up with our Hosted DKIM to monitor your DKIM authentication results over time.
2. Enable SPF and DMARC for additional security and more accurate authentication.
3. Rotate your DKIM keys periodically for stronger protection.

I Still Can’t Fix the Error

If the DKIM signature not valid error persists, reach out to your email service provider for guidance, or contact us for expert advice on everything email authentication.

Frequently Asked Questions

What does “DKIM-signature body hash not verified” mean? 

It means the body hash the receiving server calculated doesn’t match the bh= value your server recorded when it signed the message. In practice, the email body was changed after signing, most often by a disclaimer, footer, tracking pixel, or gateway modification added later in the send path.

Why does the DKIM body hash fail only in Outlook but pass in Gmail? 

When a message passes at Gmail but fails at Outlook or Hotmail, the cause is usually how Microsoft’s system handles MIME structure and character encoding rather than your signing configuration. It shows up most often on messages with attachments or embedded images. Compare the raw source at both receivers, standardize your transfer encoding, and use relaxed canonicalization.

How do I make DKIM signing happen after disclaimers are added? 

Reorder your outbound mail flow so signing is the last content-changing step. Instead of signing and then appending a disclaimer, append the disclaimer first and sign afterward. You can achieve this by running your DKIM signer after content filters and disclaimer or signature services, so it signs the final message the recipient actually receives.

What’s the difference between “body hash did not verify” and “signature did not verify”? 

“Body hash did not verify” means the message body changed after signing, so the fix is a body or mail-flow fix. “Signature did not verify” is broader and often points to a signed header change, a key mismatch, or a DNS or key problem. The reason string in the Authentication-Results header tells you which one you’re dealing with.

Does DKIM filter email? 

DKIM doesn’t filter email directly. It provides a pass or fail signal that receiving servers factor into their own spam-scoring decisions. Mail that passes DKIM from a trusted domain may see a lower spam score, while a DKIM failure can contribute to a message being marked as spam or quarantined.

Can I ignore DKIM failures if DMARC is set to p=none? 

At p=none, failing mail is still delivered, so a DKIM failure won’t block anything immediately. But ignoring it defeats the purpose of moving toward enforcement, and it leaves you unable to trust your own authentication data. It’s better to resolve failures while at p=none so you can safely progress to p=quarantine and p=reject later.

How often should I rotate DKIM keys? 

A common practice is rotating keys every six months to a year. Regular rotation limits the damage if a private key is ever exposed. The important part is updating the published public key in DNS as part of the rotation, since a rotated key that isn’t reflected in DNS will itself cause signature failures.

• About
• Latest Posts

Yunes Tarada

Domain & Email Security Expert at PowerDMARC

Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.

Latest posts by Yunes Tarada (see all)

• How to Fix “DKIM Signature Is Not Valid” and “Body Hash Not Verified” Errors - July 16, 2026
• Kit DKIM, DMARC, and SPF Setup Guide - July 6, 2026
• NIST SP 800-81r3: DNS Security Guidelines for Email - June 25, 2026