An empty p= in a DKIM record is a revoked key, not a published one
What does an empty p= value mean in a DKIM DNS record?
In one sentence
p= with nothing after it does not mean the key is missing.
Plain English
p= with nothing after it does not mean the key is missing. It means somebody revoked it and said so in public. The record answers, so most tools tick the box, and the mail still fails.
Why it matters. p= with nothing after it does not mean the key is missing.
Dotted words open definitions. See how email actually works.
What to do
Your move — not a lecture
Part platform, part you
The platform covers the mechanical bit. The judgement is still yours.
Your platform generates and publishes the key material and will rotate it. It cannot see what else is sitting under _domainkey on your domain.
Your part: Removing revoked and wildcard records from your own . A leftover empty key is yours, and so is the decision to delete rather than keep it for tidiness.
What to do first
Run dig TXT <selector>._domainkey.yourdomain.com for every selector you know about, and read what comes back rather than whether something came back. Any record whose p= is empty is a revoked key that should be deleted. Then probe a selector you invented — if that answers too, you have a wildcard under _domainkey and no selector check on this domain means anything until it is gone.
You can skip this if: You have never rotated a key and publish exactly the selectors your platform gave you.
Who this applies to
Any domain where a selector was rotated, retired or revoked and the empty record was left behind — including the wildcard case, where a record under _domainkey answers every selector name and makes probing meaningless.
Checklist
- 01Treat an answering selector as inconclusive until you have read the p= value.
- 02Delete revoked records rather than leaving them; they are indistinguishable from a working key to most tooling.
- 03Probe an impossible selector to rule out a wildcard before trusting any selector result.
- 04Confirm on a real message: =pass with header.d matching your is the only proof that survives.
That’s enough to act. The exact wording, the enforcement record and the primary source sit under Proof & sources, for counsel, bosses, or AI tools that need a citation. Not legal advice.
Proof
Exact position, enforcement, sources
For records and people who will check you. Skip if Monday’s move is already clear.
The exact position
RFC 6376 is explicit: an empty value in the p= tag means the public key has been revoked, and verifiers should return an error for any signature referencing it. The record still resolves, so a checker that only asks whether a selector exists reports as present. It is not present. Anything signed with that selector fails, and a domain relying on for loses it silently, because the answer looks healthy from the outside.
What happens if you do not
None, in the regulatory sense. The failure is mechanical: verifiers error on the signature, is lost, and a domain at p=reject that has no aligned path has its own mail rejected.
Source
- RFC 6376 § 3.6.1, Textual Representation of DKIM Key RecordsPublished 1 Sep 2011Read primary source
History of this page
- Added. The domain check has probed an impossible selector and required real base64 after p= since it shipped; neither behaviour had a page explaining why.
Related
Take this with you
GET https://emailrules.today/rules/empty-dkim-p-value-is-a-revoked-key?format=json
Same URL, same answer, every field including the ones behind the Proof tab. An Accept: application/json header on the plain URL does the same thing. All the endpoints.