定义基线要证明什么
身份验证基线是对预期配置的批准描述以及在特定时间支持它的证据。它不仅仅是DNS编辑器的屏幕截图、所需记录的列表或未来所有邮件都将进行身份验证的声明。有用的基线连接域、发送服务、记录所有权、预期的身份验证路径和验证标准。版本控制使更改变得可解释；审查确定预期配置是否仍然适合业务。
本文提出了基线和变更控制工作流程。未创建存储库、导出配置、编辑DNS记录或测试消息。协议参考确定了配置的含义，而版本控制过程是编辑操作建议，而不是标准强制使用特定工具的声明。在收集实际观察结果之前，基线必须与当前生产行为的证明分开。
在记录之前捕获身份和责任
对于每个发送工作流程，记录业务目的、域所有者、服务运营商、可见域、预期信封身份和 DKIM 签署一个或多个域。确定谁可以批准变更以及谁可以执行变更。 DNS管理员可以控制发布，而供应商可以控制签名，企业主可以确定是否应该存在发送流。这些责任不应被压缩到一个模糊的“所有者”字段中。
RFC 9989 定义 DMARC的域对齐关系。因此，基线应该识别预期的对齐路径，而不是仅记录该路径 SPF 或DKIM已启用。 RFC 6376 定义DKIM签名和 选择器 模型。记录重要的选择器和公共查找依赖项，但切勿将私有签名密钥、API 机密或恢复凭据放在通用配置基线中。
保留完整的相关记录集
与区域和权威提供商一起记录观察到的准确DNS所有者名称、类型、完整值和 TTL。将提供者-编辑者表示法与已发布的DNS表示法分开。对于TXT数据，区分一条记录中的多个字符串和一组中的多个记录。显示选定行的屏幕截图可能会省略其他值，并且不一定支持安全替换操作。保留足够的结构来解释完整的预期更改。
Azure DNS记录文档 描述记录集、 TXT字符串和特定于提供者的元数据。它是 Azure 模型的有用证据，而不是每个提供商的通用架构。如果实际提供者不同，请在应用工作表之前验证其当前表示并更新行为。基线可以使用中立的表示，同时保留原始提供者导出作为证据及其收集时间和限制。
将预期状态与观察到的状态分开
使用不同的部分来表示已批准的目标配置和从生产中收集的观察结果。所需的SPF值并不能证明权威服务器已发布该值。 DNS应答并不能证明提供商使用预期选择器签署了消息。接收消息结果并不能证明每个发送工作流都使用相同的路径。每项观察均应说明其范围、时间、收集方法及其涵盖的身份。
使用时 Authentication-Results 作为验证证据，遵循信任边界问题 RFC 8601。保留来自相关受信任接收方的结果，而不是接受任意发送方携带的断言。将经过编辑的消息证据和完整的敏感原件保存在适当的访问控制下。基线应参考经批准的证据位置，而不是仅仅为了方便而积累机密消息正文或凭证。
让每次修订成为一个可解释的决定
分配内部版本标识符并记录先前批准的版本、变更原因、预期差异、受影响的工作流程、风险评估和业务签核。可读的差异应该在完整的上下文中显示添加、删除和替换。它应该确定是否引入了供应商、轮换了选择器、删除了过时的发件人或更改了策略。不要让仅格式化的更改隐藏对授权或授权的有意义的更改 结盟.
选择适合组织工具的审查机制，但不要假设版本控制提交等同于批准。分别记录决策主体和审批范围。定义如果观察到的当前配置与执行前的预期基线不同，会发生什么情况。安全的响应是调查并协调差异，而不是仅仅因为存在准备好的更改文件就覆盖较新的状态。
考虑并发编辑和回滚限制
Azure DNS记录了与区域和记录集关联的 Etag，并解释了它们如何检测更新期间提供的并发更改。这是特定于提供商的并发机制，而不是一般的DNS属性。 TTL 控制缓存行为，而不是谁可以编辑 一个记录 或者一项更改是否会覆盖另一项更改。确认实际接口的并发行为，并保留授权变更所使用的版本证据。
回滚标准应确定技术触发因素和授权决策者。恢复材料需要之前的完整配置、相关的提供者状态和已知的依赖关系。恢复DNS记录可能无法恢复已删除的供应商资源、撤消已发送的邮件或立即替换缓存的答案。将恢复计划为协调的工作流程，而不是承诺复制旧值会逆转所有后果。在准备本草案时没有尝试回滚。
基线审查工作表
创建包含基线版本、域和工作流范围、业务目的、配置所有者、执行所有者、准确记录清单和预期身份验证路径的工作表。添加带有日期、已知差距、源文档版本和审核触发因素的证据参考。对于拟议的修订，包括预期的差异、业务批准、先决条件、并发检查、验证标准、回滚标准和最终处置。明确标记未观察到的结果，而不是将其隐含在已完成的设计审查中。
审核触发因素可以包括新发件人、供应商退役、域迁移、密钥轮换、企业所有权变更或材料身份验证事件。日历审查也可能有所帮助，但其频率应反映组织风险和变更量，而不是发明的通用间隔。检查基线是否仍涵盖所有合法工作流程以及已停用的依赖项是否仍然存在。不要将未更改的文件视为生产环境没有发生变化的证据。
虚构的诊断：未记录的供应商添加
一个虚构的组织有一个经过批准的基线，涵盖其计费服务和员工邮件。营销团队随后通过单独的供应商介绍了另一个发件人。基线保持不变，而准备好的DNS清理将删除新服务使用的依赖项。在建议的练习中，审核者在批准清理之前将当前所有权和工作流程记录与基线进行比较，并发现文档差距。
该团队将协调新的工作流程、获得业务签核、更新预期的差异并在授权更改后收集验证证据。不会因为之前获得批准就盲目恢复旧基线。这个场景是虚构的：没有发现供应商，没有应用配置差异，也没有进行交付测试。它说明了为什么版本历史必须与当前所有权和操作观察配对。
发布基线，其局限性可见
有用的审查结论指出了哪些工作流程被涵盖，哪些观察结果支持它们以及哪些尚未验证。它不承诺普遍交付或永久安全。当内容、声誉、帐户泄露或接收者策略影响邮件结果时，身份验证控制可能是正确的。基线应该使这些边界可见，以便未来的操作员不会将配置记录误认为是完整的安全评估。
该目录需要包含基线、预期差异、业务签核、验证和回滚标准的变更记录。原始运营记录仍然开放。该草案提供了拟议的结构，而不是执行的变更证据。人类专家审查、来源适用性、生产路线、视觉可访问性和所有者发布也保持开放。可发布的版本需要经过真实观察和批准的授权示例，并在不泄露秘密的情况下进行适当的编辑和保留。