DMARC正式成为IETF标准：RFC 9989–9991发布，DMARCbis落地

三份文档：从信息类到标准轨道

DMARC（基于域的消息认证、报告与一致性）自 2015 年 RFC 7489 起为"信息类（Informational）"独立提交。历经约 7 年（2018 年 ARC 定稿后加速），IETF DMARC 工作组于 2026-05-20 由 RFC Editor 发布三份新文档：RFC 9989（核心协议）、RFC 9990（聚合报告）、RFC 9991（失败报告），将协议正式推上标准轨道。记录仍从 v=DMARC1 起始，非破坏性变更，没有"DMARC2"——既有 DMARC 记录无需重写。

关键变更：弃用与新增标签

相较 RFC 7489，主要变化：弃用 pct=（采样百分比）、rf=（报告格式）、ri=（报告间隔）；新增 np=（不存在子域策略）、psd=（来自 RFC 9091，已废止）、t=（测试模式）；报告尺寸限制标注从 rua= 移除；DMARC 的 SPF 检查仅用 MAIL FROM，不再回退到 HELO 标识。这些改动解决了首版部署中发现的若干歧义。

组织域判定：Public Suffix List → DNS Tree Walk

在确定组织域（用于 DMARC 记录发现与标识对齐）时，原 Public Suffix List（PSL）机制被更灵活也更复杂的 DNS Tree Walk 算法取代，并更好地支持公共后缀域（PSD）——此前 PSD 无法完整参与 DMARC。转发与邮件列表破坏对齐的"间接邮件流"问题仍未彻底解决：RFC 9989 现建议在可能存在邮件列表收件人时谨慎使用 reject 策略。

报告与隐私

聚合报告（RUA）格式收紧并更新以纳入新标签、反映真实实践；失败报告（RUF）同步小改，并新增专门章节说明隐私影响（PII/NPI 风险）。整体文档结构更清晰，定义更明确，并新增"完整参与 DMARC 的一致性要求"一节，帮助域主与接收方判断是否符合最佳实践。

运维建议

对邮件系统运营者：核心策略不变——保持 v=DMARC1，组织域与子域均设 quarantine/reject；逐步采用 np= 覆盖未使用子域、psd= 支持公共后缀域；在邮件列表场景避免盲目 reject；并持续消费 RUA 报告以发现遗忘的 SaaS 与仿冒尝试。国产/信创邮件系统实现 DMARC 校验时，应直接对齐 RFC 9989 而非旧版。