# Why is my DKIM key failing?

Troubleshoot missing or failing DKIM keys: find the correct selector, check DNS publication and separate public-key problems from message-signature failures.

Canonical: https://tamperbox.dev/guides/fix-dkim-key-failures

Updated: 2026-10-18

Reviewed: 2026-10-17

Separate a missing public key from a failing message signature. DNS publication and signing are different steps, and a valid key record cannot prove that a message was signed correctly.

## Get the exact domain and selector

Open a message that was actually sent through the affected service. In DKIM-Signature, read d= for the signing domain and s= for the selector. In a synthetic example with d=sender.example and s=mail1, the lookup name is mail1._domainkey.sender.example.

Enter those values in [DKIM Checker](https://tamperbox.dev/dkim-checker). Common-selector discovery is a convenience, not an exhaustive inventory. A failed guess does not prove that the domain has no key.

## Check what DNS publishes

Use [TXT Lookup](https://tamperbox.dev/txt-lookup) on the full name to inspect the record. Compare the complete value with the sending service's current public key. Check for an empty p= value, which revokes the key, damaged Base64 or the wrong key type. Do not publish a private key.

A DNS interface may expect a relative record name and append the zone automatically. Check the actual published owner name instead of assuming what the interface stored. Split strings within one TXT record are not separate keys.

## Investigate a signature failure

If the key is readable, compare its fingerprint with the sender configuration. Rotation can leave the sender using a different key. Message transformations can also affect signed data. Read the trusted receiver's reported result in [Email Header Analyzer](https://tamperbox.dev/email-header-analyzer), then use the sending service's logs or a full message verifier to investigate further.

Neither of these tools independently verifies the complete message's DKIM signature. Keep sensitive message contents out of public bug reports.

## Worked example: one stale selector after rotation

A synthetic delivered message contains:

```text
DKIM-Signature: v=1; a=rsa-sha256; d=sender.example; s=mail2; ...
Authentication-Results: mx.receiver.example; dkim=fail header.d=sender.example header.s=mail2
```

The relevant DNS name is `mail2._domainkey.sender.example`. Checking `mail1` instead may show a valid 2048-bit key but tells you nothing about this message. Suppose `mail2` publishes `v=DKIM1; k=rsa; p=`. Its empty key revokes that selector, so the checker reports a revoked key: **zero usable keys at the required selector**, even though the old selector works.

Obtain the exact public key from the configured signing service and replace the empty `p=` value in one TXT record. A healthy recheck should show the expected key type, **2048 bits** for this example and a matching fingerprint. Do not copy a key from another sender or generate an unrelated one in DNS.

Send a new message. A trusted receiver reporting `dkim=pass header.d=sender.example header.s=mail2` confirms its verification of that new message. The record checker alone cannot establish that result, and an old message signed before the repair need not verify.

## Reference

[DKIM key records and verification, RFC 6376](https://www.rfc-editor.org/rfc/rfc6376).