DMARCbis 对 DNS 查询次数的限制有哪些修改？RFC 9989 的 DNS 查询优化详情

DNS 查询效率一直是大型邮件服务商部署 DMARC 时面临的核心挑战。Gmail、Outlook、Yahoo 等大型接收方每天要处理数十亿封邮件，每封邮件至少需要一次 _dmarc.<domain> TXT 查询。DMARCbis 通过引入 dpub-domain 机制和其他优化措施，显著改进了这一场景。

一、原有 DMARC 的 DNS 查询问题

在 RFC 7489 下，每封收到的邮件都会触发以下 DNS 查询链：

1. 查询 _dmarc.发件域 TXT 记录（DMARC 策略）
2. 如果查到策略中有 rua/ruf，可能需要额外查询邮件域
3. 如果没有 DMARC 记录，尝试向上查找组织域
4. 对于子域名邮件，还需要查询 _dmarc.子域（失败后向上追溯）

对于大型邮箱服务商，问题在于：同一个服务商可能使用数百个不同的域名发送邮件。每封来自不同域的邮件都要消耗一次 DNS 查询，而域名的大量差异性导致了 DNS 缓存命中率低、查询延迟高。

二、dpub-domain（公开域）机制

2.1 核心概念

dpub-domain（DMARC Public Domain）是 RFC 9989 引入的全新概念。它允许一个组织或邮件服务商宣告一个"公开域"，接收方可以直接查询 _dmarc.<dpub-domain> 来获取该服务商所管所有域名的统一 DMARC 策略。

2.2 dpub-domain 的 DNS 记录格式

; 在邮件服务商的 dpub-domain 上添加
_dmarc.dpub-domain.com. TXT "v=DMARC1; p=reject; d=example.com,example.org,other.com;"

; d= 参数列出该 dpub-domain 覆盖的所有域名

接收方在处理来自 example.com 域的邮件时，如果无法缓存该域的 DMARC 记录，可以尝试查询 _dmarc.dpub-domain.com（发现器机制：接收方通过 dpub-domain 发现方法找到服务商的默认 dpub-domain）。

2.3 dpub-domain 的发现方法

接收方可以通过以下两种方式发现 dpub-domain：

1. DPUB DNS 记录：服务商可在 _dmarc.<domain> 的 DMARC 记录中添加 dpub=<dpub-domain> 标签，显式指向其公开域
2. 启发式发现：接收方可以根据邮件 Received 链中发送 MTA 的域名推断 dpub-domain（例如发送 IP 的 PTR 记录指向 mail.dpub-domain.com）

三、DNS 查询优化的实际效果

根据 RFC 9989 附录的估算数据，dpub-domain 机制可以为大型接收方减少高达 30%-50% 的 DMARC DNS 查询量：

• 无 dpub-domain：每次收到来自陌生域名的邮件都需要一次 _dmarc.<domain> 查询
• 有 dpub-domain：只需查询一次 _dmarc.<dpub-domain> 即可覆盖大量域名
• DNS 缓存命中率：从典型的 40% 提升到 70% 以上
• 查询延迟：平均减少 20-80 毫秒（取决于 DNS 配置）

四、DSCP 域名的查询限制

RFC 7489 对 DSCP（Domain Services Control Provider）域名的 DNS 查询没有明确限制。DMARCbis 规定：

• 接收方对每个邮件域名的 DMARC 记录查询，最多不应超过 5 次（含向上追溯）
• 如果经过 dpub-domain 优化，整个查询路径应控制在 3 次以内
• DNS 超时或 NXDOMAIN 应被视为"无 DMARC 记录"，而非永久失败
• 接收方应实现 DNS 缓存，TTL 小于 1 小时的记录可以按 1 小时缓存

五、对接收方实现的建议

1. 实现 dpub-domain 发现逻辑（支持显式 dpub= 标签和启发式发现）
2. 缓存优先：先检查本地 DNS 缓存，再发出 DNS 查询
3. 并行查询：同时查询 _dmarc.<domain> 和 _dmarc.<dpub-domain>（如果已知）
4. 对超时或临时 DNS 故障，应使用之前的缓存结果或回退到 p=none