Mister Marbi

Domain Health · DKIM · Revoked keys

A DKIM selector shows as "revoked"

A checker found a DKIM record whose key is empty (p= with nothing after it). Usually that's harmless key rotation. It's only a problem if your mail is still being signed with that selector. Here's how to tell which.

Blank = try common selectors.
Try an example:

What an empty key means

The DKIM standard (RFC 6376 §3.6.1) says an empty p= tag means the public key has been revoked. Any signature made with that selector now fails verification. Publishing an empty key is the formal way to retire one.

hostingermail-b._domainkey.example.com TXT "v=DKIM1; k=rsa; p="

That's only bad news if something still signs with it. So the question is never "is there a revoked selector?" but "which selector is my mail actually signed with?"

The two-minute test

  1. Send yourself a message from the address in question, or open a recent one you sent.
  2. Open the raw message ("show original" or "view source").
  3. Find the DKIM-Signature: header. s= is the selector and d= is the signing domain.
  4. Check that selector by name in the checker above.
  • If the s= selector has a valid key, the revoked one is just a retired or standby key. Nothing to fix.
  • If the s= selector is the revoked one, your mail is failing DKIM. Republish the current key from your provider's DKIM settings, or switch signing to a selector that has a key.
  • If you find several DKIM-Signature: headers, judge by the one whose d= is your domain. That's the one DMARC counts.

The common harmless cases

Your provider rotates keys behind a CNAME

Many providers ask you to publish two or three selectors as CNAMEs pointing at their DNS, then rotate keys there on their own schedule. At any moment one selector holds the active key and the others may be empty. If the empty selector is a CNAME to your provider and a sibling selector from the same provider has a valid key, that's rotation working as designed. Leave the CNAMEs in place, because the provider needs them for the next rotation.

You rotated a key yourself

The usual safe sequence is: publish the new key under a new selector, switch signing to it, wait a few days for mail in transit, then empty or delete the old record. An empty old selector afterwards is expected. Deleting the record has the same effect as an empty key.

A domain that never sends mail

Some owners publish an empty key on purpose, together with v=spf1 -all and a DMARC p=reject record, to state that the domain sends no email at all. If that's intentional, it's correct.

A case that fools checkers: wildcard records

If a domain publishes an empty key at *._domainkey, every selector name anyone tries returns that empty key. A checker that guesses common selectors, ours included, will then list each guess as "revoked". To be sure, check the exact s= selector from a real message, as in the test above.

Worked example: our own domain

Our email host gives mistermarbi.com three selectors, hostingermail-a, -b and -c, each a CNAME into the provider's DNS. The checker above finds a 2048-bit key at hostingermail-a and empty keys at the other two. Only hostingermail-a can produce a valid signature right now, and the empty ones are the provider's standby slots for the next rotation. The two-minute test above confirms which selector a given message actually used. Our checker reports them as Info: provider-managed key rotation, not as something to fix.

Related: DKIM checker and how DKIM works · DMARC checker