DMARC.

Domain-based Message Authentication, Reporting and Conformance (DMARC) 由 RFC 7489 定义,在 SPF (RFC 7208) 和 DKIM (RFC 6376) 之上,要求可见的 From: 域名与经 SPF 或 DKIM 认证的域名之间存在标识符对齐。这弥补了这两个协议留下的缺口:SPF 和 DKIM 各自都能验证某个域名,但都不能保证它就是收件人实际看到的那个。域名所有者在 _dmarc.<domain> 发布一条 TXT 记录,其中包含策略 (p=none、quarantine 或 reject)、子域处理方式 (sp=)、对齐模式 (aspf/adkim,宽松或严格)、发布百分比 (pct=) 以及报告 URI (rua、ruf)。

部署与执行

安全的部署路径是先用 p=none:聚合 XML 报告 (RFC 7489) 会揭示每一个合法发送方——包括被遗忘的营销和票务平台——从而可以先完成认证,再收紧到 quarantine,最后到 reject。跳过这一步会使真实邮件石沉大海。

DMARC 是 BIMI 的基础(仅在 p=quarantine/reject 时才显示经过验证的品牌徽标),并在 Google 和 Yahoo 的大量发送者规则于 February 2024 生效后成为一项实际的强制要求:向 Gmail 每天发送 ~5,000 封及以上邮件的发送方必须通过对齐的 SPF 或 DKIM、至少发布 p=none,并提供一键退订 (one-click unsubscribe)。2026 年发布的 DMARCbis 修订版废除了 RFC 7489,在保持 v=DMARC1 记录继续有效的同时,用 DNS "Tree Walk" 取代了 Public Suffix List 查询来确定组织域名。

flowchart TD
  A[入站邮件] --> B{SPF 通过?}
  A --> C{DKIM 通过?}
  B --> D{From 与 SPF<br/>域名对齐?}
  C --> E{From 与 DKIM<br/>域名对齐?}
  D --> F{任一检查<br/>通过且对齐?}
  E --> F
  F -->|是| G[DMARC 通过 - 投递]
  F -->|否| H[应用 p= 策略]
  H --> I[none: 监控]
  H --> J[quarantine: 垃圾邮件文件夹]
  H --> K[reject: 退回]
  G & H --> L[向域名所有者发送 rua 聚合报告]