Why DKIM Fails: 6 Common Causes and How to Fix Them

DKIM is the part of email authentication that does the heavy lifting. It survives forwarding, it’s what most marketing platforms rely on to pass DMARC, and Google, Yahoo and Microsoft all expect it from bulk senders. So when your headers or DMARC reports show dkim=fail, it’s worth fixing quickly.

Here are the six causes we see most often, how to spot each one and how to fix it.

First, a 30-second refresher

When you send an email, your platform adds a DKIM signature: a header with an encrypted fingerprint of the message, the signing domain (d=) and a selector (s=). The receiving server looks up the public key at selector._domainkey.yourdomain.co.uk and checks the fingerprint still matches. If the key can’t be found, or the message has changed since it was signed, DKIM fails. Our introduction to DKIM covers the basics in more detail.

To find which cause you’re dealing with, open the full headers of a failing email and look at the Authentication-Results line. The wording after dkim=fail (or dkim=permerror) usually points straight at the problem.

1. The DKIM record is missing or published in the wrong place

What you’ll see: “no key for signature”, “key not found” or dkim=permerror.

The receiving server went to look up your public key and found nothing. Usually one of these has happened:

• The record was never added, or was added to the wrong domain.
• The DNS panel added your domain to the name automatically, creating s1._domainkey.yourdomain.co.uk.yourdomain.co.uk.
• The selector in the record doesn’t match the one in the signature (for example, s1 published but s2 used).

Fix: Compare the s= and d= values in the email’s DKIM signature with the record in your DNS, and look the record up with a DKIM checker to confirm it resolves.

2. DKIM was set up in DNS but never switched on

What you’ll see: the email is signed by your platform’s domain instead of yours, or not signed at all.

Most platforms make you add the DNS records and then click “verify” or “enable” in their settings. Microsoft 365 is the classic example: you publish two CNAME records (selector1._domainkey and selector2._domainkey) and then enable DKIM signing for the domain in the Defender portal. Skip that last step and Microsoft keeps signing with its own default domain.

Fix: Go back into each platform’s domain authentication settings and confirm DKIM signing shows as active for your domain.

3. The key has been broken by your DNS panel

What you’ll see: “invalid public key”, “key syntax error” or dkim=permerror.

DKIM keys are long. A 2048-bit key is over 400 characters, and a single DNS text string can only hold 255. Some DNS panels split long values automatically and some don’t. Copy-and-paste can also add stray spaces, line breaks or extra quotation marks, or cut off the end of the key.

Fix: Republish the record exactly as your platform provides it. If your DNS panel struggles with long values, use the CNAME option many platforms offer instead. The platform then hosts the key and keeps it up to date.

4. The email was changed after it was signed

What you’ll see: “body hash did not verify” or “signature did not verify”.

DKIM’s fingerprint covers the message body and key headers. If anything changes them on the way, the fingerprint no longer matches. Common culprits:

• Email security gateways that rewrite links or add “external sender” banners
• Mailing lists and Google Groups that add footers or change the subject line
• Signature or disclaimer tools that add text after sending
• Forwarding services that alter the message

Fix: Make sure any tool that modifies outgoing mail does so before DKIM signing, not after. For mailing lists you don’t control, there’s little you can do. That’s normal, and it’s one reason DMARC passes if either SPF or DKIM passes and aligns.

5. The key was rotated or removed

What you’ll see: DKIM was passing and suddenly fails across all mail from one service.

Platforms periodically switch to new keys, and people tidying DNS sometimes delete an “unrecognised” _domainkey record that was still in use. If a key is replaced before the platform stops using it, signatures fail until things catch up.

Fix: Never delete a _domainkey record without checking your DMARC reports to see whether anything still signs with that selector. Where possible, use CNAME-based DKIM so the platform handles rotation for you. And check you’re on 2048-bit keys: Google recommends them, and some older setups still use weaker 1024-bit keys.

6. DKIM passes, but not for your domain

What you’ll see: dkim=pass in the headers, but DKIM shown as failing in DMARC reports.

This one catches out a lot of people. DKIM can pass perfectly well for the platform’s own domain (for example d=platform-example.com). DMARC, though, only counts DKIM when the signing domain matches your From domain. That’s called alignment. Without it, DKIM is technically working but does nothing for your DMARC result or your sender reputation.

Fix: Set up custom DKIM (often called “domain authentication” or “branded sending domain”) in every platform that sends as your domain, so the signature reads d=yourdomain.co.uk. This matters even more as you move your DMARC policy from p=none to enforcement.

A quick DKIM health check

• Every service that sends as your domain signs with d=yourdomain.co.uk.
• Every selector in use has a working record in your DNS.
• Keys are 2048-bit where the platform supports it.
• Your DMARC reports show DKIM passing and aligned for all legitimate sources.