摘要

  • RFC 9989 规定：只要至少一个通过 SPF 或 DKIM 验证的域名与 RFC5322.From 中的作者域名对齐，DMARC 就可得到 pass。它证明域名使用获授权，不验证邮箱地址本地部分、显示名、具体自然人或邮件内容。
  • fail 也不是相反方向的定罪。转发器、邮件列表等合法中间环节可能破坏 SPF 对齐或 DKIM 签名，使合法邮件在最终接收方失去原有证据。
  • DNS 中的 p、sp、np 是域名所有者提出的处理偏好。接收方仍以本地政策决定接收、隔离、拒绝或延迟；它可以拒绝一封通过的邮件，也可以接收一封失败的邮件。

先给绿色标记划边界

2026年5月发布的 RFC 9989 是 Internet Standards Track 文档，取代 RFC 7489 与 RFC 9091。Todd M. Herr 与 John Levine 共同担任编辑。它在开篇就阻止了一种常见的语义膨胀：DMARC 通过，只表明作者域名在这封邮件中的使用已被验证为得到该域名所有者授权；这种授权不对邮件或域名所有者作任何明示或默示的价值判断，也不保证把邮件送进收件箱是安全或合意的。

这不是附在协议末尾的免责条款，而是结果本身的对象定义。系统若把 pass 显示成“可信发件人”或“安全邮件”，就不是在简化 RFC，而是在增写 RFC 没有提供的证明。

邮件看起来是一个对象，实际却叠着多种身份。SMTP 会话有 MAIL FROM，DKIM 签名有 d= 域名，读者看到的 RFC5322.From 又有地址和显示名。DMARC 只把其中一条关系固定下来，其他关系仍要各自留存证据。

SPF、DKIM 与作者域名之间差的那一步

SPF 检查连接进来的主机是否获准使用某个 SMTP MAIL FROM 或 HELO 域名；DMARC 采用前者。DKIM 检查签名覆盖的邮件部分有没有被改变，并确认签名域名。两种机制都可独立得到有效结果，却未必与读者看到的 From 域名有关。攻击者完全可以正确配置自己的 SPF，也可以用自己的域名正确签名。

DMARC 增加的是“对齐”。接收方从 RFC5322.From 提取作者域名，再把它同已经验证的 SPF 或 DKIM 域名比较。严格模式要求两个域名完全相同；宽松模式要求它们属于同一组织域。域名所有者通过 aspf 与 adkim 选择模式，RFC 9989 还指出，实践中几乎所有域名所有者都认为宽松模式足够。

任一经过验证且对齐的标识符就能带来 pass。一封邮件可以有多个 DKIM 签名，其中一个有效并对齐即可；另一个失败并不会自动推翻前者。SPF 通过也不能跳过对齐：若通过的是转发器自己的域名，而 From 仍是原作者域名，DMARC 仍可能失败。

因此，精确回执应该写成：某接收方在某时刻观察到某个通过 SPF 或 DKIM 验证的域名，并按指定模式确认它与作者域名对齐。它没有说“这个人写了邮件”。

地址左边的人、屏幕上的名字与正文仍未验证

当一个地址把本地部分 finance 与域名 example.com 组合起来时，DMARC 只处理 example.com，不验证 finance。它不能证明这个邮箱存在、由财务部门控制，或邮件确由某位财务人员操作。显示名更是另一层：界面可以写真实高管姓名，背后的地址却属于完全不同的域名。

视觉近似域名也不在 DMARC 的直接能力内。攻击者可以换一个相似字符、加上“secure”或“support”等词，再为这个新域名建立完整 SPF、DKIM 和 DMARC。RFC 9989 明确把显示名攻击与相似域名排除在外。

正文分析同样不属于该协议。获授权的营销平台可能被滥用，合法账户可能失陷，组织内部人员也可能发送恶意请求。链接、附件、付款账号、指令真实性和收件人是否适合执行，都需要内容检测、账户风险、业务流程与人工复核。DMARC 通过并不妨碍这些风险成立。

反过来说，这些事件也不应被错误标记为“DMARC 没工作”。协议可能准确识别了域名授权，真正失败的是账户控制、声誉更新、内容检测或业务批准。把证据对象分开，才能找到真正需要修复的控制面。

合法邮件为何会在终点失去对齐

RFC 7960 研究的正是间接邮件路径。转发器若保留原始 MAIL FROM，最终连接 IP 往往不在原域名 SPF 授权范围内；若改用转发器自己的 MAIL FROM，SPF 可以通过，但新域名又可能与原始 From 不对齐。

