继承的发件人清单是一个决策工具，而不是 IP 地址列表。在标准化获取的域之前，将观察到的邮件连接到生成该邮件的特定于客户的服务、其业务所有者及其批准的身份。熟悉的提供商可以托管合法和不需要的流量，因此基础设施识别本身并不能获得批准。
从多个证据来源开始
收集授权配置导出、应用程序注册、供应商帐户记录、 DNS观察和可用的邮件证据。保留每个观察结果的来源和收集时间。 汇总报告 可以揭示源 IP 和身份验证模式，但无法独立确定组织的业务意图或完整的发件人群体。 RFC 9990.
对于每项服务，记录目的、责任所有者、提供商帐户或租户、关键性、可见域、信封域、 DKIM 签名身份、最后代表测试和批准证据。保持未知字段明确。分别记录可能处于休眠或防御状态的域的发送和接收目的。
添加权限之前先赋予身份
将观察到的标识符与实际的供应商配置和业务工作流程进行比较。 DMARC 用途 结盟 作者域和成功验证的标识符之间；没有标识符的通用通过结果可能会隐藏您需要解决的问题。 RFC 9989.
不要添加未知来源 SPF 只是因为邮件似乎是从那里发出的。 SPF为评估的身份授权主机，其评估包括DNS查找限制。 RFC 7208 ，第 4.6.4 节。新的包含可能会扩大权限、超出操作限制或无法修复对齐。首先建立预期的服务和适当的经过身份验证的路由。
将批准和测试分开
已批准的服务仍可能无法通过迁移测试；经过身份验证的消息仍然可能来自未经批准的服务。存储这两个状态。批准证据应确定负责任的决策，而测试证据应描述实际交易、身份、结果和时间。请勿使用测试通过作为企业所有权的替代品。
假设继承的计费服务具有指定的企业所有者和批准的用途，但目标帐户的签名身份尚未经过验证。第二个服务具有一致的传递消息，但没有确定的业务所有者。第一个在迁移之前需要路线证据；第二个需要归属和批准才能被视为授权服务。这两个差距都没有因为其他服务的令人放心的结果而得到解决。
这些是假设的库存决策，而不是生成的记录或执行的测试。为所有权、预期身份、批准和当前测试覆盖范围保留单独的字段。当应用程序所有者提供缺失的帐户证据时，仅更新其建立的状态；不要自动将未经测试的迁移结果更改为通过。
将归因转变为迁移计划
按经过验证的所有者、依赖性和准备情况对服务进行分组。在编辑记录之前定义预期的目标身份和测试。保留未知的路线以供调查，并指定所有者和截止日期，而不是默默地批准或删除它们。为每次后续转换保留旧配置和批准的恢复计划。
标准化后，根据批准的清单协调实际观察结果并调查新的身份。让退休人员及其决策载入史册。有用的库存通过供应商变更和事件响应保留为运营记录，而不是合并项目结束时废弃的电子表格。
此库存和审核工作流程是推荐的操作模型。 NIST SP 800-53 Rev. 5 CM-8 和 CM-3 为负责任的库存和受控变更提供了一般基础；他们不规定这些特定于电子邮件的字段或授予批准。 NIST控制目录.