身份验证报告中的新来源是线索，而不是某人绕过批准的证据。它可能是新地址上的合法服务、间接传送路径、新报告的接收者或未经授权的使用。在添加权限或指控影子采购团队之前，先建立发送身份和服务关系。
保留观察结果
保留报告标识符、报告组织、间隔、源地址、计数、认证域和策略评估结果。区分用于的 From 域 DMARC 从一个 DKIM 签名域或信封域。聚合行对观察结果进行分组，而不是邮箱级别的转录本。 RFC 9990.
将新行与之前的可比较间隔和接收器进行比较。首次看到的源仅在您的数据集中首次出现。不要将其标记为全球新的或仅从提供商拥有的 IP 推断出新服务。共享基础设施和不断变化的出口地址使得仅地址白名单成为企业所有权的弱证据。
谨慎加入服务注册
有用的寄存器包含目的、客户特定的服务标识符、业务所有者、关键性、来自域、信封身份、签名身份、最后受控测试和批准参考。使用这些字段搜索批准的更改和应用程序所有权记录。已知的提供商名称是一条线索；需要将其链接到业务的服务实例或帐户证据。
DMARC检查经过身份验证的身份 结盟，不是采购审批。当未经授权的服务保留一致的签名权限时，它就可以通过。相反，已批准的服务可能会因为其路由配置错误而失败。将身份验证结果和授权结果分开。 RFC 9989.
使用显式调查状态
将结果分类为匹配并批准、匹配但未批准、归因待定或确认未经授权。保留最后的状态作为实际证据和负责任的决定。当归属待决时，不要自动添加 SPF 包括、委托 选择器 或降低域范围的策略。这些行动在调查确定需要之前就改变了权力。
假设新观察到的调查签名者与特定于客户的服务帐户相匹配，并且营销所有者确认了其目的，但当前没有可用的批准参考。记录缺失的批准并向负责的决策者询问授权历史记录。对于没有匹配帐户证据的第二个身份，保留归属待定并请求相关配置记录。这两项发现均未证实存在恶意或允许添加DNS权限。
这些是假设的输入，而不是连接的文件、实时报告或执行的分类。如果后来的批准记录仅涵盖不同的域或帐户，则保留实际观察结果未解决；熟悉的供应商标签不能扩大该决定的范围。
跟踪服务如何获取访问权限
如果服务是真实的，请检查授权配置历史记录：谁创建了其选择器、更改了SPF 、授予了集成或配置了中继。使用现有的读取权限和批准的证据。请勿未经授权登录陌生租户或代表他人发送测试消息。对于批准的路由测试，保留最终接收器的结果并将其与预期身份进行比较。
Microsoft 的应用程序邮件指南说明了传递方法为何如此重要：经过身份验证的提交、 SMTP中继和直接发送具有不同的先决条件和收件人范围。不要将所有应用程序邮件视为租户邮箱流量。 微软指导.
在其实际边界处解决异常
如果企业批准该服务，则通过正常流程启动该服务，最小化其权限并测试其真实路径。如果服务应停止，请与其所有者协调删除并保留关键流的回滚路径。通过事件流程升级已确认的恶意或受损活动，而不是将其视为普通的库存清理。
通过观察到的身份、归因证据、决策者和确切的变化来结束调查。添加维护触发器以供将来的身份或提供商更改。移除后的安静报告是支持证据，而不是根除的证据，因为报告的覆盖范围有限且可变。
上述调查状态和所有权决策是建议的操作工作流程。 NIST SP 800-53 Rev. 5 CM-8 提供了一般清单和责任基础；它不会从身份验证结果推断企业主。 NIST控制目录.