邮件列表还会加主题前缀、页脚，删除 MIME 部分或调整编码。这些操作对列表功能可能完全合理，却会改变 DKIM 覆盖的字节，使原签名失效。于是，一封出站时获授权并签名正确的邮件，到最终收件服务器时可能没有任何仍然有效且对齐的标识符。

RFC 9989 因此刻意说，失败邮件“并不一定与作者域名无关”。fail 描述的是最终检查点现有证据没有满足对齐条件，不是对整段历史的重建，也不是对作者动机的裁决。

自动化若忽略这一点，就会制造另一类安全事故：合法通知、邮件列表发帖或转发后的业务邮件被永久丢弃。绿色不能继承安全，红色也不能继承欺诈。

域名可以请求，不能遥控另一家的队列

DMARC 策略发现有明确顺序：先查询作者域名，再查询它的组织域，最后查询公共后缀域。记录所在位置、子域是否存在等条件，决定采用 p、sp 或 np。IANA 当前登记把这些标签描述为“requested”策略，即域名所有者提出的处理偏好。

偏好不是远程管理员权限。RFC 9989 把最终处理始终留给接收方本地政策。接收方发现其他恶意证据时，可以隔离或拒绝一封 pass 邮件；知道它来自可信转发路径时，也可以接收一封 fail 邮件，即使发布者写了 p=reject。文档进一步建议，不应仅因为 reject 就拒收，而应结合其他知识，避免误伤合法间接邮件和邮件列表。

DNS 故障把控制边界表现得最清楚。若必要查询因临时或永久错误无法完成，结果既不能算通过，也不能算失败，域名策略不能照常套用。接收方可以选择放行、暂缓或其他处理，并承担相应后果。

Heng Lu 在《The Policy Mirror》中提出一个范围检验：共同层只保留互操作需要的最低事实，不应借一个记录扩大到另一主体承担后果的决定。RFC 9989 的规范权威来自 IETF，但它在邮件层面展示了相同纪律——发布者能让请求可读，不能把接收者的控制杆搬进 DNS。

请求报告不等于拥有完整观察

域名所有者可用 rua 请求聚合报告，用 ruf 请求逐封失败信息。聚合数据不仅帮助发现冒用，也能暴露自身合法发件源配置不全、签名中断或对齐错误。不过，接收方没有义务发送全部请求的报告。RFC 9989 建议发送聚合报告；逐封报告是可选项，还常因隐私而被删减或不发。

所以，DNS 中存在报告地址，只证明有人提出请求。实际收到的一份报告，只证明某接收方在某时间段按其实现提供了某组观察。它不证明全球覆盖，不证明每封邮件都执行了发布策略，也不证明用户最终看到了什么。

从 none 提升到 quarantine 或 reject 前，应先盘点发件源、验证转发器与列表、观察真实报告覆盖，并准备回滚。没有这些回执，策略升级只是把不确定性写进 DNS，再把损失交给远端发现。

讲 Todd Herr，不把共同编辑写成协议主权

截至2026年9月1日的 IETF Datatracker 页面，在 Todd Herr 的公开身份下列出 RFC 9989，并显示他担任 ART Area Review Team reviewer。RFC 发布页把他列为 Valimail 的编辑，同时列出 Standcore LLC 的 John Levine。致谢部分又保存了 DMARC 工作组和更早行业协作的众多贡献。

这篇人物稿可以把 Herr 放在一个具体贡献上：他共同编辑的文档没有把认证结果写成夸大的安全承诺，而是反复标出接收方控制与结果范围。但不能把他写成 DMARC 唯一发明者、全球域名验证者、每家收件系统的决策者或全部部署的负责人。准确归因本身就是证据纪律。

一条不允许自动继承的邮件证据链

可审计记录至少应包含：收到的原始邮件与唯一 From；每个 SPF、DKIM 结果及其域名、selector、错误原因和时间；严格或宽松对齐及决定性标识符；策略发现查询路径与实际采用的标签；DNS 错误；已知中间转换；本地声誉与内容信号；最终接收、隔离、拒绝或延迟动作；用户随后是否举报或受损；实际发出和收到的报告。

这条链的价值在于禁止继承。域名授权不继承自然人身份，对齐不继承正文真实性，pass 不继承安全，远端偏好不继承本地执行，SMTP 接收不继承收件箱位置，进入收件箱也不继承无害结果。

保持边界不会削弱 DMARC。它仍能显著减少精确域名冒用，为声誉提供稳定对象，并让域名所有者观察发件流。真正削弱它的，是要求一个域名回执替人、内容和运营决定承担它从未拥有的证明责任。

来源