A 和 AAAA 记录将主机名映射到IPv4和IPv6地址。它们是邮件服务的依赖项，而不是服务已准备好或已授权发送的声明。发布地址可以公开客户端实际尝试的路由，因此请验证每个公布的系列和端点。
遵循协议使用的名称
参考： RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.
对于入站SMTP ，解析MX返回的交换主机名。当显式交换无法使用时，收件人域的网站地址不能替代。如果不存在MX ，则SMTP的隐式 MX 规则可以使收件人域自己的 A 或 AAAA 记录相关。
对于出境 SPF，检查实际政策并评估身份。一个 a 机制可以授权为其指定名称返回的地址；一个平原 一个记录 本身不授权任何事情。同样，更改SPF使用的主机名 MX 机制可以更改评估为授权的地址。在将DNS地址编辑视为仅网站更改之前，记录这些引用。
将双栈视为两条操作路径
参考： RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.
一个主机名可以有多个 A 记录和多个 AAAA 记录。它们的存在并不保证可达性、 SMTP服务、正确的证书或等效策略。健康的IPv4端点并不能证明IPv6可以正常工作。相反，一个客户端路径上的故障并不能证明每个发送方都使用该路径。
捕获实际尝试的目标地址、地址族、连接结果和SMTP响应。如果调查出站流量，请捕获外部观察到的源地址，而不是假设它与应用程序内部使用的地址匹配。 NAT 和提供商出口池可以使这些值不同。
重现地址族故障
合成夹具： example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com 。 AAAA 2001:db8::10。在实验室中，将IPv4端点配置为接受端口 25 上的 TCP 连接，并使IPv6端点无法访问。预期的DNS检查对于两种记录类型都成功，而特定于系列的连接测试仅对于IPv4成功。
询问 挖掘@AUTH mx.example.com 。 A+无递归 然后使用相同的命令 AAAA。将 AUTH 替换为隔离的权限。记录两个答案。使用您认可的实验室SMTP客户端独立固定每个目标，记录连接和协议结果。该装置说明了为什么DNS成功并不意味着服务成功；它没有声明特定发件人的回退时间。
第二个夹具仅更改 A 地址 192.0.2.10 到 192.0.2.20 而SPF策略是 v=spf1 a:mx.example.com -all。对于具有其他成功查找的IPv4 SPF评估，地址有资格匹配 a 机制变化。明确的 ip4:192.0.2.10 相反，机制将保持与该文字网络的联系，直到策略本身发生变化。
使地址更改可逆
参考： RFC 8767 §4.
清点主机名的所有使用者，包括邮件路由、 SPF引用、监控和证书期望。在公布端点之前准备好端点。保留旧服务，同时适当的缓存仍然可以将流量引导到那里，基于实际的迁移计划而不是普遍的等待期。
更改后，将权威答案与递归观察和消息级证据进行比较。出现故障的IPv6端点应通过批准的更改进行修复或删除，而不是通过削弱不相关的身份验证策略来隐藏。仅当预期地址和操作路径与记录的服务设计匹配时才结束工作。
保持证据范围明确
对于两个家庭的场景，在测试之前将预期的IPv4成功和IPv6失败保留为建议的实验室观察结果。 SPF地址更改示例假定查找成功并采用规定的策略；它不会为任何真正的发件人建立当前授权。