DMARC quarantine 与 reject：如何从 p=none 平稳过渡而不丢失正常邮件

1. p=none、quarantine 和 reject 分别要求收件方做什么

位于 _dmarc.example.com 的 DMARC 记录中，p 标签说明：对于 From 域名未通过 DMARC 的邮件（即 SPF 和 DKIM 都没有针对与之对齐的域名通过验证），你希望收件方如何处理。这只是一个请求。RFC 9989 是 2026 年 5 月发布、取代 RFC 7489 的 DMARC 标准，它把最终决定权留给各收件方的本地策略。

有两点会影响上线方式。第一，p=none 本身不提供任何保护；它只生成报告，而且前提是记录中有 rua 地址。第二，各收件方的执行方式并不一致。RFC 9989 要求它们不要仅因为策略写着 reject 就拒收，有些收件方会改为隔离此类邮件，因此同一次策略变更在不同邮箱服务商那里可能表现不同。请把这次升级规划成一系列小而可回退的步骤，而不是一次性切换。

大型邮箱服务商已经要求批量发件人具备 DMARC 记录，但接受 p=none。SPF 与 DMARC 检查指南列出了它们的要求，并解释了记录中的每个标签。

2. 如何阅读 DMARC 聚合（rua）报告

聚合报告是安全升级的基础。在记录中加入报告地址，例如 rua=mailto:dmarc-reports@example.com，发送报告的收件方就会给你发来压缩的 XML 文件，通常覆盖一个 UTC 日，列出所有以你的域名作为 From 发信的 IP 地址及这些邮件的处理结果。格式由 RFC 9990 定义。形如 receiver.example!example.com!1791590400!1791676800.xml.gz 的文件名依次给出报告方、你的域名，以及以 Unix 时间戳表示的周期起止时间。

文件中的每个 <record> 按来源和结果对邮件分组。以下字段最重要：

最后一行与 policy_evaluated 之间的差别，是最值得掌握的一点。邮件群发平台可能在 auth_results 中显示 mailer.example.net 的 DKIM pass，但 DMARC 仍然失败，因为该域名与 example.com 不对齐。只有 policy_evaluated 才告诉你 DMARC 的结论。

要连续阅读数周的报告，而不是只看一天：月度发票、季度通讯和年度续费通知各有自己的发送周期。数据量稍大时，直接看原始 XML 很繁琐；用能按来源、对齐情况和每日处理结果分组的解析器或报告工具，复核才切实可行。并非每个收件方都会发送聚合报告，所以一周安静不代表域名安静。如果 rua 地址位于另一个组织域名下，该域名必须发布以 v=DMARC1 开头的授权记录，例如 example.com._report._dmarc.reports.example.net，否则收件方会忽略该地址（RFC 9990 第 4 节）。

3. 强制执行前，找出每一个正常发件源

只有清楚知道哪些系统会把你的域名放在 From 中，强制执行才是安全的。请从两个方向建立清单：组织实际使用的系统，以及报告中出现的来源。典型来源：

• 邮箱平台：员工每天使用的邮件系统。
• 营销与通讯邮件，包括某人仍在登录的旧营销工具。
• 事务邮件：应用发出的注册确认、密码重置和收据。
• 业务工具：CRM、开票与账单、客服系统、人事与招聘、日历和电子签名服务。
• 网站表单和插件，以 noreply@example.com 的名义发信。
• 设备和脚本：扫描仪、监控告警、定时任务和本地中继。

然后把报告中的每个来源与清单中的条目对应起来。对 IP 地址做反向查询（dig +short -x 192.0.2.10）往往能得知服务商名称，服务商文档会说明其支持的 SPF include 和 DKIM 配置。把结果保存在类似下面的表格里：

最后一行正是这项工作的目的。当所有已知来源都通过后，仍然失败的大多是伪造或配置错误的邮件，而这正是强制执行应当拦截的。发送频率很低的来源最容易被遗漏，所以在相信某个安静的月份之前，先问问财务、人事和客服他们用了哪些工具。

4. SPF 与 DKIM 对齐：宽松还是严格

当 SPF 或 DKIM 通过并且其通过验证的域名与 From 域名对齐时，DMARC 才算通过。只需一项对齐通过即可。对 SPF 而言，检查的是信封发件人域名（RFC 7208）；对 DKIM 而言，检查的是有效签名中的 d= 值（RFC 6376）。aspf 和 adkim 标签决定匹配的严格程度：

• 宽松（r，默认值）：两个域名共享同一个组织域名，因此 bounce.example.com 和 news.example.com 都与 example.com 对齐。
• 严格（s）：两个域名必须完全相同。

RFC 9989 通过 DNS Tree Walk 确定组织域名，即从完整域名向上逐级查询 _dmarc 记录，取代了 RFC 7489 所依赖的公共后缀列表。

RFC 9989 指出，几乎所有域名所有者都认为宽松对齐已经足够。严格对齐会破坏“每个服务商使用专用退信子域名”这一常见做法，因此除非有具体理由，否则保持默认值，例如子域名委托给了供应商，而宽松对齐会让为 vendor.example.com 验证通过的邮件冒充 example.com 通过。无论如何选择，都应让 DKIM 成为每个发件源的对齐方式。邮件被转发时 SPF 会失效，因为转发服务器不在你的记录中；只要邮件内容没有被修改，DKIM 签名通常能在转发后保留。

5. 分阶段上线：pct 已移除，改用 t=y

较早的指南用 pct 分阶段推进：p=quarantine; pct=10，然后依次提高到 25、50 和 100，让策略覆盖越来越大比例的失败邮件。在 RFC 7489 下，抽样之外的邮件适用低一级的策略。RFC 9989 移除了该标签；其附录 A.6 解释说，除 0 和 100 之外的取值通常没有被准确应用，而且不同实现之间的偏差很大。

