There is no DKIM revocation list and no expiry on a key. Revocation is one thing: publish the record with an empty p=.
What an empty p= means
RFC 6376 §3.6.1 states it plainly — an empty key means the key has been revoked, and a verifier must treat any signature made with that selector as failing. Note the difference from deleting the record:
p= with a key signatures verify p= empty signatures FAIL (revoked: an assertion) record absent signatures cannot be verified (no information)
The middle case is a statement. The third is a silence, and a receiver that meets it cannot tell a retired key from a typo, a DNS outage or a selector that never existed. Revoking properly is the difference between saying “this key is no longer ours” and saying nothing at all.
Google’s retired selectors
Google rotates gmail.com’s signing keys and leaves the revocations in place. Three of them, all answering today:
"v=DKIM1; k=rsa; p=" "v=DKIM1; k=rsa; p="
Anyone replaying an old gmail.com message signed under those selectors gets a definite failure rather than a shrug. That is what the records are for.
A pre-published rotation slot
The same empty p= is also how a standby selector is reserved before it holds anything. Fastmail publishes three slots and uses one:
fm2.fastmail.com.dkim.fmhosted.com. "v=DKIM1; k=rsa; n=Intentionally_Left_Blank_As_Per_DKIM_Rotation_BCP; p="
This is one of the few n= tags you will ever meet in the wild, and it is being used exactly as intended: a note to the next human, saying the blank is deliberate. The record is doing two jobs — reserving the name and forbidding any signature that claims it.
Revoking one
- Stop signing with the key first. Revoking while mail is still being signed with it fails your own messages.
- Wait for mail in flight. Queued and retrying messages carry the old signature. A day is usually enough; a week is safer.
- Replace the key with nothing, keeping the record.
v=DKIM1; k=rsa; p= - Leave it there. Indefinitely. It costs one small TXT record and it is the only thing standing between a leaked key and an attacker’s signature verifying.
Deleting the record is not revocation
It is the instinctive move and it is wrong in one specific and serious case: if the private key was exposed, deleting the record means signatures made with it are unverifiable rather than invalid — and a receiver that cannot verify falls back to whatever else it has, which may be an SPF pass on infrastructure the attacker also controls.