DKIM Authentication Failed? Here’s How to Fix It

DKIM is one of the core email authentication mechanisms used to verify that a message was legitimately signed by a domain and that the signed parts of the email weren’t altered after signing. When DKIM works correctly, receiving mail servers can retrieve the sender’s public key from DNS and use it to verify the cryptographic signature attached to the email.

But configuration errors, DNS problems, third-party sending platforms, or changes made to a message while it is in transit can cause DKIM failure. When this happens, receiving servers lose an important trust signal. Depending on the recipient’s filtering rules and the results of SPF and DMARC checks, affected messages can be delivered normally, sent to spam, or rejected.

The good news is that most DKIM failures can be diagnosed systematically. In this guide, we’ll explain what a DKIM failure means, the most common reasons it happens, and how to fix DKIM authentication problems step by step.

Key Takeaways

• DKIM fails when a receiving server cannot successfully verify the DKIM signature attached to an email.
• Common causes include missing or incorrect DKIM records, wrong selectors, malformed public keys, message modifications, DNS problems, and improperly configured third-party email services.
• Make sure the selector in the email header points to the correct DKIM record in DNS.
• DKIM authentication and DKIM alignment are related but different: a signature may be valid while still failing DMARC alignment.
• Third-party email platforms must be individually configured to sign messages with DKIM for your domain.
• Monitoring DMARC reports helps identify which sending sources repeatedly fail DKIM.
• SPF, DKIM, and DMARC should be implemented together for stronger authentication and domain protection.

What Happens When DKIM Fails?

 
The consequences depend on the recipient’s filtering rules and your overall email authentication configuration.

A DKIM failure can:

• reduce trust in the message;
• contribute to spam placement;
• negatively affect email deliverability if failures occur repeatedly;
• cause DMARC to fail if SPF does not provide an aligned pass;
• lead to quarantine or rejection when DMARC enforcement applies.

Importantly, DKIM failure does not automatically mean DMARC failure.

DMARC can pass when either:

• DKIM passes and aligns with the visible From domain, or
• SPF passes and aligns with the visible From domain.

Therefore, if DKIM fails but SPF passes with proper alignment, the email can still pass DMARC. If neither authentication method passes with alignment, DMARC fails and the published domain policy may determine how the recipient treats the message.

Why Does DKIM Fail?

 
Before changing your DNS records, identify why authentication is failing. DKIM problems can originate from several different parts of the email infrastructure.

1. DKIM Isn’t Configured.

 
One of the simplest causes is that DKIM signing was never enabled.

Your email provider might be sending messages without a DKIM signature, or you may not have published the public key required to verify it.

This frequently happens when organizations add a new email service but forget to complete the service’s domain authentication process.

For example, you may have correctly configured DKIM for your primary mailbox provider but not for:

• an email marketing platform;
• a CRM;
• a transactional email provider;
• a customer support platform;
• a billing system;
• another SaaS application sending email from your domain.

Every legitimate service sending email using your domain should be reviewed individually.

2. The DKIM Record Is Incorrect.

 
Syntax or formatting problems in your DKIM DNS record can make the public key unreadable.

Possible problems include:

• an incomplete public key;
• incorrect quotation marks;
• missing DKIM tags;
• extra or misplaced characters;
• an incorrectly copied value;
• publishing the record under the wrong hostname;
• DNS provider formatting problems.

Even a small configuration mistake can prevent the receiving server from retrieving or using the correct public key.

3. The DKIM Selector Is Wrong.

 
Every DKIM signature contains a selector in the s= tag.

For example:

DKIM-Signature: ... d=example.com; s=selector1; ...

The receiving server combines the selector with the _domainkey label and the signing domain to find the public key.

In this example, it would query something similar to:

selector1._domainkey.example.com

If the selector referenced by the email does not have a corresponding DKIM record in DNS, verification cannot be completed.

This can happen after:

• DKIM key rotation;
• migrating to another email provider;
• deleting an old selector too early;
• entering the selector incorrectly;
• publishing the key at the wrong DNS location.

4. The Public and Private Keys Don’t Match.

 
DKIM relies on a cryptographic key pair.

The sending platform signs the message using the private key, while recipients verify it using the public key stored in DNS.

If the private key being used by the sending server does not correspond to the public key published for that selector, verification fails.

This problem may occur after changing DKIM keys when only one side of the configuration was updated.

5. The DKIM Public Key Is Missing.

 
Another common error is:

dkim=fail (no key for signature)

The message contains a DKIM signature, but the receiving server cannot find the corresponding public key.

This usually means that:

• the DKIM DNS record was removed;
• the selector is incorrect;
• the record was never published;
• the DNS update has not propagated;
• the record was published on the wrong domain.

Missing public keys are one of the common causes of DKIM authentication failure.

6. The Message Was Changed After DKIM Signing

 
DKIM verifies the integrity of signed email content.

Once the sending server generates the DKIM signature, changes made to signed portions of the message can invalidate that signature.

For example, intermediary systems may:

