映射邮件系统实际做出的决策
有用的电子邮件依赖关系图将业务发送服务与其使用的身份、 DNS记录和传输服务连接起来。每一个的列表 TXT记录 还不够。该地图应该让所有者回答如果提供商、主机名、密钥或策略发生变化可能会出现什么问题，并在批准该更改之前确定所需的证据。
将出站身份认证和入站传输策略作为单独的分支。他们可能共享管理员和域，但不保护相同的决策。这里提出的地图是一个运营模型，组织必须从其自己的授权清单和消息证据中填充该模型。这并不是说DNS扫描可以发现每个发送者或确定所有接收者行为。
以真实的发送路由启动每个出站分支
为每项服务和实质上不同的路线创建一个条目，包括定期计费、支持系统和外部管理的活动。记录其业务所有者、技术所有者、可见作者域、信封域、发送基础设施和观察到的 DKIM 签名域名和 选择器。将每个值标记为观察到的、由提供商记录的或仍然未知的。请勿将供应商的通用设置指南转变为该帐户配置的证据。
这 SPF 分支从评估的身份开始，并遵循与该路由实际相关的策略条款。包括外部政策参考和控制它们的团队。 RFC 7208第 2.3 节和 4.6.4 节 解释身份评估和 DNS 相关限制。依赖关系图可以显示外部更改可能影响评估的位置，但节点的静态计数并不能确定每个连接地址的结果。
DKIM分支以签名的 d 和 s 值开始，并通向选择器的验证记录。添加任何别名目标、目标区域所有者和密钥生命周期所有者。 RFC 6376第3.6.2.1节 定义此查找名称空间。将私钥放在地图之外；记录安全操作所有权并参考经批准的密钥管理系统。
将身份验证连接到相关DMARC决策
添加作者域（适用） DMARC 政策记录以及如何发现政策的证据。将经过身份验证的标识符链接到 结盟 决定，确定严格或宽松模式。在下面 RFC 9989第 4.4 节，有效对齐的SPF或DKIM标识符可以满足DMARC ；两个不相关的身份验证过程无法建立对齐。
记录用于策略发现评估的规范和实施上下文。 RFC 9989 描述了一个 DNS树遍历，因此应该审查继承的关于发现的电子表格假设，而不是默默地继续下去。该地图应保留有关其实施尚未得到验证的接收者的不确定性。包括报告目的地及其所有权，但将报告可用性与已观察到每个合法发件人的证据分开。
显示所有者请求的策略和接收者在不同字段中观察到的处理。这使得未来的审阅者更难将策略字符串误认为是邮件被拒绝、已发送或放入收件箱的证据。
新增独立运输分支
对于入站邮件，将收件人域连接到其MX主机及其地址依赖项。如果 MTA-STS 部署后，添加发现TXT记录、HTTPS 策略主机、证书维护所有者、发布模式、允许的MX名称和策略生命周期。 RFC 8461第 3 节和第 6 节 描述发现和缓存。策略生存期与DNS TTL 不是同一字段，更改其中一个字段不会直接重写另一个字段。
在哪里 DANE SMTP已部署，映射 DNSSEC 链， MX分辨率， TLSA 记录和相应的TLS服务。 RFC 7672第 2 节 使经过身份验证的DNS成为核心依赖项。在没有验证和证书关系的情况下复制到清单中的 TLSA 记录是不完整的操作证据。
添加TLS报告作为观察渠道，而不是作为执行机制。 RFC 8460第 3 节 定义报告策略发现。报告目的地需要所有者和审查流程，而实际的运输政策仍然是一个明显的依赖项。
提供商迁移的虚构示例
虚构组织“Example Repairs”计划将发票邮件转移给新供应商。其提议的地图将发票服务链接到billing.example.com作为作者域、一个单独的信封域和通过别名托管的旧DKIM选择器。迁移所有者注意到，退休的提供者仍然控制着别名目标，并且一些排队的消息可能携带旧签名。
因此，审查提出分阶段签署变更、验证替代路线以及单独批准的退役决定。同时，入站MX和MTA-STS条目仍然是不同的分支，并且不会作为出站供应商移动的一部分进行自动编辑。这个例子是发明的；身份、批准和消息结果尚未从真实账户获得。
地图的好处在于它揭示了一个问题：什么证据允许在不破坏合法消息验证的情况下撤销该别名？地图本身并没有回答这个问题。服务所有者必须提供队列和签名信息，审核者必须将这些事实与提议的更改联系起来。
使用地图维护证据和所有权
为每条边提供最后验证日期、证据参考、所有者和审核触发器。在供应商迁移、选择器轮换、委托更改、传输策略编辑或无法解释的身份验证失败后重新访问它。未知的所有者和未经验证的边缘应该保持可见，而不是充满猜测。
在推出之前，构建逐个发送者的准备矩阵、准确的策略差异和批准记录。授权执行后，附上相关消息和DNS观察结果。这些是目录所需的原始工件，并在此处保持打开状态。本手稿提供了地图设计和虚构的决策练习，而不是填充的租户库存或经过验证的部署。