DMARC 自 2012 年公开，仍有 68.4% 的域名未强制执行

# DMARC 自 2012 年就已公开。但仍有 68.4% 的公司域名未强制执行。 来源：https://ciphercue.com/blog/dmarc-enforcement-gap-rua-fragmentation-2026 DMARC 自 2012 年就已存在。它是一种免费的 DNS 记录，告诉接收邮件服务器如何处理未能通过你的域名身份验证的电子邮件：是报告、隔离还是直接拒绝。它主要关注的是在可见的 `From` 地址中未经授权使用域名；它无法阻止相似域名注册、显示名称欺骗或来自已受攻击的合法账户的网络钓鱼邮件。十四年后，我们在 2026-04-14 到 2026-07-28 期间检查了 CipherCue 跟踪实体集中的 67,336 个域名的 DNS 记录。这是 CipherCue 数据集的一个快照，并非全球所有公司的统计代表性样本；下面的方法说明介绍了该群体是如何构建的。其中 30,362 个（45.1%）仍然没有这样的记录。 有记录的域名也并未前进太多。只有 10,963 个（占拥有记录域名的 29.7%）实际执行了某些措施：`p=reject`，身份验证失败的邮件会被丢弃。10,258 个（27.7%）设置为 `p=quarantine`，即进入垃圾邮件文件夹但不阻止。最大的单一组群是 15,709 个域名（42.5%），它们设置为 `p=none`。`p=none` 策略会收集身份验证数据和聚合报告，但不要求接收邮件系统隔离或拒绝未通过 DMARC 的邮件。在此分析中，强制执行意味着发布了 `p=quarantine` 或 `p=reject` 的策略；使用 `p=none` 的域名被视为未强制执行。 截至我们最近的观察窗口，42.5% 拥有 DMARC 记录的域名仍处于 p=none 状态，仅收集报告而不要求隔离或拒绝 `p=none` 本应是一个临时监控阶段，通常持续几周，之后你再转向强制执行。在标准发布十四年后，对于我们数据中最大的单一域名组群来说，这看起来像是永久状态。 把两者结合起来看，情况比单独看任何一个数字都更触目惊心：在我们检查的所有 67,336 个域名中，46,071 个（68.4%）要么没有 DMARC 记录，要么有但未强制执行策略。在这个数据集中，发布 DMARC 记录已不再是主要的采用差距；从监控转向执行才是。 68.4% 的已检查域名没有 DMARC 记录，或者有记录但未强制执行策略（无记录：45.1%；有记录但 p=none：占总数的 23.3%） ## 策略细分详情 10,258 p=quarantine 15.2% 占所有 67,336 个已检查域名的比例，不仅仅是那些有记录的 状态|域名数量|占所有已检查域名的比例|占拥有记录域名的比例 ---|---|---|--- 无 DMARC 记录|30,362|45.1%|n/a p=none（仅监控）|15,709|23.3%|42.5% p=quarantine|10,258|15.2%|27.7% p=reject（完全强制执行）|10,963|16.3%|29.7% ## 为什么 p=none 无法推进 通常的解释是惰性或无知。我们的数据指向了一个更具体、更机械化的原因：没有人能确定实际发送邮件的是什么。 每个开启了 DMARC 报告标志的域名都会收到每日聚合报告（`rua=`），列出每个声称来自该域名并发送邮件的来源，无论其身份验证是通过还是失败。转向强制执行意味着需要逐一检查该列表，并决定“是的，那是我们发送的”或“不，阻止它”。我们提取了 36,974 条 DMARC 记录中的原始 `rua=` 地址，并统计了这些报告实际发送的位置。 10,268 个不同的 rua= 报告域名，分布在 26,179 条报告地址条目中；其中 8,113 个（79%）在我们的数据中只出现一次 其中一些集中在少数几个显而易见的地方：Proofpoint 自己的报告端点出现了 1,605 次，Cloudflare 出现了 1,273 次，dmarcian 的各种区域端点（`ag.eu.dmarcian.com`，`ag.us.dmarcian.com` 以及另外八个国家代码变体）合计超过 1,000 次，而 Brevo、Postmark、Barracuda 以及一批 DMARC 即服务供应商（EasyDMARC、PowerDMARC、dmarcian、Red Sift、DMARC Analyzer、dmarcly、sdmarc.net、hornetdmarc.com）填补了其余大部分。 但长尾才是新发现。一旦你超过大约前 60 个域名，地址就不再是知名的供应商，而变成了一个个单一用途、通常是哈希处理过的邮箱名称：`[email protected]`，`[email protected]`，`[email protected]`，一个在自己域名下自托管报告的公司（`[email protected]`，`[email protected]`），或者一个完全看不出端倪的邮箱（`[email protected]`）。管理员盯着这样一周的报告，看到的不是供应商列表。他们看到的是大量没有明确所有者的 IP 地址和发件人字符串，而决定是否强制执行意味着首先要识别出每一个。 这是一项研究任务，而不是配置更改，而且这正是一种会被无限期推迟的任务。我们认为这是上述 `p=none` 数字如此之高的最大单一原因。 ## 谁在运行 DMARC 监控 我们将 `rua=` 报告地址域名与我们能够自信识别的涵盖 DMARC 监控和邮件基础设施产品的供应商词典进行了映射。这是一个与仅匹配单一事实类型不同的、更广泛的测量：它在 29 个命名目的地中识别出 8,862 个实体，而仅使用预构建供应商词典时只能识别 1,400 个。这仍然是一个下限，而非上限。它只统计了我们能够自信归属的域名；上面描述的 8,113 个单一目的地在此处被排除，因为仅出现一次不足以让我们自信地命名供应商。 目的地|实体数量|占已识别实体的比例|说明 ---|---|---|--- **Brevo**|**1,297**|**14.6%**|事务性邮件平台（前身为 Sendinblue）；接收报告是发送邮件的一个副作用，而非 DMARC 产品 **Proofpoint**|**1,094**|**12.3%**|安全邮件网关；自己的报告端点（`emaildefense.proofpoint.com`） **Valimail**|**1,068**|**12.1%**|DMARC 监控/自动化产品 **Cloudflare**|**978**|**11.0%**|DNS/CDN 提供商；报告通过托管 DMARC 功能到达他们自己的域名，而非专门的 DMARC 产品 DMARC Analyzer|602|6.8%|DMARC 监控产品（荷兰创立，自 2020 年起成为 Vade 的一部分） dmarcian|584|6.6%|DMARC 监控产品，九个不同国家的区域端点 DMARC Advisor|407|4.6%|DMARC 监控产品 EasyDMARC|377|4.3%|DMARC 监控产品 Postmark|348|3.9%|事务性邮件平台；接收报告是发送邮件的一个副作用 MxToolbox|321|3.6%|提供 DMARC 报告阅读功能的 DNS 诊断供应商 Barracuda|267|3.0%|邮件安全/网关供应商 Red Sift (OnDMARC)|248|2.8%|DMARC 监控产品 PowerDMARC|184|2.1%|DMARC 监控产品 Fortra (Agari)|149|1.7%|邮件安全/DMARC 监控产品 其他（15 家供应商）|938|10.6%|dmarcly, GoDaddy, sDMARC, Red Sift（单独端点）, CheckPoint, Mailgun, Mailhardener, Everest, HornetSecurity, Kevlarr, LetsDMARC, report-uri, GlockApps, Cisco, UK NCSC 阅读此表需要表格本身无法承载的说明：Brevo、Cloudflare 和 Postmark 并非像 Valimail、dmarcian 或 Red Sift 那样的“DMARC 监控供应商”。它们接收聚合报告是因为域名所有者将 `rua=` 指向了它们平台上的一个邮箱，通常是因为该平台同时也是该域名的出站发送或 DNS 提供商，而不是因为域名所有者从它们那里购买了专门的监控产品。如果将表格限制为以 DMARC 监控为核心产品的供应商，那么 Valimail、DMARC Analyzer、dmarcian、DMARC Advisor、EasyDMARC、Red Sift、PowerDMARC 和 Fortra (Agari) 共同代表了 8,862 个已识别实体中的 3,619 个，占比 40.8%。在这个更窄的基数内，Valimail 是最大的单一供应商，占 29.5%，DMARC Analyzer（16.6%）和 dmarcian（16.1%）紧随其后；没有供应商占据多数，但市场也并非均匀分布。 ## 国家/地区细分 强制执行阶段因国家而异。在此群体中，波兰拥有最大比例的完全没有 DMARC 记录的域名；英国拥有最小比例的无记录域名，但一旦有了记录，其执法率也相应更高。 国家/地区|已检查域名数量|无记录|p=none|p=quarantine|p=reject ---|---|---|---|---|--- 波兰|7,039|64.6%|16.3%|11.3%|7.7% 荷兰|5,598|51.1%|21.1%|14.2%|13.6% 德国|12,152|45.7%|26.3%|12.9%|15.0% 美国|13,292|42.1%|19.0%|16.7%|22.2% 意大利|4,545|40.9%|36.8%|11.7%|10.5% 英国|1,493|37.0%|19.2%|18.3%|25.5% 西班牙|2,697|36.9%|29.5%|18.1%|15.5% 法国|5,125|43.0%|29.1%|12.8%|15.1% 美国和英国在此表中拥有最高的 `p=reject` 比例（分别为 22.2% 和 25.5%）。意大利则因另一个原因而突出：它具有较低的无记录率之一（40.9%），但同时拥有此表中所有国家中最高的 `p=none` 比例（36.8%），这一观察到的差异表明该群体中更多的意大利域名已开始 DMARC 过程并停留在仅报告阶段，尽管此处数据并未说明原因。这是 CipherCue 跟踪群体的一个快照，并非国家普查；有关该群体如何构建，请参阅方法说明。 ## 除了 DMARC 之外还缺少什么 DMARC 并非独立运作。SPF 和 DKIM 是 DMARC 建立在之上的两个身份验证机制；MTA-STS、DNSSEC 和 BIMI 是三种相邻的基于 DNS 的控制措施，它们解决相关但不同的问题。我们针对同一个由 67,336 个域名组成的群体检查了全部五种措施。 控制措施|功能|存在数量|占比 ---|---|---|--- SPF|授权哪些邮件服务器可以为域名发送邮件|48,962|72.7% DMARC|为未通过身份验证的邮件设置策略，并提供报告|36,974|54.9% BIMI|在支持的收件箱中显示经过验证的品牌徽标|1,726|2.6% MTA-STS|强制邮件服务器之间的传输使用 TLS 加密|957|1.4% DNSSEC|对 DNS 响应进行加密签名，以防止伪造|0|0.0% SPF 是这里最广泛采用的控制措施，这与它是最古老且最易于配置（一条 DNS TXT 记录，无需报告基础设施）的事实相符。在 48,962 个拥有 SPF 的域名中，25,657 个（52.4%）使用硬失败（`-all`），21,103 个（43.1%）使用软失败（`~all`），两者的区别在于对未通过 SPF 检查的邮件是“拒绝”还是“标记但接受”。 MTA-STS 和 BIMI 均低于 3%。DNSSEC 在此群体中显示零个已验证域名，我们将其作为测量说明而非研究发现来标记：CipherCue 当前的 DNSSEC 检查会验证完整的签名链，更严格的检查相比仅检查 DNSKEY 或 RRSIG 记录存在的宽松检查，通过的次数会更少。我们不会将 0.0% 当作声称群体中没有域名配置了 DNSSEC 的论断；我们可以自信地说，在我们的检查中，没有一个域名通过了完整的链验证，在我们审计了检查本身之前，我们将真实的采用率视为一个开放性问题。 ## 相关的 RFC 以及近期变化 DMARC 的核心规范在 2026 年发生了变化。**RFC 7489**（https://datatracker.ietf.org/doc/html/rfc7489），即 2015 年 3 月作为信息性、行业撰写的文档发布的原始 DMARC 规范，已被 2026 年 5 月发布的三个新的 IETF 文档取代： - **RFC 9989**（https://datatracker.ietf.org/doc/html/rfc9989）：核心 DMARC 协议 - **RFC 9990**（https://datatracker.ietf.org/doc/html/rfc9990）：聚合报告（本文所讨论的 `rua=` 报告） - **RFC 9991**（https://datatracker.ietf.org/doc/html/rfc9991）：失败报告（`ruf=`） 实际意义不在于 DNS 记录中的新标签，而更多在于其地位。RFC 7489 通过独立提交流作为信息性文档发布，意味着它从未经过 IETF 工作组的共识。RFC 9989 是标准跟踪（拟议标准），这是 DMARC 首次拥有正式的 IETF 标准状态。你已经在使用的标签，`v=`、`p=`、`sp=`、`rua=`、`ruf=`、`adkim=`、`aspf=` 和 `fo=`，保持其现有含义；你现在无需做任何更改。 一个实质性的机制变化是接收方如何找到没有自己 DMARC 记录的子域的“组织域名”。RFC 7489 使用了公共后缀列表，这是一个社区维护的文件，列明了哪些域名后缀被视为可注册（例如，知道 `co.uk` 是一个后缀，而非公司）。RFC 9989 用 DNS 树遍历取代了它：接收方在确切发送域名处检查 DMARC 记录，然后向上遍历域名树检查每个父域，直到找到一个或标签用完。这消除了对不属于 DNS 本身的外部维护列表的依赖。 本文中引用的两个相邻标准，供参考成熟度：**RFC 8461**（https://datatracker.ietf.org/doc/html/rfc8461）（MTA-STS）自 2018 年 9 月起已成为完整的 IETF 互联网标准。相比之下，BIMI 从未被 IETF 工作组采纳；截至本文撰写时，最新版本是个人互联网草案（第 14 版，日期为 2026 年 5 月），该草案明确声明“在 IETF 标准过程中没有正式地位”。这种地位上的差距是 BIMI 在我们数据中的采用率仅为 2.6%，而 SPF 为 72.7% 的一个合理解释：实施一个没有完成规范且需要额外认证成本（BIMI 需要来自少数机构的验证标记证书）的控制措施，比针对已批准标准添加一条 DNS TXT 记录更难推销。 ## SOC 2 或 ISO 27001 是否要求这个？ SOC 2 和 ISO 27001 都未普遍要求将 DMARC 作为一项具体指定的控制措施。组织仍可能将其作为针对电子邮件身份验证、冒充和域名滥用的基于风险的控制措施的一部分来实现。 **SOC 2** 基于 AICPA 的信托服务标准，而非固定的技术检查清单。审计师评估公司选择的控制措施是否满足标准（最常见的是安全性，有时也包括可用性、保密性、处理完整性或隐私）；公司选择自己的控制措施，而 DMARC 并非标准文档中命名的示例之一。 **ISO 27001:2022** 的工作方式相同。附录 A 控制措施 5.14“信息传输”要求有“规则、程序或协议”来管理信息在组织内部以及与第三方的移动，这足够广泛以涵盖电子邮件身份验证，但并未明确命名。2022 年修订版将 2013 版本中原本的四个独立控制（旧条款 8.7.1 至 8.7.4）合并为这一个控制措施。 ## 一个域名的具体表现 Cranswick，英国食品生产商（cranswick.co.uk），是数据集中的一个真实例子。其 DMARC 记录为 `p=none`，并列出了三个独立的 `rua=` 地址：`[email protected]`，一个在 `eu.cp-dmarc.com` 上自行注册的邮箱，以及一个在 `rua.easydmarc.eu` 上的哈希地址。一个域名对应三个不同的目的地，至少两家不同的 DMARC 监控供应商。这是一个公开的 DNS 记录；任何人都可以通过 `dig TXT _dmarc.cranswick.co.uk` 查询它。这在数据集中并不罕见，这正是关键所在：将三个独立的报告流协调成“谁在真正为我们发送邮件”，正是域名所有者要摆脱 `p=none` 之前必须完成的那种工作。 ## 方法说明 **来源和群体：** CipherCue 自己的 DNS 观测结果（直接查询 DMARC、SPF、MTA-STS、BIMI 和 DNSSEC），而非第三方数据集。67,336 个域名，观测时间为 2026-04-14 至 2026-07-28。这是域名计数，而非去重后的组织计数：一家大公司可能拥有处于不同强制执行阶段的多个域名，因此同一家公司可能出现多次。 **供应商映射**（“谁在运行 DMARC 监控”）使用一个手动维护的词典，包含 40 个已知的 rua= 报告端点域名，并识别出 8,862 个实体；这是一个下限，而非普查，因为只有当目的地与已知模式匹配时才会出现名称。 **DNSSEC** 显示为 0.0%，因为 CipherCue 的检查要求完整的签名链验证；请阅读上文关于此限制的讨论。