A compromised DKIM private key can let an attacker create signatures that verify under the affected signing domain. Treat the event as a signing-authority incident. Replacing a DNS record is only one part of containment, and DKIM verification alone cannot distinguish an authorized signer from an attacker holding the same key.
Establish the affected authority
Identify the signing domain, selectors, key custodian and every service using the private key. Preserve relevant audit logs, configuration and representative suspicious messages without copying the secret into tickets or chat. Record discovery time, likely exposure window and what is known versus suspected.
Separate private-key theft from unauthorized access to a signing service. An attacker with account access may continue signing after a key rotation unless that access is contained. DNS administration compromise is another dependency requiring its own response. Coordinate these investigations under the incident owner.
Stop new misuse and revoke the old verification path
Suspend affected signing routes or credentials through the approved incident process. RFC 6376 permits revocation by publishing an empty p value. Removing the key also prevents successful retrieval once the absence is visible. Choose the response supported by the platform and verify the exact selector and domain before changing it.
Revocation is not instantaneous across every receiver. Cached DNS data and messages already evaluated create a time-dependent boundary. Do not promise that changing DNS retroactively invalidates signatures in delivered mail or proves that no abusive messages were accepted.
Normal rotation overlap preserves verification for queued legitimate messages. During compromise, keeping the exposed key verifiable can also preserve an attacker's capability. The incident owner must weigh containment against delayed-mail failures rather than applying the routine overlap schedule automatically.
Restore signing through a clean path
Generate replacement key material through a trusted supported process after addressing the exposure cause. Prefer a new supported selector so old and new evidence can be distinguished. Apply current cryptographic requirements. For RSA signing, RFC 8301 requires rsa-sha256 rather than rsa-sha1 and recommends at least 2048-bit keys.
Illustrative response: selector sales1 is exposed and its signing account is contained. A clean signer uses sales2 while sales1 is revoked. New controlled mail verifies with sales2 and aligns with From; delayed mail signed with sales1 may fail. This example describes an explicit trade-off, not a completed incident or a guarantee of universal receiver behavior.
Verify recovery and preserve uncertainty
Test every affected route, not just one mailbox. Save raw messages and trusted results, inspect the new selector, confirm alignment and verify that compromised credentials no longer authorize signing. Review provider logs and receiver reports for the exposure period, noting that reports do not cover every receiver or prove who sent each message.
Maintain a timeline of containment, DNS observations, replacement deployment and customer-impact assessment. Keep forensic copies access-controlled. Close the incident only with an identified owner for remaining investigation and a corrected key-custody or access failure. A successful new signature proves the recovery route works; it does not by itself establish the full scope of earlier misuse.
Exercise a tabletop before an emergency
In this synthetic timeline, service account A holds sales1 and clean account B holds sales2. At minute zero, contain A. At minute one, publish sales1 revocation. At minute two, a fictional resolver still has its old cached key, so old signatures may remain verifiable there. At minute three, start the clean sales2 route. At minute thirty, collect per-route received results and access evidence rather than declaring recovery from DNS alone. These timings illustrate ordering, not a promised propagation interval.
This written tabletop proposes five required recovery observations: old access disabled, exposure cause contained, new key published, fresh signature verified and fresh signature aligned. A scenario with new mail passing but old access still active fails the recovery gate. A scenario satisfying all five passes the modeled gate. Both sets of observations are synthetic; no tabletop program, tenant or message test was executed. Actual containment, cache observations, approvals and message tests remain required during a real incident.
Assign an owner to each unresolved recovery gate
Written case KEY-01 assumes the replacement selector sales2 produces a passing aligned signature for From sales@example.org with d=example.org, but the old service account remains active. The incident owner must keep recovery open and address access containment; a mail administrator’s successful signature test cannot close that gap. Old resolver caches and past abuse scope remain unknown. The identities and results are stipulated teaching assumptions, not an executed incident.