DKIM Fail: What Each Error Means and How to Fix It

DomainKeys Identified Mail (DKIM) is one of the fundamental pillars of email authentication. By attaching a cryptographic signature to outgoing messages, DKIM allows receiving mail servers to verify that an email was genuinely authorized by the domain owner and that its contents were not tampered with during transit.

However, when a receiving server inspects an incoming email and encounters a dkim=fail status in the header, authentication breaks. A DKIM failure signals to receiving gateways like Google Workspace, Microsoft 365, or Apple Mail that either the message body was modified after leaving the sender, the public key could not be retrieved from DNS, or the cryptographic signature itself is invalid.

Depending on your domain’s DMARC policy and receiver security settings, DKIM failures can cause legitimate business emails to land in spam folders or get rejected entirely. This guide acts as an explicit error-message reference to help you diagnose the exact failure string in your email headers, identify the root cause, and resolve the issue quickly.

Common Reasons for DKIM Failure

While DKIM validation failures ultimately stem from a hash mismatch or key retrieval failure, the real-world operational causes usually fall into several predictable categories. Cross-referencing these underlying causes against the specific error string in your email headers will point you directly to the solution.

1. Message Modifications by Email Gateways and Security Appliances

The most frequent cause of DKIM failure in corporate environments is an intermediate service modifying message content after the DKIM signature has already been applied. Security appliances, outbound gateways, anti-spam filters, and data loss prevention (DLP) tools often alter outgoing messages by appending corporate footers, injecting tracking links, re-encoding character sets, or modifying MIME boundaries. 

If signing happens at the primary mail server prior to passing through these appliances, the body hash calculated by the receiver will not match the original signature, triggering a dkim=fail (body hash did not verify) error.

2. Mailing Lists and Automated Email Forwarding

When an email is sent to a mailing list or auto-forwarded across intermediate mail transfer agents (MTAs), the forwarding server frequently alters message headers (such as Subject or To) or appends mailing list management footers (such as unsubscribe links or list disclaimers). Because the cryptographic signature covers these components, any post-signing change invalidates the verification check. 

While modern protocols like Authenticated Received Chain (ARC) help forwarders preserve authentication state, raw DKIM checks on forwarded messages frequently fail.

3. Missing, Misconfigured, or Truncated DNS TXT Records

Receiving mail servers must fetch your public key from a specific DNS TXT record located at selector._domainkey.yourdomain.com. If this DNS record is missing, published under an incorrect selector name, or delayed by DNS propagation, the receiver cannot retrieve the key, producing a dkim=fail (no key for signature) error.

Furthermore, a specific and common issue occurs with 2048-bit RSA keys. Under RFC 1035, an individual string within a DNS TXT record is limited to 255 bytes. A base64-encoded 2048-bit RSA key is roughly 392 characters long. If your DNS provider or administrator pastes a 2048-bit key as a single unquoted string, older DNS management tools may truncate the key payload, leading to an incomplete public key in DNS and causing a dkim=fail (signature did not verify) error.

4. Key Mismatches, Unannounced Key Rotation, and Provider Migrations

For DKIM verification to succeed, the private key used by the sending mail server to generate the signature must mathematically correspond to the public key published in your DNS. A cryptographic mismatch occurs if:

• The signing mail server generates a new private key, but the DNS record is not updated simultaneously.
• An Email Service Provider (ESP) rotates their signing keys without updating your published TXT record or CNAME target.
• A domain is migrated to a new hosting platform while the email server continues signing with an old selector or retired key pair.

5. Syntax Errors in DNS Records and Strict Canonicalization Settings

Small formatting flaws in the public key record (such as missing semicolons, stray spaces inside the base64 key payload, or incorrect tag names) render the public key unparseable by receiving MTAs. 

Similarly, if your signing server uses simple canonicalization for headers or body content (c=simple/simple), even minor line-ending conversions (CRLF vs. LF) or trailing whitespace adjustments introduced by transit relays will break verification.

Review DKIM record syntax.

6. You have not set up DKIM for your third-party email vendors

If you use several third-party email vendors to send emails on behalf of your organization, you need to get in touch with them for instructions on how to activate DKIM for your outbound emails. If you are using your own custom domains or subdomains registered on this third-party service to send emails to your customers, be sure to request your vendor to handle DKIM for you.

Ideally, if your third-party vendor is helping you outsource your emails, they would set your domain up by publishing a DKIM record on their DNS using a DKIM selector that is unique to you, without you having to intrude.