这一移除有个尖锐之处。RFC 9989 要求收件方忽略不认识的标签，所以遵循新标准的收件方会把 p=quarantine; pct=25 当作普通的 p=quarantine，并应用于所有失败邮件。部分 pct 值不能再用来限制影响范围。

替代方案是测试标志 t。设置 t=y 时，收件方被要求按比已发布策略低一级的方式处理：p=quarantine; t=y 按 none 处理，p=reject; t=y 按 quarantine 处理。报告照常发送，收件方可以用原因 policy_test_mode 记录这一偏离。RFC 9989 将 t=y 和 t=n 描述为 pct=0 和 pct=100 的对应物。

过渡期内，有些收件方仍只实现 RFC 7489 并忽略 t，较新的则忽略 pct。由于旧规则下的 pct=0 与新规则下的 t=y 要求相同的处理方式，测试期间可以同时发布两者：

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

观察报告几周，然后同时删除这两个标签，让 p=quarantine 全面生效。在升级到 reject 之前重复同样的做法：p=reject; t=y; pct=0 要求收件方做隔离，删除这两个标签后 reject 才真正启用。

你也可以按邮件流而不是按百分比分阶段。news.example.com 这样的子域名可以有自己的 DMARC 记录，比主域名更早或更晚进入强制执行；RFC 9989 自己的部署示例就是先在子域名上用 t=y 测试 p=quarantine，再进一步收紧。

6. 子域名策略：sp 和 np

example.com 上的 DMARC 记录同样覆盖没有自己 _dmarc 记录的子域名。有两个标签可让子域名策略与 p 不同：

几条规则让行为可预测。sp 只在组织域名处的记录中有意义；发布了自己记录的子域名由该记录的 p 管辖。在 p 仍为 none 时设置 np=reject 是风险较低的早期步骤：来自 billing-support.example.com 这类虚构名称的伪造邮件会被拒收，而不支持 np 的收件方只会回退到 sp 或 p。依赖它之前，请确保你实际用来发信的每个子域名至少有一条 DNS 记录，这样它才算存在。还要记住，SPF 不会继承：无论 DMARC 策略如何，每个用作信封发件人的名称都需要自己的 SPF 记录。

7. 从 p=none 到 p=reject 的现实时间表

没有适合所有域名的时间表，RFC 9989 也提醒，域名所有者可能需要数月的报告才能做好强制执行的准备。对于用户会向邮件列表发信的域名，它建议至少在 p=none 停留一个月，并在 p=quarantine 停留同样长的时间、对比结果，即便如此也表示这类域名不应发布 reject。发件服务不多的组织可以这样规划：

每次变更之前，至少提前一个旧 TTL 的时间调低 _dmarc TXT 记录的 TTL，例如调到 300 秒，这样回滚能很快传到解析器。把变更安排在一周的早些时候，告诉客服团队需要关注什么，并为发布的每个值保留带日期的记录。RFC 9989 要求任何发布 p=reject 的域名用有效的 DKIM 签名为邮件签名，而不能只依赖 SPF。Reject 并非唯一的理想终点：对员工会用于邮件列表的域名，监控良好的 quarantine 可能是更好的选择，而只用于发票和通知的域名则非常适合 reject。

8. 正常邮件失败时：诊断、修复、回滚

迟早会有报告或同事指出正常邮件失败。在聚合报告中找到对应的行，或索取受影响邮件的完整邮件头并阅读其 Authentication-Results 头，然后对照以下模式：

如果失败规模较大，或影响收据、密码重置等关键邮件，先回滚，再调查：加上 t=y 和 pct=0，或恢复到之前的策略。TTL 较短时，变更会在几分钟内传到大多数解析器。5xx 拒收是永久性的，已被拒收的邮件之后不会再投递；请告诉受影响的团队哪些邮件需要重发。然后修复发件源，在几天的报告中确认它已通过，再继续推进。用 ARC（RFC 8617）保留认证结果的转发器和邮件列表会有帮助，但 RFC 9989 指出目前还没有这样的机制被广泛使用，所以为每个发件源配置 DKIM 仍是可靠的解决办法。

9. 如何检查已发布的 DMARC 记录

检查实际发布的内容，而不是 DNS 控制台显示的内容：

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

前两行显示解析器返回的结果；最后一行直接查询权威服务器，能在缓存过期之前看到变更。请确认：

• _dmarc 处恰好有一条以 v=DMARC1 开头的 TXT 记录；如果有两条，收件方会把两条都丢弃，域名的表现就像没有 DMARC 记录；
• v=DMARC1 是第一个标签，p 的值为 none、quarantine 或 reject；
• rua 邮箱存在，并且若位于另一个域名下，已用 _report._dmarc 记录授权；
• 标签以分号分隔，没有从文档中粘贴进来的排版引号或多余字符。

然后从每个发件服务向你控制的邮箱发一封邮件，阅读 Authentication-Results 头：出现 dmarc=pass 并带有你的 From 域名，就是收件方的结论，也是真正算数的结论。

想快速获得外部视角，可使用免费的 SPF 和 DMARC 记录检测工具，它读取你输入的确切主机名上的 _dmarc 记录，不会回退到父域名。它会提示缺少记录（中等级别，前提是该主机有 MX 记录）以及 p=none（低级别，表示监控模式）；quarantine 和 reject 不会触发提示。它不读取你的报告，也不评估 sp、np、t、pct、rua 或对齐情况。同一项邮件 DNS 检查还会读取 SPF、MTA-STS 和 CAA，它是免费上线准备快照中八项被动检查之一，无需注册，返回总分和每项检查的结果。如需持续复查的流程，请参阅 DNS 与邮件安全指南。