The day a private key is exposed

A private signing key turns up in a public repository, in a leaked backup, or in a departing contractor’s laptop image. Anyone holding it can produce valid, aligned, DMARC-passing mail as your domain. The order of the response matters, because the instinctive first move is the wrong one.

The order

1. Generate a new key under a NEW selector, publish it
2. Wait for it to resolve from outside
3. Switch every signer to the new selector
4. Verify with a delivered message
5. REVOKE the exposed selector:  p=   (keep the record)
6. Only then: rotate anything else that shared the key

Steps 1 to 4 are an ordinary rotation, compressed. Step 5 is the one that ends the exposure, and it comes last because revoking first stops your own mail as well as the attacker’s.

The tension, stated honestly

The normal rotation has a drain window of several days before revocation, so that mail in retry queues keeps verifying. An exposed key does not get that courtesy — every hour it stays valid is an hour an attacker can sign with it.

Revoke as soon as the new key is live and signing. Hours, not days.
Accept that queued mail loses its DKIM pass. It may still pass DMARC on SPF, and if it does not, a small volume of delayed mail failing is a far better outcome than leaving a usable key in circulation.
Do not delete the record. Deletion makes the attacker’s signatures unverifiable; revocation makes them invalid. Only the second is a repudiation.
Leave the revocation published permanently. The attacker keeps the key forever. The empty p= is what makes it worthless forever.

Afterwards

Find out how long it was exposed, and read aggregate reports covering that window for signing activity from IPs you do not recognise. A valid signature from unfamiliar infrastructure is the evidence of use.
Check whether the key was shared across selectors or domains. If the same key pair was reused, every place it was published needs the same treatment.
Fix where the key lived. The exposure is the symptom. A private key that could be committed to a repository is a private key that will be again.

Revocation is not retroactive protection

Mail the attacker sent while the key was valid was authenticated at the time and has already been delivered. Revoking stops future abuse and does nothing about what is already in inboxes — which is why the exposure window is the number worth knowing, and why the response is measured in hours.

Knowledge check

Why publish the new key and switch signers before revoking the exposed one, when the exposed key is being actively abused?

Revoking first leaves your own mail with no valid signature until the replacement is live and resolving, so you break your delivery without ending the abuse any sooner.
Because a selector cannot be revoked while it is still in use by a signer.
Because receivers need to see both keys during the changeover.
Because the drain window for queued mail must elapse first.

Correct — Revoking first leaves your own mail with no valid signature until the replacement is live and resolving, so you break your delivery without ending the abuse any sooner. The replacement takes as long as DNS takes either way. Sequencing it first costs nothing in exposure time and avoids a self-inflicted outage on top of the incident.

Not this — Because a selector cannot be revoked while it is still in use by a signer. Nothing prevents it technically. Revoking a selector in active use simply invalidates the mail being signed with it.

Not this — Because receivers need to see both keys during the changeover. Each signature names its own selector and is verified independently. Receivers never need both, which is precisely why a new selector rather than a replaced key is the safe move.

Not this — Because the drain window for queued mail must elapse first. That is the rule for a routine rotation. An exposed key is the case where you deliberately cut the drain window short and accept the loss.

The order

The tension, stated honestly

Afterwards

Try it on a real domain