Defaults.Exposed › 报告
盲目发布：大多数 DMARC 记录不索取任何报告
发布于 2026-07-03 · 更新 2026-07-03
数据截至 2026-06-29 · 方法论 v7。 普查覆盖了每一个发布可解析 DMARC 记录的域名，并按域名去重。
rua=的存在情况是在所有记录中测量的，因此它与任何单一策略的确切重叠无法推导出来——本文在提及此类重叠时，只会给出上下界，绝不给出确切的交叉列表。所有数据均为汇总数据——我们从不发布任何单个企业的评级。
大多数 DMARC 记录并没有在观察
在发布了 DMARC 记录的 65 百万个域名中，只有 23 百万个——即 35.7%——包含索取汇总报告的 rua= 标签。其余 64.3% 都在盲目发布： 记录上有一条策略，但没有人要求被告知在这条策略下正在发生什么。这就意味着有 42 百万个域名的 DMARC 记录无法向它们展示任何信息。
一条没有报告的 DMARC 记录就像一个无人应答的门铃。邮件接收方尽职地拿每一封邮件与之核对——而它们的发现，也就是所有以你的域名发信者的名单，却无处可去。机制在运转；只是所有者没有在听。
rua= 实际上做了什么
DMARC 有两个部分。策略部分（p=none、quarantine 或 reject）告诉接收方如何处理未通过身份验证的邮件。报告部分——rua= 标签，即一个邮箱地址——请求接收方每天向你发送汇总报告：哪些服务器以你的域名发信、发了多少邮件，以及邮件是否通过了 SPF 和 DKIM。
第二个部分就是整个反馈闭环。报告让你发现那个没人记录过的邮件列表平台、市场部接入的那个开票工具、以及另一个地区的影子发信方——在你实施强制策略并把它们弄坏之前。没有 rua=，这些情报都无法送达你手中。添加它只需一次 DNS 修改：在现有记录后追加 rua=mailto:[email protected]（或某个监控服务的地址）。
第 2 阶段和第 3 阶段之间的鸿沟：已发布却盲目
在 DMARC 成熟度的六个阶段 中，第 3 阶段——观察——始于 DMARC 已发布且汇总报告开始流入之时。一条没有 rua= 的记录并不达标。它处于第 2 阶段和第 3 阶段之间的鸿沟里——已发布却盲目——这是该模型有意留白、不赋予其自身编号的位置。
这一点很重要，因为其后的每个阶段都依赖于报告。你无法从从未收到的报告中识别出你的发信方（第 4 阶段）；你也无法在不了解发信方的情况下安全地实施强制策略（第 5 阶段）。一条盲目的记录不是这段旅程上的早期一步——它是紧挨着旅程旁边的一处停靠带。而普查表明，大多数记录持有者都停在那里或附近：所有 DMARC 记录中有 57.5% 从未达到强制策略。
比毫无用处更糟，因为它让人感觉像是进展
一条缺失的 DMARC 记录至少看起来就是它本来的样子：一个空缺。而一条盲目的记录看起来像是打了一个勾。有人跑了一遍合规清单、或一份可送达性指南、或某个供应商给的一行修复——发布了 v=DMARC1; p=none——扫描器就变绿了。这个组织现在感觉比那个根本没有记录的组织走得更远，而实际上处在同样的境地：没有可见性、没有强制策略、也没有通往任何一者的路径。
后果是无声而累积的。盲目的记录不会大声报错；它们只是永远不会产生那些能为下一步提供依据的证据。多年之后，记录仍然写着 p=none，没有人能说清哪些发信方是合法的，而实施强制策略比以往任何时候都更让人觉得有风险——恰恰是因为从未收集过任何报告。
普查能说什么、不能说什么
由于 rua= 的存在情况是在全部 65 百万条记录中测量的——而非按策略交叉列表——因此从这些边际数据中无法推导出既是 p=none 又是盲目的记录的确切数量。但上下界依然触目惊心。37 百万条记录（占记录持有者的 57.4%）停在 p=none；而整个普查中只有 23 百万条记录索取报告。因此这些 p=none 记录中最多只有 23 百万条能够收到报告——而其中至少 14 百万条肯定没有收到，即便普查中的每一个报告地址都属于某个 p=none 域名也是如此。无论重叠实际上落在何处，都有数百万个域名停在”监控模式”，而监控器却被拔掉了插头。
一次修改即可解决
如果你的 DMARC 记录没有 rua= 标签，修复方法只需一次 DNS 更改，而且在任何策略级别都是安全的：
- 选择一个报告目的地——一个你真的会去处理的邮箱，或者一个免费/付费的 DMARC 监控服务，它会把 XML 转换成可读的内容。
- 将它追加到记录中：
v=DMARC1; p=none; rua=mailto:[email protected]。如果目的地是另一个域名，该域名必须授权接收你的报告（在它那一侧添加一条小小的额外 DNS 记录）。 - 等待几天，然后阅读。 主要接收方每天都会发来报告。它们所展示的内容——每一个以你的域名发信的来源——就是这段旅程后续的地图。
然后这条记录就不再是摆设，而开始成为一件仪器。（修复 DMARC →。）
常见问题
什么是 DMARC rua 报告？ 这是一份汇总的 XML 报告，由参与的邮件接收方（通常每天）发送到你记录中 rua= 标签所指定的地址，概述哪些来源以你的域名发信，以及邮件是否通过了 SPF 和 DKIM 对齐。它不包含任何邮件内容——只有发信方基础设施和通过/未通过的计数。
没有 rua 的 DMARC 是否毫无价值？ 并非毫无价值——即使没有它，一条强制策略仍能阻止仿冒。但在 p=none 下，一条没有 rua= 的记录既不阻止任何东西，也不向你展示任何东西——它唯一剩下的作用就是勾上邮箱服务商的最低要求那一栏。而且即便是实施强制策略却没有报告的域名，也会失去那种在新发信方出现时保持强制策略安全的漂移检测能力。无论如何，p=none 不是保护——没有报告，它甚至称不上是准备。
rua= 可以指向任何邮箱吗？ 可以，包括位于另一个域名上的邮箱——大多数监控服务正是以这种方式工作的。接收域名会发布一条小小的验证记录来授权你的报告。真正重要的是，确实有某个东西在处理这些 XML；一个没人阅读的邮箱只是多绕了几步的盲目。
汇总报告会暴露私密数据吗？ 不会。rua 汇总报告携带的是发信来源和身份验证统计信息，而非邮件正文或收件人名单。（单独的 ruf= 失败报告可能包含邮件片段，这也是为什么许多接收方不再发送它们——rua 才是重要的那个。）
检查你的记录是否在观察
一条不索取任何报告的 DMARC 记录，是整段旅程中最容易修复的发现之一——一次 DNS 修改就能把盲目变为观察。你可以私密且免费地进行检查，看看在 34 项检查中你通过了哪些，以及如何修复那些没通过的。
检查你的域名 → · DMARC 成熟度的六个阶段 → · DMARC 支柱 → · 仅汇总数据。数据在欧盟境内存储与处理。