一个终端显示一次 DNS 查询及其简洁答案,旁边是打印的规范页面,铅笔在某一行做了标记

read receipts

十秒读懂一家公司的 DMARC 策略(以及它无法告诉你什么)

这条记录表明域名所有者希望如何处理伪造邮件,是公开的、一次查询就能得到。这是一个陈述的偏好——不是垃圾邮件过滤器,也不是对你收件箱的承诺。

·5 分钟

一次 DNS 查询可以告诉你一家公司要求全球邮件服务器如何处理以其名义发送的伪造邮件。这条记录是公开的,命令只有一行:dig +short TXT _dmarc.example.com。返回的是一个简短的设置字符串,其中有一个指令——p=none、p=quarantine 或 p=reject——它表示当使用该域名的消息认证失败时,域名所有者的偏好。

现行规范 RFC 9989 发布于 2026 年 5 月,是 IETF 标准轨道文档,替代了较早的 RFC 7489。它几乎简洁地定义了这三个值:

  • p=none ——"域名所有者不表示任何偏好。"
  • p=quarantine ——"域名所有者认为此类邮件可疑。邮件可能是有效的,尽管认证失败引起了重大关切。"
  • p=reject ——"域名所有者认为所有这类失败都明确表示该域名的使用无效。"

再读一遍这些词,因为它们的含义比大多数关于 DMARC 的解释所承认的要弱。策略是发送者为接收者考虑而发布的一个偏好。它不是接收者必须执行的指令。RFC 9989 用一句话说明了这一点:"任何消息的最终处理始终是本地策略的问题,由邮件接收者自行裁定。"同一节还补充了两个方面的后果——接收者"可以选择拒绝或隔离一条消息,即使它通过了 DMARC 验证检查",他们"不应该仅因为发布的'拒绝'策略就拒绝消息",这正是为了防止以 DMARC 无法描述的方式发送的合法邮件和邮件列表被破坏。

那么 p=none 实际上承认了什么?比通常指责的要少。根据规范的说法,这是监控模式:域名所有者正在收集聚合报告并"对认证失败的消息不表示处理偏好",而部署 DMARC 的接收者"仍然可以"验证该域名的使用。它不会在接收端关闭任何东西。你的提供商的垃圾邮件过滤、信誉评分、URL 检查和附件分析是独立运行的机制,不受发送者发布的内容影响。到达 p=none 域名的伪造消息不会因为这条记录而被提升到你的收件箱;它只是被交给接收者,没有陈述的偏好,接收者做出决定。

误解的另一半则相反。DMARC 不读取钓鱼邮件的危险部分。其规范本身列出了有意排除的内容,"内容分析"就在其中,用这些确切的词。它还指出 DMARC"不处理视觉上相似的域名或对 RFC5322.From 人类可读显示名称的滥用"——这两个技巧承载了大多数品牌冒充邮件。在通过的价值方面:"DMARC 本身的通过不保证传递到收件人收件箱会是安全或可取的。"从一个一次性域名发送的经过正确认证的消息干净地通过 DMARC。DMARC 只回答谁被授权在 From: 头中使用该域名。仅此而已。

这是 2024 年的大量发件人规则经常被误报的地方,包括本文的第一个版本。Google 的发件人指南要求每天向 Gmail 账户发送 5,000 条或以上消息的发件人"为你的发送域设置 DMARC 电子邮件认证",然后说,同一瞬间:"你的 DMARC 执行策略可以设置为 none。"Yahoo 自己的 Sender Hub 必须单独阅读,而不是假设它复制 Google,将要求陈述为"发布至少 p=none 的有效 DMARC 策略 - DMARC 必须通过",并根本不发布任何数值体积阈值。两套要求从 2024 年 2 月开始生效。两者都不强制任何人离开 p=none。两者实际强制的是身份验证对齐:Google 要求"发件人 From: 头中的域必须与 SPF 域或 DKIM 域一致",Yahoo 说宽松对齐是可接受的。对齐而非严格性是关键。

这就留下了域名处于监控状态的真正原因,它是运营性的而非怯懦。转移到 quarantine 或 reject 意味着首先找到以你的名义发送邮件的每项服务——工资单、售票系统、营销、无人记录的支持部门——并对其进行认证以确保对齐。标准本身承认了使这一过程缓慢的风险:第三方发件人既不被 DMARC 引入也不被排除,转发和邮件列表可能通过无人知晓的对齐破坏,规范指向接收者查阅 RFC 7960 来处理这些确切的失败模式。发布 p=none 并阅读其报告的组织正在按照规范描述的顺序进行工作。发布 p=none 但忽略报告的组织则不然。从外部看,单独这条记录无法告诉你你看到的是哪一种。

你不需要终端来查看。免费查询工具——dmarcian 的域名检查器、MXToolbox 的 DMARC 检查——可以获取记录并为你打印策略。对你的银行、工资单提供商、你乘坐的航空公司进行查询。只要根据它的含义来读答案:域名所有者的意图声明,是你的邮件提供商自主做出的决定中的众多输入之一,关于一种特定类型的伪造。这是可以在十秒钟内读懂的真正有用的东西。它不是对下一条声称来自该品牌的消息是否安全的裁定。

更正,2026 年 10 月 20 日。本文的早期版本将 p=none 描述为将伪造物传递到收件箱,p=reject 作为唯一阻止欺骗消息的设置,说 2024 年 Google 和 Yahoo 的大量发件人规则强制发件人离开 p=none,并引用了大约三分之一的域名处于执行状态的数字。根据 RFC 9989 已更正策略描述;Google 和 Yahoo 实际上都接受 p=none,上述引自他们自己的文档;执行数字已被删除,因为基础报告不发布其样本或分母。本文现在还说明了 DMARC 不检查的内容。

The weakest DMARC policy, and the one both Google and Yahoo accept from bulk senders under rules in force since February 2024

来源

  1. RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF, Standards Track, May 2026; obsoletes RFC 7489. Policy values §4.7, Monitoring Mode §3.2.12, out-of-scope list §2.4, policy enforcement §5.4
  2. Google — Email sender guidelines — Requirements in force from 1 February 2024, including "Your DMARC enforcement policy can be set to none" and the 5,000-messages-a-day threshold (checked 20 October 2026)
  3. Yahoo Sender Hub — Best practices — Yahoo's own bulk-sender requirements: "Publish a valid DMARC policy with at least p=none"; no numeric volume threshold published (checked 20 October 2026)
  4. DMARC.org — Overview — Plain-language introduction to SPF, DKIM and identifier alignment
  5. dmarcian Domain Checker — Free lookup that fetches and reads a domain's DMARC record

← 全部文章