OR, 

You can generate a DKIM key pair and hand over the private key to your email vendor while publishing the public key on your own DNS. 

Misconfigurations in the same can lead to DKIM failure, so you must communicate openly with your service provider regarding your DKIM setup. 

Note: Some third-party exchange servers induce formatted footers in the message body. If these servers are intermediary servers in an email forwarding process, the conjoined footer can be a contributing factor to DKIM failure. 

7. Problems in server communication

In certain situations, the email might be sent from a server that has DKIM disabled on it. In such cases, DKIM will fail for that email, even if other servers in your infrastructure are correctly configured. It is important to ensure that communicating parties have DKIM properly activated. 

8. DNS outage / DNS downtime

This is a common reason for DKIM failures. DNS outage may occur due to a variety of reasons including denial of service attacks. Routine maintenance of your name server may also be the reason behind a DNS downtime. During this (usually short) period of time, recipient servers cannot perform DNS queries. 

As we know that DKIM exists in your DNS as a TXT/CNAME record, the client-server performs a lookup to query the sender’s DNS for the public key during authentication. During an outage, this is deemed not possible and hence may break DKIM. 

9. Using OpenDKIM

OpenDKIM is an open-source DKIM implementation that can be deployed on your own mail server to sign and verify outgoing email. When using a self-hosted OpenDKIM setup, the service typically communicates with the mail server through port 8891.

To ensure OpenDKIM is working correctly, you can use an online port checker to verify that port 8891 is open and accessible on your server. You should also check that the required permissions are configured correctly. Incorrect permissions can prevent OpenDKIM from accessing its socket or binding to it properly.

Check your server configuration and the directory containing the OpenDKIM socket to make sure the directory exists and has the appropriate ownership and permissions.

10. DKIM Check for alignment failure

If you have DMARC set up for your domain in addition to DKIM, during DKIM check, the domain value in the d= field on the DKIM signature in the email header has to align with the domain found in the From address. It can either be a strict alignment, wherein the two domains have to be an exact match or a relaxed alignment that allows an organizational match to pass the check. 

A DKIM failure can occur if the DKIM signature header domain doesn’t match the domain found in the From header, which might be a typical case of domain spoofing or impersonation attack. 

DKIM Fail Errors Explained (By Error Message)

Find your exact error below to understand what the receiving server encountered and how to resolve it.

dkim=fail (body hash did not verify)

The dkim=fail (body hash did not verify) error indicates that the public key was successfully retrieved from DNS and the overall signature header was formatted correctly, but the cryptographic hash of the message body calculated by the recipient does not match the hash value stored in the signature’s bh= tag.

In plain terms, the body of the email was modified after the sending server signed it.

Primary Causes:

• Outbound security gateways, disclaimer tools, or CRM plugins appended legal disclaimers, promotional footers, or tracking pixels after the signing stage.
• Intermediate relays modified line breaks, character sets, or whitespace in transit.
• Email forwarding or mailing list software modified the body payload.

How to Fix It:

1. Reorder your outbound mail flow so that DKIM signing is executed as the absolute final step before the message leaves your network infrastructure, ensuring all footers and tracking links are applied prior to signing.
2. Ensure your mail server uses relaxed body canonicalization (c=relaxed/relaxed or c=relaxed/simple), which tolerates minor whitespace and line-ending variations during transit.
3. If using an l= (length) tag in your DKIM headers, remove it. The l= tag restricts how much of the body is signed and creates security vulnerabilities while failing to resolve body modification issues.

dkim=fail (no key for signature)

The dkim=fail (no key for signature) error occurs when the receiving server extracts the domain (d=) and selector (s=) from the email’s DKIM-Signature header and attempts to query DNS at s=._domainkey.d=, but fails to retrieve a valid public key record.

This error narrows the problem down specifically to DNS configuration or selector misalignments.

Primary Causes:

• The selector name specified by your sending application does not match the selector prefix published in DNS.
• The TXT or CNAME record was never published on the authoritative DNS server.
• The DKIM record was published recently and has not fully propagated across global DNS resolvers.
• The public key record was accidentally deleted during a domain migration or key cleanup.

How to Fix It:

1. Inspect the raw email header to identify the exact selector string in the s= tag.
2. Confirm that a DNS TXT or CNAME record exists at selector._domainkey.yourdomain.com (for instructions on locating selector strings, see our detailed guide on how to find your DKIM selector).
3. Verify that the DNS record includes the mandatory v=DKIM1; and k=rsa; (or k=ed25519;) tags along with the p= public key payload.

