DMARC 执行缺口持续存在：2026 年 68.4% 的公司域名缺乏执行力度

DMARC 执行缺口持续存在：2026 年 68.4% 的公司域名缺乏执行力度

概述

DMARC 自 2012 年以来一直作为一种免费的 DNS 记录存在，用于告知接收邮件的服务器如何处理身份验证失败的电子邮件。在 CipherCue 对 67,336 个公司域名进行的 2026 年快照调查中，68.4% 的域名要么没有 DMARC 记录，要么记录设置为 p=none，这意味着它们没有执行隔离（quarantine）或拒绝（rejection）。

执行缺口详情

在受调查的 67,336 个域名中，30,362 个 (45.1%) 没有 DMARC 记录。在发布了记录的 36,974 个域名中，15,709 个 (占有记录域名的 42.5%，占所有域名的 23.3%) 被设置为 p=none。只有 10,258 个域名 (占总数的 15.2%) 使用 p=quarantine，10,963 个域名 (占总数的 16.3%) 使用 p=reject。因此，46,071 个域名 (占总数的 68.4%) 要么缺乏记录，要么拥有非执行性的 p=none 策略。

为什么 p=none 持续存在

从 p=none 转向执行的主要障碍是解读每日聚合报告 (rua=) 所需的工作量。每个启用了报告功能的域名都会收到一份列出所有声称来自该域名的发件源列表。为了实施执行，管理员必须逐一决定发件人是否合法。rua= 地址指向大量一次性的、通常是哈希处理过的邮箱（例如 ivrejeuw@ag.c1.dmarcian.com，a.8hyzr404@sdmarc.net），这些邮箱没有明确的所有者，使得政策执行变成了一项被推迟处理的研究任务。

谁在运行 DMARC 监控

通过将 rua= 报告地址域名与供应商字典进行比对，在 29 个指定目的地中识别出 8,862 个实体。前几大目的地是 Brevo (1,297 个实体, 14.6%)、Proofpoint (1,094, 12.3%)、Valimail (1,068, 12.1%) 和 Cloudflare (978, 11.0%)。如果仅限于核心产品为 DMARC 监控的供应商，Valimail、DMARC Analyzer、dmarcian、DMARC Advisor、EasyDMARC、Red Sift、PowerDMARC 和 Fortra (Agari) 合计占 3,619 个实体 (占已识别实体的 40.8%)。

国家层面的差异

该样本库中执行情况因国家而异：

  • 波兰：64.6% 无记录，16.3% p=none，11.3% p=quarantine，7.7% p=reject。
  • 荷兰：51.1% 无记录，21.1% p=none，14.2% p=quarantine，13.6% p=reject。
  • 德国：45.7% 无记录，26.3% p=none，12.9% p=quarantine，15.0% p=reject。
  • 美国：42.1% 无记录，19.0% p=none，16.7% p=quarantine，22.2% p=reject。
  • 意大利：40.9% 无记录，36.8% p=none，11.7% p=quarantine，10.5% p=reject。
  • 英国：37.0% 无记录，19.2% p=none，18.3% p=quarantine，25.5% p=reject。
  • 西班牙：36.9% 无记录，29.5% p=none，18.1% p=quarantine，15.5% p=reject。
  • 法国：43.0% 无记录，29.1% p=none，12.8% p=quarantine，15.1% p=reject。 美国和英国的 p=reject 占比最高 (22.2% 和 25.5%)，而意大利尽管无记录率相对较低，但 p=none 的占比最高 (36.8%)。

相关 DNS 控制措施

除了 DMARC，该样本库还显示：

  • 48,962 个域名存在 SPF (72.7%)。
  • 36,974 个域名存在 DMARC (54.9%)。
  • 1,726 个域名存在 BIMI (2.6%)。
  • 957 个域名存在 MTA-STS (1.4%)。
  • DNSSEC 在全链验证下显示为 0.0%；作者指出这是测量限制，并不代表没有任何域名配置了 DNSSEC。 在启用了 SPF 的域名中，52.4% 使用硬失败 (-all)，43.1% 使用软失败 (~all)。

最近的 RFC 变更

2026 年 5 月，IETF 发布了三项取代 RFC 7489 的标准轨道 RFC：

  • RFC 9989：核心 DMARC 协议（现为标准轨道，建议标准）。
  • RFC 9990：聚合报告 (rua=)。
  • RFC 9991：失败报告 (ruf=)。 对现有记录的实际影响很小；v=、p=、sp=、rua=、ruf=、adkim=、aspf= 和 fo= 标签保留其含义。一个实质性的变化是用 DNS 树遍历取代了用于组织域名发现的 Public Suffix List 查询，从而消除了对外部列表的依赖。

SOC 2 和 ISO 27001 考量

SOC 2 和 ISO 27001:2022 都没有普遍要求将 DMARC 作为指定的控制措施。SOC 2 评估组织选择的控制措施是否满足信任服务标准；DMARC 可作为电子邮件身份验证风险管理的一部分使用，但未被列为示例。ISO 27001:2022 附录 A 控制措施 5.14 (信息传输) 范围足够广泛，可以涵盖电子邮件身份验证，而无需特别提及 DMARC。

示例域名

Cranswick (cranswick.co.uk) 发布了一个 p=none 的 DMARC 记录，包含三个 rua= 地址：dmarc_agg@vali.email、一个在 eu.cp-dmarc.com 上的自注册邮箱，以及一个在 rua.easydmarc.eu 上的哈希地址。这说明单个域名可以聚合来自多个不相关目的地的报告，要求管理员在转向执行之前先对这些数据流进行整合。

方法论说明

数据来自 CipherCue 自身的 DNS 观测（针对 DMARC、SPF、MTA-STS、BIMI、DNSSEC 的直接查询），执行时间为 2026-04-14 至 2026-07-28，涵盖 67,336 个域名。计数单位是域名而非去重后的组织；如果一家大公司拥有多个域名，可能会出现多次。供应商映射使用了手动维护的包含 40 个已知 rua= 报告端点域名的字典，这只是底线而非普查。DNSSEC 结果仅反映全链验证。

社区见解 (HN 评论)

评论者强调了几个实际和认知障碍：

  • 一些小型运营商质疑，在 SPF 和 DKIM 已经有效的情况下，DMARC 能带来什么附加价值。
  • 其他人指出，DNS 变更通常由理解有限的员工进行，导致配置仅停留在 p=none 的复制粘贴状态。
  • 有人认为主要邮件提供商会忽略滥用报告，降低了 DMARC 的感知收益。
  • 有人建议，没有电子邮件（或没有 MX 记录）的域名可能会被计入“无记录”组，从而扭曲了统计数据的相关性。
  • 一些评论者声称 DMARC 增加了复杂性却未能提高收件箱信任度，因为垃圾邮件通常能通过 SPF/DKIM/DMARC。
  • 相反，一些用户描述了使用 LLM 自动化 DNS 变更的方法，包括通过 Terraform 添加 DMARC 记录。 这些评论强化了文章的观点：主要缺口不在于对 DMARC 存在的认知，而在于从监控转向执行所需的运营工作量。

Sources