• append disclaimers;
• add legal footers;
• modify HTML;
• rewrite URLs;
• change whitespace or formatting;
• alter headers;
• modify the message body.

If these modifications affect content covered by the DKIM signature, the hash calculated by the recipient no longer matches the original hash.

You may then see errors such as:

dkim=fail (bad signature)

or:

dkim=fail (DKIM-signature body hash not verified)

Mail gateways, forwarding systems, security filters, and mailing lists are common sources of these modifications.

7. DNS Problems Prevent DKIM Lookup.

 
DKIM verification depends on DNS.

A recipient needs to retrieve your DKIM public key before it can verify the signature. DNS downtime, timeouts, connectivity problems, or temporary resolution issues may therefore interrupt authentication.

These problems can result in a temporary error rather than a permanent DKIM failure.

For example:

dkim=temperror

If only a small number of messages failed during a brief period and your DNS record is otherwise correct, a temporary DNS issue may be responsible.

8. DKIM Isn’t Properly Configured for a Third-Party Sender.

 
Using several email platforms makes DKIM configuration more complicated.

Each service may:

• use its own DKIM selectors;
• provide its own DNS records;
• require domain verification;
• use a CNAME instead of a TXT record;
• require DKIM signing to be manually enabled.

Adding a new sender to SPF does not automatically configure DKIM for that sender.

Check the documentation provided by every email platform that sends on behalf of your domain and confirm that DKIM signing is enabled.

9. DKIM Authentication Passes but Alignment Fails.

 
There is an important distinction between DKIM authentication and DKIM alignment.

A signature can technically pass DKIM verification but still fail the DKIM alignment requirement used by DMARC.

For DMARC, the domain in the DKIM d= tag must align with the domain visible in the message's From address.

For example:

From:

newsletter@example.com

DKIM signing domain:

d=example.com

These domains align.

But if the signature uses:

d=email-provider.com

the DKIM signature itself might be valid while failing DMARC alignment with example.com.

DMARC can use relaxed or strict DKIM alignment. Strict alignment requires an exact domain match, while relaxed alignment allows organizational-domain alignment.

How to Fix DKIM Failure

 
The exact solution depends on the error, so troubleshooting DKIM should follow a logical sequence.

Step 1: Check the Email Headers.

 
Start with an email that failed authentication.

Open the full message headers and locate:

Authentication-Results:

You may see something like:

dkim=fail

Next, find the:

DKIM-Signature:

header.

Pay particular attention to:

• d= — signing domain;
• s= — DKIM selector;
• c= — canonicalization method;
• h= — signed headers;
• bh= — body hash.

The error shown in Authentication-Results often provides the fastest clue about where to begin troubleshooting.

For example:

dkim=fail (no key for signature)

Check the selector and DNS record.

dkim=fail (body hash did not verify)

Investigate whether the email was modified after signing.

dkim=temperror

Check for DNS or receiving-server problems.

dkim=permerror

Look for persistent configuration or syntax problems.

Step 2: Verify the DKIM Record in DNS.

 
Take the selector from the failed message and query its DKIM record.

Confirm that:

• the selector exists;
• the record is published under the correct domain;
• the public key is complete;
• the record syntax is valid;
• there are no accidental formatting errors.

You can use the DMARKOFF DKIM Checker to look up a domain and selector, validate DKIM syntax, check the public key and key length, and confirm that the record is correctly published in DNS. You can also paste a DKIM record into the checker before publishing it, which can help catch configuration errors early.

Run DKIM Check

If you recently created or changed the DKIM record, remember that DNS changes may not become visible everywhere immediately.

Step 3: Confirm That DKIM Signing Is Enabled.

 
A perfectly configured DNS record is useless if your outgoing mail platform is not actually signing messages.

Send yourself a test email and look for:

DKIM-Signature:

If the header is completely absent, check the DKIM configuration in your ESP or mail server.

Depending on the provider, you might need to:

1. add the provider's DKIM records to DNS;
2. verify the domain;
3. wait until the provider detects the records;
4. explicitly enable DKIM signing.

Repeat this process for every platform sending mail using your domain.

Step 4: Check the DKIM Selector.

 
Compare the selector in the email:

s=selector1

with the selector currently published in DNS.

If they do not match, determine whether:

• the sending platform is still signing with an old selector;
• an old DNS record was deleted;
• a new record was published under the wrong selector;
• your provider changed its DKIM configuration.

During DKIM key rotation, keep the old public key available long enough for messages already signed with the previous key to finish passing through the email ecosystem.

Step 5: Verify the Key Pair.

 
If the selector and DNS record exist but authentication still fails consistently, make sure the public key corresponds to the private key used by the sender.

For managed email providers, this normally means regenerating or reconfiguring DKIM according to the provider's instructions.

Avoid manually modifying the public key unless you know exactly how the provider handles DKIM signing.

Step 6: Investigate Message Modifications.

 
If the failure states that the body hash or signature could not be verified, compare the message before and after it passes through your infrastructure.

Look for systems that may modify emails, including:

