A revoked DKIM key and a missing key record can tell an operator different things, but neither supplies a usable verification key. RFC 6376 §3.1 explicitly defines no semantic difference between revoking a key and removing its record for signature verification. Preserve that distinction when diagnosing an outage or responding to a compromise.
Recognise the different observations
In a DKIM key record, an empty p= value indicates revocation. A syntactically suitable illustrative RSA revocation value is v=DKIM1; k=rsa; p=. It contains no private key and is not a replacement key. Use the exact selector owner name from the affected signature and follow the platform's supported process.
When the key record does not exist, RFC 6376 §6.1.2 calls for permanent failure with a no-key reason. An empty public-key value yields permanent failure with a revoked-key reason. A DNS query that fails to respond is a different condition and can produce temporary failure. Do not call every lookup problem revocation.
Operational intent still needs evidence. An empty key might be an approved emergency change or a publishing mistake. A missing record might reflect deliberate retirement, a wrong selector or an accidental deletion. Compare the authoritative DNS state, recursive answer, timestamp and authorised change history before attributing cause.
Choose the response according to the incident
For routine retirement, coordinate the end of signing with the period during which legitimate delayed messages may still require the old public key. For a suspected private-key compromise, continuity and containment may conflict. Invoke the incident process, establish who can authorise the change and document why the chosen response is proportionate.
Revocation is not instantaneous across caches. RFC 1034 §3.6 describes the TTL of cached records. A resolver can retain earlier positive data until its cache lifetime ends. Reducing the TTL after the incident does not retrospectively shorten every cached copy. Some resolvers can serve stale data under RFC 8767 §4 when refresh is unavailable, so the old TTL is not an absolute worldwide revocation deadline. Do not claim that a DNS edit instantly prevents every subsequent verification using an older answer.
Stopping the compromised signer and restricting unauthorised access are separate tasks. A DNS change alone does not recover the leaked private key or secure the account that exposed it. RFC 6376 §8.3 explains the risk of a compromised signing key. For provider-managed CNAMEs, identify who controls the final key data and which supported action retires the affected selector. Do not add a conflicting TXT record alongside the alias as an improvised fix; see RFC 1034 §3.6.2.
Work an evidence-led example
In a synthetic incident, messages use d=example.com; s=oldbilling. The authoritative answer now contains an empty p=, while one recursive resolver still returns the earlier public key. The incident record shows an approved revocation. This supports a cache-transition explanation; it does not establish that all recipients have already stopped validating the old signature.
A second test uses s=old-billing, with a hyphen absent from the intended selector. No record exists at that name. The lookup failure is real, but it does not prove the intended selector was revoked. Exact names prevent these two cases from being collapsed into one incident.
Verify the replacement without restoring the exposure
Where continued sending is authorised, use a new, securely generated key and a supported selector transition. Confirm authoritative publication and inspect a received test from each affected application. Keep the compromised key out of recovery scripts, backups restored to active signers and copied configuration templates.
Preserve the old configuration as incident evidence under restricted access, not as an automatic rollback target. A rollback that restores a compromised signing secret can recreate the problem. Close the incident with the authority for the change, affected selectors, containment actions, cache observations and new-signature evidence. Record any older legitimate messages whose verification was intentionally sacrificed.
Classify the lookup before choosing an action
Use these as synthetic diagnostic branches, not results from a real domain:
- Exact selector returns an empty p value: the key is explicitly revoked; RFC 6376 requires PERMFAIL (key revoked).
- Exact selector has no key record: RFC 6376 requires PERMFAIL (no key for signature). Check spelling, delegation and approved retirement history.
- Query receives no response: RFC 6376 permits TEMPFAIL (key unavailable). This observation alone does not prove revocation.
These outcomes concern that signature. Preserve other signatures and their results separately; a message can have another authentication path.
Related reading
DKIM DNS delegation: assess the scope of control granted to a provider · Store and protect DKIM private keys across signing systems.