dkim=fail (signature did not verify)

Unlike a body hash failure, the dkim=fail (signature did not verify) error means the cryptographic evaluation of the main signature string (the b= tag) failed. The receiver retrieved a public key from DNS, but that key failed to decrypt and verify the header signature payload.

This error points directly to an invalid key pair or modified header fields.

Primary Causes:

• Key Pair Mismatch: The private key used by the sending server to sign the message does not match the public key published in DNS under that selector.
• Truncated DNS Key: A 2048-bit key was published incorrectly as a single string over 255 bytes, causing the DNS server to truncate the public key data.
• Header Modification: An intermediate mail server or gateway altered headers explicitly included in the signature’s h= tag (such as From, To, Subject, or Date) after the signature was generated.

How to Fix It:

1. Check whether your 2048-bit public key record in DNS was split properly into multiple quoted strings under 255 bytes each.
2. Confirm that your private key on the mail server corresponds to the published public key. If unsure, generate a fresh key pair, update DNS, and verify alignment.
3. Ensure intermediate security appliances do not alter signed header fields in transit.

DKIM Soft Fail

In email authentication, “soft fail” is not a native DKIM protocol status. While SPF explicitly defines a SoftFail result (~all), RFC 6376 defines DKIM outcomes strictly as pass, fail, policy, neutral, temperror, or permerror.

When administrators or email security tools report a “DKIM soft fail,” they are typically referring to one of two scenarios:

1. DMARC Evaluation under p=none: A message fails DKIM authentication, but because the domain owner’s DMARC policy is set to monitoring mode (p=none), the receiving mailbox provider delivers the email to the inbox while marking the internal evaluation status as a soft failure.
2. Gateway-Specific Classification: Mail security gateways (such as Cisco Secure Email or Mimecast) sometimes output internal diagnostic labels like “soft fail” when an email fails DKIM, but SPF passes with proper DMARC alignment, meaning the overall message is permitted delivery.

If you encounter a “soft fail” label in logs, treat it as a standard DKIM failure and check your headers for the underlying RFC error string (body hash did not verify or no key for signature).

Other DKIM Errors You May See

Receiving mail servers may also output the following standardized DKIM diagnostic codes in their Authentication-Results headers:

DKIM Fails but SPF Passes (and Other Mixed Results)

When inspecting email deliverability reports, you will frequently see scenarios where protocol results conflict. Understanding how receiving gateways evaluate these combinations is essential for troubleshooting.

Under DMARC specifications (RFC 7489), an email achieves overall DMARC validation as long as at least one underlying protocol (SPF or DKIM) yields a PASS status and is properly aligned with the domain shown in the visible From: header.

Here is how common protocol combinations resolve during delivery:

Why Is My Message Blocked Due to DKIM?

If SPF passes but your message is still blocked or marked as spam due to a DKIM failure, one of two things is occurring:

1. SPF is Not Aligned: The SPF check passed for a third-party server domain (e.g., mail.mcsv.net), but did not match your actual From: header domain. Because SPF alignment failed and DKIM failed outright, DMARC failed.
2. Strict Provider Enforcement: Major receivers like Google and Microsoft enforce strict security policies for bulk senders. If an email demonstrates structural authentication failures alongside high spam complaint signals, receiver algorithms may block the message regardless of partial passes.

To understand how policy enforcement affects non-compliant emails, review our guide on what a DMARC policy is and test your domain using our free DMARC record checker.

How to Read DKIM Results in Your Email Headers

To identify your specific error string, you must view the raw Internet headers of a delivered test email.

Step 1: Access Raw Headers in Your Mail Client

• Gmail: Open the message, click the three vertical dots next to the Reply button, and select Show original.
• Microsoft Outlook (Web): Open the message, click the three dots in the action bar, select View, and click View message details.
• Apple Mail: Open the email, click View in the top menu bar, hover over Message, and select Raw Source.

Step 2: Locate the Authentication-Results Header

Scroll through the raw header text to locate the Authentication-Results block. Look for the dkim= entry.

A typical header entry exhibiting a failure looks like this:

Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) [email protected] header.s=s1 header.b=W8xKz2L;
spf=pass (google.com: domain of [email protected] designates 192.0.2.1 as permitted sender) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Key Header Tags to Inspect:

