确定哪个 Microsoft 服务接收消息
“Microsoft 托管的邮件”并未标识一项通用转发策略。首先确定目标是Microsoft 365组织、消费者Outlook .com 帐户还是在到达 Microsoft 邮箱之前经过另一个安全服务的路由。不应假定一种环境中可用的管理控制和证据适用于另一种环境。
此工作流使用组织管理邮件的最新Microsoft 365文档，并需要验证实际路由。这是拟议的调查和变更计划，而不是检查或修改任何租户设置的报告。首先进行直接与转发的比较，然后选择最小的更改来解决已证明的故障，同时保留组织的安全控制。
找到身份验证发生变化的边界
绘制从原始发送方通过每个转发器或网关到接收服务的路径。对于每个边界，记录连接主机，可用 信封发件人, 作者域, DKIM 签名和观察到的转变。将入站第三方中介与向外转发邮件的Exchange Online分开来。即使它们都发生在同一个对话中，它们也是不同的操作案例。
SPF 使用最终连接源作为在那里评估的身份，因此原始源的授权可能不会描述转发连接。 RFC 7208第 10.3 节 解释了这一限制。分析师不应更改原始发件人的 SPF记录 直到了解受影响的身份和预期授权。
使用比较原始签名和最终签名 RFC 6376。当网关的内容更改之后更改所覆盖的材料时，可能会使签名无效 规范化。这是有条件的，而不是声称所有添加的标头或所有转发规则都会破坏DKIM 。在授权的地方保留原始消息副本，以便可以测试假设，而不是从供应商图表中推断。
读取 Microsoft 结果而不重命名它们
微软的 身份验证概述 区分SPF 、 DKIM和 DMARC 来自复合身份验证，记录为 compau。后者包含额外的评估。将每个字段和最终处理操作保留在单独的列中。复合通行证不应在事件记录中重写为普通DMARC通行证。
目前的 值得信赖的ARC密封剂指南 描述了使用合法中介机构的早期评估，并提供了 compauth=pass 和reason=130的诊断示例，而dmarc=fail仍然可见。它还警告其他过滤仍然可以发挥作用。这是特定于提供者的解释，用于在受信任的接收者生成的结果中进行验证，而不是保证相同的字段出现在每个帐户中。
不要轻信任意的 Authentication-Results 行只是因为它靠近粘贴标题的顶部。确定哪个接收系统生成结果以及如何识别可信边界。如果只有屏幕截图或摘录可用，请记录缺失的出处，并通过批准的流程请求适当编辑的完整样本。
保持 SRS 和ARC决策的区别
微软的 SRS 文档 关注适用的转发和中继场景，并明确将重写的 MAIL FROM 与可见的 From 分开。它还记录了例外情况。不要假设进入Microsoft 365每条消息都会收到相同的重写，或者将其视为向外发送 SRS 行为作为修复不相关的入站网关的行为。
重写的信封可以支持重写域的SPF ，而无需 结盟 给原作者。仍然需要相关的域关系 RFC 9989第 4.4 节. ARC 相反，传达早期的身份验证评估供接收者考虑。 RFC 8617第 7.2.1 节 描述了本地策略的使用，而不是自动替换普通认证结果。
任何信任密封者的建议都是安全决定。确定确切的合法服务、其运营需求和负责任的审批者；保留先前的配置和删除标准。不要仅仅因为消息携带语法上有效的ARC集而添加广泛信任。目前的 ARC重新分类草案 工作正在进行中，而RFC 8617在此审核日期仍处于实验阶段。
通过有界验收测试进行虚拟网关更改
在此虚构示例中，示例服务在Microsoft 365邮箱之前通过内容网关接收邮件。发明的直接样本验证了对齐 DKIM签名;等效的网关路由样本具有重写的附件，并且不再验证该签名。该场景假设这些观察结果只是为了解释调查。没有访问任何租户或消息。
业主首先要确定是否有必要进行改造，以及是否支持破坏性较小的配置。如果提出基于 ARC 的处理，则审查将需要实际的密封者身份、经过验证的链证据和特定租户的批准。验收标准将分别记录普通认证、综合结果、安全过滤和处置。仅凭成功的收件箱外观并不能证明预期的机制。
恢复标准应包括意外的广泛信任、新的错误分类或未能保留所需证据。回滚计划应该确定确切的批准配置，而不是简单地指示某人在消息到达之前禁用安全处理。
仅关闭已验证的路由
授权更改后，将新的直接和间接样本与代表性消息的基线进行比较。保留设置版本、时间戳以及任何剩余的提供商或租户的不确定性。通过一个网关的工作路径不会验证组织中的每条转发规则。
原始证据门保持不变且可见：直接和间接传递样本与路线、信封、签名和可信结果进行比较。这里不包括此类操作证据、租户批准、现场测试或恢复执行。可交付成果是一个可审查的过程，具有源支持的区别，而不是完整的Microsoft 365修复。