Guides

DKIM fail: find the cause before you change DNS

Last updated 2026-09-14

Your DNS checker says DKIM is valid, but a received email says dkim=fail. Start with that email's headers to find which signature failed and why.

Can DKIM fail when the DNS record is valid? Yes. A DNS lookup checks the public key, while the receiving service checks a signature against the message it received.

1. Get the received email's original headers. In Gmail, open the message, click the menu beside Reply, then Show original. Google's header instructions cover other mail apps too.
2. Find the receiving service's Authentication-Results header. Copy the DKIM result and its reason. Use the result your receiving service added. A sender can insert a header with the same name.
3. Find d= and s= in the matching DKIM-Signature. These give you the signing domain and selector. Check that exact pair, then follow the matching fix below.

If you've only got a DMARC report, skip to reading DKIM failures in aggregate reports. You'll need a received message to investigate a particular signature.

DKIM errors need different fixes

Keep the full error text when asking your provider for help. RFC 8601 defines the DKIM result codes, but receiving services add their own explanations.

Selector lookup: use the signature's domain

Build the lookup name from s=, then ._domainkey., then d=. Copy both values from the same signature. The address in From can use a different domain.

In Google Admin Toolbox Dig, select TXT and enter that full name. If you've got dig installed, run these commands. Replace the uppercase placeholders with the values you copied:

If the answer contains a CNAME, check its target for the TXT public key. Compare the answer with the record in your sending service's admin panel. Check the whole value.

A long key can occupy several quoted strings inside a single TXT record. Those strings join without spaces. Separate TXT records at the same selector need correcting under DKIM's TXT format rules.

An empty p= means the key was revoked. Get the active key's record from your sending service.

For a browser check, enter the same signing domain and selector in our DKIM checker. A key found under another selector doesn't prove this message's key is available.

Missing signature: enable the service that sent it

Publishing a key leaves another job to do. You have to turn on signing in the service that sends the email.

Google Workspace: open the Admin console, then Apps > Google Workspace > Gmail > Authenticate email. Choose the sending domain and click Start authentication after publishing its key. Follow Google's DKIM setup instructions if the domain isn't ready.

Microsoft 365: open Email authentication settings > DKIM in the Defender portal. Select the sending domain, publish the CNAME values Microsoft gives your tenant, then enable signing. Microsoft's DKIM instructions explain how to get those values.

A helpdesk, invoice app or marketing service: check that service's domain-authentication settings. Signing your staff email doesn't configure your invoice app. Our provider setup pages cover the individual services.

Signature mismatch: check keys and signed headers

If the DNS key matches your provider's instructions, ask them to check the signing key used by the failing server. Give them the original message, sending time, domain and selector. Intermittent failures need a passing sample too.

Check for a key rotation or DNS change around the first failure. Keep the old public key available while mail signed with it is still in transit. RFC 6376 describes that overlap.

In Microsoft 365, retain the selector CNAME records required for rotation. Copy their targets from your tenant's settings. A target from another company's setup example belongs to that company.

Also check the services between signing and receipt. A relay that changes a signed Subject or From header can invalidate the signature. Microsoft's authentication troubleshooting covers key mismatches and gateway changes.

If the error mentions a weak key or an obsolete algorithm, check the signer. RFC 8301 requires RSA keys of at least 1024 bits, recommends at least 2048, and prohibits rsa-sha1. Follow your provider's key replacement process.

Body hash failure: find what changed the message

Look for an added footer, rewritten links, or a gateway that changes the message's encoding. Google's DKIM troubleshooting specifically calls out outbound gateways that add footers.

Send a test directly to an external mailbox you control. Compare it with a test through the affected forwarding or mailing-list route. If only the second fails, investigate what happens on that route.

For a gateway you control, stop the edits or arrange aligned DKIM signing after the edits. For a recipient's forwarder, ask its administrator to investigate. The body-hash failure guide covers that diagnosis in depth.

ARC lets a forwarding service preserve evidence of earlier authentication. The receiving service chooses whether to trust it. ARC doesn't repair the original DKIM signature.

DKIM passes: check which domain passed

DMARC checks whether passing SPF or DKIM authenticates the domain in the visible From address. That relationship is called alignment. A signature from an unrelated service domain won't supply it.

Read every DKIM result if the message has several signatures. A passing, aligned signature is enough for DMARC, even if another fails. RFC 9989 defines that rule.

Enable custom-domain signing at the sending service if it signs only with its own domain. Check your DMARC alignment mode too. Our DMARC alignment explanation covers exact matches and subdomains.

Report failures: separate DKIM from alignment

In an aggregate report, auth_results contains the underlying DKIM results. The DKIM result under policy_evaluated includes alignment. A pass in the first and a fail in the second points to a passing signature that didn't align.

Aggregate reports contain counts and authentication results, without the original message body. They help you find the affected source. You'll need a message sample or provider logs to establish why a signature failed.

Open the XML yourself using our aggregate report walkthrough, or upload it to the free DMARC report analyzer. Compare the source and reporting period before and after your change.

Fresh messages prove the repair

Repeat the failing task after your change. Send another invoice from the invoice app, or another reply from the helpdesk. A successful test from your staff mailbox only tests that mailbox's sending route.

Use a recipient outside your own mail system. Internal delivery can skip the signing and verification steps you're trying to test.

Check the received message for a passing signature from the intended domain, then check DMARC. If you changed DNS, allow old cached answers to expire. The authentication result saved in yesterday's email won't update.

We email you when a new source first fails DMARC on a paid plan. Our weekly digest shows the reported results by source so you can follow up after a repair. Your first domain is free.

DomainCanary is a DMARC monitoring service that protects your domain from email spoofing without blocking your own mail.