How to fix a revoked or rotated DKIM key

A domain can have a perfectly valid DKIM record sitting in DNS and still fail authentication on every single email. No error in the sending platform. No bounce. No warning. The signature is just wrong, and nothing tells you why.

This is what a revoked or rotated DKIM key looks like, and it's one of the more common deliverability problems agencies miss for weeks at a time.

What's actually happening

DKIM works as a key pair. Your sending service (Google Workspace, an ESP, your own mail server) holds a private key and uses it to sign every outgoing email. The matching public key lives in a DNS TXT record at a specific selector, something like 20210112._domainkey.yourdomain.com.

When a receiving server gets your email, it looks up that public key in DNS and checks whether the signature matches. If it does, DKIM passes. If the public key in DNS doesn't match the private key that actually signed the message, DKIM fails even though a DKIM record technically exists.

This mismatch happens for one of two reasons:

The key was rotated. Sending platforms periodically rotate their signing keys for security. When this happens, they're supposed to update the DNS instructions they gave you, or if you're using their automated DNS integration update it for you automatically. Sometimes that update doesn't propagate, or it was a manual setup years ago and nobody touched it since.

The key was revoked. Some providers explicitly revoke an old selector by publishing an empty p= value at that selector's DNS record. This is the standard way to signal "this key is dead, stop trusting it" without removing the record entirely. If your checker is still pointed at that selector, it reads as a hard failure, not a missing record.

Either way, the result looks identical from the outside: a DKIM record exists, but authentication fails.

A real example

While testing Infraova's DKIM checker, we ran a scan against google.com itself a domain about as well-maintained as they come. The checker flagged exactly this issue: selector 20210112 came back revoked, with an empty p= value in DNS.

That's not a misconfiguration on Google's part. It's an old key they explicitly retired, left in place as a deliberate "do not trust this" signal rather than deleting the record outright. The lesson isn't "even Google gets it wrong" it's that key rotation and revocation are a normal, ongoing part of how DKIM works, and a one-time setup will eventually go stale.

How to tell the difference between "missing" and "revoked"

This distinction matters because the fix is different.

A missing DKIM record means there's no TXT record at the selector at all. Nothing was ever published, or it was deleted. The fix is to publish a new one.

A revoked key means a record exists, but the value at p= is empty or doesn't match what the sending service is currently using to sign mail. The fix is to update the existing record with the current public key, not create a new one.

Most basic DNS lookup tools just tell you "DKIM check failed" without distinguishing between these. That ambiguity is exactly why this issue tends to sit unnoticed there's no clear next step in the error message.

How to fix it

1. Identify which selector your sending service is currently using. Log into the sending platform's domain authentication settings (Google Workspace admin console, your ESP's domain settings, etc.) and find the current DKIM public key and selector name.

2. Compare it against what's published in DNS. Query the DNS TXT record at [selector]._domainkey.yourdomain.com and check whether the p= value matches what the sending service shows you. If it's empty, blank, or different, that's your mismatch.

3. Update the DNS TXT record with the current public key from the sending service. If the sending service uses a different selector than what's currently in DNS, you'll need to publish a new record at the new selector the old one can stay as-is or be removed once the new one is confirmed working.

4. Re-verify through the sending service. Most platforms have a "verify DNS" or "check domain authentication" button that confirms the key pair matches before you rely on it for live sending.

5. Send a test email and check the headers. Look for dkim=pass in the authentication results of the received message to confirm the fix actually took.

Why this keeps happening

Sending services rotate keys for security reasons on their own schedule, not yours. If DNS was set up manually once and never revisited, there's no mechanism that tells you when a rotation happens on their end. The domain just quietly starts failing DKIM, and depending on your DMARC policy, those emails either get flagged as suspicious or, in the worst case, rejected outright.

This is the kind of failure that doesn't show up until someone notices reply rates dropped, or a client calls asking why a campaign underperformed by which point it's usually been broken for weeks.

The only real fix is checking it on a schedule rather than once at setup. A key that's valid today isn't guaranteed to still be valid in three months, and there's no notification when it changes unless something is actually watching for it.