• secure email gateways;
• forwarding services;
• anti-spam systems;
• mailing list software;
• CRM platforms;
• compliance tools;
• systems adding disclaimers or footers.

Changes made by MTAs or intermediary systems can invalidate DKIM signatures.

Where possible, configure these systems so that content modifications happen before DKIM signing.

Step 7: Review DKIM Canonicalization.

 
DKIM canonicalization determines how certain formatting variations are treated during signature verification.

Two common options are:

• simple
• relaxed

A simple canonicalization strategy tolerates fewer changes, while relaxed canonicalization normalizes certain formatting differences before verification.

The setting appears in the c= tag of the DKIM signature, for example:

c=relaxed/relaxed

If your messages frequently travel through systems that make harmless formatting changes, canonicalization settings may be worth reviewing with your mail administrator or ESP.

However, canonicalization cannot protect DKIM against substantial modifications to signed content.

Step 8: Check DKIM Alignment.

 
If DKIM passes but DMARC still reports a DKIM alignment failure, inspect the d= domain.

Compare:

Visible From domain

example.com

with:

DKIM signing domain

d=example.com

or an aligned subdomain.

Then inspect your DMARC record for:

adkim=r

or:

adkim=s

r means relaxed alignment, while s means strict alignment.

Strict alignment requires the domains to match exactly, so it can create failures in infrastructures that use subdomains or third-party DKIM signing domains.

Do not weaken alignment simply to hide a configuration problem. Ideally, legitimate services should be configured to sign using an aligned domain.

Step 9: Configure Every Legitimate Sending Source.

 
Organizations often troubleshoot their main mail provider while overlooking less obvious email streams.

Create an inventory of platforms that send as your domain, such as:

• Google Workspace or Microsoft 365;
• marketing automation platforms;
• transactional email services;
• ecommerce platforms;
• CRMs;
• customer support software;
• invoicing tools;
• recruiting platforms;
• monitoring and alerting systems.

Then confirm DKIM authentication for each one.

One improperly configured application can generate thousands of DKIM failures even when every other sending source works correctly.

Step 10: Monitor DKIM Through DMARC Reports.

 
Fixing an individual test email does not necessarily mean your entire domain is properly configured.

DMARC aggregate reports can show which sending sources are:

• passing DKIM;
• failing DKIM;
• passing or failing SPF;
• aligned or misaligned;
• sending unexpected traffic using your domain.

This is particularly useful when multiple platforms send email on behalf of your organization.

DMARKOFF continuously analyzes authentication results and provides visibility into SPF, DKIM, and DMARC performance, helping teams identify misconfigurations and authentication failures across their sending infrastructure instead of relying only on individual message tests.
 
Start 14-day Free Trial
 

How to Prevent DKIM Failures

 
Once DKIM is working, regular maintenance helps prevent the same problems from returning.

Monitor All Sending Services

Maintain an accurate inventory of services allowed to send email using your domain.

Whenever a new ESP or SaaS application is introduced, make domain authentication part of the onboarding process.

Monitor DMARC Reports

DMARC reporting provides ongoing visibility into authentication performance and can reveal when a new source suddenly begins failing DKIM. We recommend using DMARC reporting to track authentication problems over time.

Rotate DKIM Keys Carefully

DKIM keys should be managed securely and rotated according to your organization's security policy and provider recommendations.

When rotating keys:

1. create a new selector and key pair;
2. publish the new public key;
3. confirm that DNS has updated;
4. start signing with the new private key;
5. verify authentication;
6. retire the previous selector only after it is no longer needed.

This prevents messages signed during the transition from suddenly becoming unverifiable.

Test After Infrastructure Changes

Recheck DKIM whenever you:

• migrate email providers;
• change DNS providers;
• add a sending service;
• modify mail routing;
• implement an email security gateway;
• change DKIM selectors;
• introduce forwarding or compliance systems.

Infrastructure changes are one of the easiest ways for previously working authentication to break.

Use SPF, DKIM, and DMARC Together

DKIM should not operate in isolation.

SPF verifies whether a server is authorized to send mail for a domain used during SPF evaluation, while DKIM validates a cryptographic signature. DMARC then evaluates SPF and DKIM results together with domain alignment.

Implementing all three gives mailbox providers more information for distinguishing legitimate email from spoofed mail and gives domain owners reporting visibility into authentication activity.

Conclusion

 
A DKIM failure means the receiving mail server could not successfully verify the cryptographic signature attached to your email. The problem may be as simple as a missing selector or DNS record, but it can also originate from third-party platforms, mismatched keys, DNS outages, forwarding systems, message modifications, or DMARC alignment.

The fastest way to fix DKIM failure is to work methodically. Start with the failed message's email headers, identify the signing domain and selector, verify the corresponding public key in DNS, make sure the sender is actually signing messages, and then investigate any infrastructure that modifies messages after signing.

Most importantly, don't treat DKIM troubleshooting as a one-time task. Monitor authentication results across all sending sources and use DMARC reporting to catch new failures before they begin affecting a significant portion of your email traffic.