• dkim=: Displays the immediate verification status (pass, fail, permerror, etc.) followed by the explicit error string in parentheses.
• header.i=: Shows the identity/domain that signed the email.
• header.s=: Identifies the exact selector used to fetch the public key from DNS.
• header.d=: Indicates the organizational domain claiming responsibility for the signature.

Manually reviewing raw email headers can be complex, time-consuming, and overall inconvenient. You can skip the steps by using our free Email Header Analyzer tool for instant human-readable insights into your SPF, DKIM, and DMARC authentication results. 

How to Fix DKIM Failures and Prevent Them From Coming Back

Follow this systematic remediation workflow to resolve DKIM issues across your sending infrastructure:

1. Validate the Public Key in DNS

Use an online lookup tool like our DKIM Record Lookup to inspect the public key published at selector._domainkey.yourdomain.com.

• Ensure there are no syntax errors, typos, or double semicolons.
• Check for proper key chunking: If using a 2048-bit key, ensure your DNS editor has split the payload into quoted string segments under 255 characters (e.g., “v=DKIM1; k=rsa; p=part1…” “part2…”). Never create separate TXT records for the same selector.

2. Move DKIM Signing to the Final Outbound Hop

If your organization routes email through secondary security gateways, disclaimer tools, or CRM solutions, ensure that DKIM signing occurs after these tools have made their additions. If an appliance must modify content, configure that appliance to perform the final DKIM signing step on behalf of your domain.

3. Update Canonicalization Settings

Change your mail server’s canonicalization settings to relaxed/relaxed (or c=relaxed/relaxed in the DKIM header). This instructs receiving mail servers to normalize whitespace, trailing spaces, and header field formatting before re-computing the hash, preventing false verification failures caused by minor transport modifications.

4. Ensure Key Pair Alignment During Rotations

When rotating DKIM keys, always publish the new public key under a new selector name in DNS first. Allow 24 to 48 hours for DNS propagation before configuring your mail server to sign messages with the new private key. Once migration is complete, leave the old public key record in DNS for several days so in-flight or queued messages signed with the old selector can still be verified.

Note that we have covered some common DKIM failure prompts and their probable causes while providing a possible solution for them. However, errors might pop up due to various underlying reasons that are specific to your domain and servers, which have not been covered in this article. 

You must build up your knowledge around authentication protocols sufficiently before you implement them at your organization or enforce your policies. DKIM failure, failure in SPF, or DMARC validation can impact your email’s deliverability. 

Frequently Asked Questions

What does “body hash did not verify” mean?

“Body hash did not verify” means the public key was found in DNS and the header format was valid, but the message content changed after it was signed. Because the body was modified in transit (by disclaimers, security gateways, re-encoding, or forwarding), the receiver’s computed hash did not match the original hash recorded in the signature’s bh= tag.

How do I solve DKIM failure?

To solve a DKIM failure, locate the exact error string in your email’s Authentication-Results header. If the error is a missing key (no key for signature), publish or correct the public key TXT record in DNS under the correct selector. If the error is a body hash mismatch (body hash did not verify), adjust your mail flow so that DKIM signing happens as the final step after all footers and links are added, and set canonicalization to relaxed/relaxed.

What does DKIM violation mean?

A “DKIM violation” is a term used by certain mail security gateways to indicate that an incoming email failed DKIM validation checks. This usually implies either the cryptographic signature was invalid, the message was tampered with in transit, or the sender attempted to sign the email using a domain that does not align with the visible sender address.

Does a DKIM failure mean my email won’t be delivered?

Not necessarily. If your domain has a valid SPF record that passes with proper DMARC alignment, the email will still pass overall DMARC verification and reach the inbox in most cases. However, relying solely on SPF makes your deliverability vulnerable when emails are forwarded. Furthermore, if DMARC fails on both protocols and your domain policy is set to p=quarantine or p=reject, the failing email will be delivered to spam or rejected entirely.

• About
• Latest Posts

Maitham Al Lawati

Cybersecurity Expert, CEO at PowerDMARC

Maitham is a tech entrepreneur, cybersecurity expert, CEO and Founder of PowerDMARC with 15+ years of industry experience. Maitham holds a Global MBA from the University of Manchester and various professional certifications including CISSP, CISM, CRISC, and ISC2 CCSP.

Latest posts by Maitham Al Lawati (see all)

• DKIM Fail: What Each Error Means and How to Fix It - September 13, 2026
• Email Authentication Methods: How SPF, DKIM, and DMARC Protect Your Domain - August 9, 2026
• What is a DMARC Policy? None, Quarantine, and Reject - July 27, 2026