一个妥协的 DKIM 私钥可以让攻击者创建在受影响的签名域下进行验证的签名。将该事件视为签名授权事件。替换DNS记录只是遏制的一部分，仅靠DKIM验证无法区分授权签名者和持有相同密钥的攻击者。
建立受影响的机构
使用私钥识别签名域、选择器、密钥保管人和每项服务。保留相关的审核日志、配置和代表性可疑消息，而无需将机密复制到票证或聊天中。记录发现时间、可能的暴露窗口以及已知与可疑的情况。
将私钥盗窃与未经授权的签名服务访问分开。具有帐户访问权限的攻击者可能会在密钥轮换后继续签名，除非包含该访问权限。 DNS管理妥协是另一个需要自己响应的依赖项。在事件负责人的领导下协调这些调查。
停止新的滥用并撤销旧的验证路径
通过批准的事件流程暂停受影响的签名路线或凭证。 RFC 6376允许通过发布空 p 值来撤销。一旦发现钥匙缺失，取出钥匙也会阻止成功检索。选择平台支持的响应并验证准确 选择器 和更改之前的域。
撤销并不是对每个接收者都是即时的。已评估的缓存DNS数据和消息创建了一个与时间相关的边界。请勿承诺更改DNS会追溯性地使已发送邮件中的签名无效或证明不接受任何滥用邮件。
正常轮换重叠保留了对排队合法消息的验证。在妥协过程中，保持暴露的密钥可验证也可以保留攻击者的能力。事件所有者必须权衡遏制措施和延迟邮件故障，而不是自动应用例行重叠时间表。
通过干净的路径恢复签名
解决暴露原因后，通过受信任的支持流程生成替换密钥材料。更喜欢新的受支持的选择器，以便可以区分新旧证据。应用当前的加密要求。对于 RSA 签名， RFC 8301需要 rsa-sha256 而不是 rsa-sha1，并建议至少 2048 位 键。
说明性响应：选择器 sales1 已公开，并且包含其签名帐户。干净的签名者使用 sales2，而 sales1 被撤销。新的受控邮件与 sales2 进行验证并与 From 保持一致；与 sales1 签署的延迟邮件可能会失败。这个例子描述了一个明确的权衡，而不是一个完整的事件或通用接收者行为的保证。
验证恢复并保持不确定性
测试每一条受影响的路由，而不仅仅是一个邮箱。保存原始消息和可信结果，检查新选择器，确认 结盟 并验证受损的凭据不再授权签名。查看暴露期间的提供商日志和接收者报告，注意报告并未涵盖每个接收者或证明每条消息的发送者。
维护遏制、 DNS观察、替换部署和客户影响评估的时间表。保持取证副本的访问控制。仅与已确定的所有者联系以结束事件，以进行后续调查并纠正密钥保管或访问故障。成功的新签名证明恢复路线有效；它本身并不能确定早期滥用的全部范围。
在紧急情况发生之前锻炼一下桌面
在此综合时间线中，服务帐户 A 持有 sales1，干净帐户 B 持有 sales2。在零分钟，包含 A。在第一分钟，发布 sales1 撤销。在第二分钟，虚构的解析器仍然拥有其旧的缓存密钥，因此旧的签名可能仍然可以在那里验证。在第三分钟，开始干净的 sales2 路线。在第 30 分钟，收集每个路由收到的结果并访问证据，而不是仅声明从DNS恢复。这些时间说明了排序，而不是承诺的传播间隔。
该书面桌面提出了五个必需的恢复观察：旧访问被禁用、暴露原因被包含、新密钥已发布、新签名已验证和新签名已对齐。新邮件通过但旧访问仍处于活动状态的情况无法通过恢复门。满足所有五个条件的场景会通过建模门。两组观察结果都是综合的；没有执行桌面程序、租户或消息测试。在真实事件期间仍然需要实际遏制、缓存观察、批准和消息测试。
为每个未解决的恢复门分配一个所有者
书面案例 KEY-01 假设替换选择器 sales2 为 From sales@example.org和d=example.org,但旧服务帐户仍保持活动状态。事件所有者必须保持恢复开放并解决访问控制问题；邮件管理员成功的签名测试无法弥补这一差距。旧的解析器缓存和过去的滥用范围仍然未知。身份和结果是规定的教学假设，而不是执行的事件。