当电子邮件发件人清单可以解释哪些服务使用域、该服务为何被授权以及其消息如何验证时，它非常有用。提供商名称或源 IP 地址列表本身无法回答这些问题。
围绕业务工作流程及其身份构建清单。将观察到的证据与批准分开，并将维护作为软件购买、更改和退役方式的一部分。
定义导致操作的记录
使用一项负责任的服务或工作流程作为记录的起点。提供商可以托管多个客户帐户，并且一个应用程序可以使用不同的路线进行活动、收据和密码重置。
- 服务和工作流程：标识正在调查的业务功能。
- 业务和技术所有者：确定谁可以批准使用和更改设置。
- 从身份可见：命名用户看到的域。
- 信封和签名身份：连接实际的 SPF 和 DKIM 路径。
- 提供商帐户和路由：将您的配置与共享基础设施区分开来。
- 证据和批准状态：将观察、调查和授权使用分开。
- 审查和退休条件：保持记录最新。
对帐户详细信息和证据链接使用适当的访问控制。清单应指向受控记录，而不是成为私钥或可重用管理凭据的存储库。
从观察和业务知识两方面入手
汇总报告 可以揭示值得研究的源模式。原始接收的消息和发送提供商日志可以添加身份和路由证据。
企业主可以识别短期观察窗口中未出现的定期服务。采购和申请记录还可以显示在中央邮件团队之外购买的服务。
将这些输入结合起来，而不是将其中一个视为完整的。观察到的 IP 可能属于共享基础设施或中介。购买的产品可能已停用或配置为使用其他发送服务。
将归属与授权分开
为条目提供明确的状态，例如已观察、正在调查、已批准、例外或已退休。定义在它们之间移动需要哪些证据。
一个可识别的品牌名称不足以获得认可。确认客户特定的帐户或路线，旨在从身份和业务目的出发。同样，未知的故障源也不会自动成为攻击者。
明确记录不确定性。得到调查负责人支持的假设比随后无人能解释的看起来自信的标签更有用。
验证实际工作流程
对于每个关键路线，通过用户依赖的服务发送受控消息。在接收方保留原始文件并比较其可信结果、来自域、信封身份和相关签名。
DKIM公钥演示了一种配置依赖性。它并不表明应用程序正在与其签名。通过员工邮件测试并不能确定计费应用程序共享相同的路由。
使用 结盟 原始身份验证和可见身份不同的诊断。将验证结果和配置记录链接到库存条目。
在DNS之前进行入职更改清单
考虑一个综合示例：新的客户支持工具要求管理员添加SPF包含。该公司已经将该提供商用于不同的帐户。
现有提供商标签不批准新帐户。在假设审查中，团队应首先记录服务所有者、支持的身份、路线和所需的权限。批准和消息验证是必需的后续步骤，而不是针对本文执行的操作。
这可以避免两种常见的失败：在没有所有权的情况下授权不熟悉的服务，并假设共享的提供商名称意味着现有的设置涵盖了所有内容。
关闭变革和退休的循环
当服务更改其域、签名者、网关或发送模型时触发审核。记录异常是否是暂时的、谁拥有它以及什么关闭它。
退休时，请确认合法使用已结束，然后再删除权限或 选择器 代表团。包括定期工作流程和获得的系统。保留历史决策记录，以便可以调查不熟悉的后续观察结果。
有用的库存可以在人员变动后继续存在，因为另一个操作员可以跟踪服务、所有者、身份、批准和证据。使用它来支持策略选择、非发送域决策和正在进行的报告调查。
拟议的库存设计由 NIST CM-8 组件责任，不是强制性的特定于电子邮件的模板。 RFC 9989第 5.3.5 节 定义消息级别 DMARC 结果; RFC 9990第 3.1 节 描述汇总观察结果。两者都没有建立内部业务批准。
将下一次调查附在记录中
当观察到某项服务但未归因时，请列出与帐户和工作流程相匹配所需的证据。当归因但未经批准时，将决定传递给企业主。如果获得批准但未经测试，请安排授权代表测试。这些是不同的州，而不是一个绿色库存徽章。