摘要

  • DMARC pass 只说明 Author Domain 的使用通过了授权验证，并不证明邮件真实、安全、善意或值得投递。
  • p=reject 表达域名所有者的偏好；RFC 9989 把最终处置留给接收方，并要求偏离偏好时保留可解释的原因。

同一时刻，接收边界可能看到两封方向相反的邮件。一封完成 SPF 或 DKIM 对齐，却携带本地滥用系统已经识别的危险内容；另一封因为邮件列表或转发链改变了路径而 DMARC fail，但其托管关系和历史足以支持投递。把 pass 翻译成“安全”、把 fail 翻译成“欺诈”，两封都会判断错。

2026 年 5 月发布的 RFC 9989 是 IETF Standards Track 文档，并取代 RFC 7489 与 9091。它的发布记录、Datatracker 历史和勘误页面界定规范身份，不证明任何系统已经正确执行。

DMARC 先继承两个较窄的技术结果。SPF把 SMTP 来源与 SPF 身份的发送授权联系起来；DKIM验证签名域及其密钥。RFC 9989 再检查至少一个 Authenticated Identifier 是否与读者所见 RFC5322.From 中的 Author Domain 严格一致，或属于同一 Organizational Domain。存在对齐的通过结果，DMARC 才 pass；没有对齐身份，则 fail。

这个结果只回答“该域名的使用是否获授权”。规范明确否认它对邮件或域名所有者作任何价值断言。pass 的邮件仍可被接收方隔离或拒绝；fail 也不等于伪造。RFC 7960列出的邮件列表、别名和转发正会使合法邮件失去认证或对齐。

DNS Policy Record 是第三个对象。IANA DMARC 参数注册表记录协议词汇。none 不提出处置偏好，quarantine 表示怀疑，reject 表达最强烈的无效判断。Domain Owner 最了解自己计划中的发信方式，因此这项意见很有价值；但它不运营收件系统，不服务收件人，也看不到接收方掌握的全部信誉、滥用和用户证据。

所以 RFC 9989 第 5.3.6 和 5.4 节把执行权留在本地。DMARC fail 的邮件按接收方本地策略处理，公布偏好只是接收方可以酌情考虑的输入。规范甚至不建议仅因 p=reject 就拒收，因为合法间接邮件与邮件列表可能受损。反过来，接纳 fail 也可能放进真正的滥用。没有一个远端 DNS 值能替承担后果的一方消除这组权衡。

DNS 查询失败也不能偷换成 DMARC fail。若必要查询遭遇临时或永久错误，邮件既不能判 pass，也不能判 fail，Domain Owner Assessment Policy 不能应用。接收方仍要在延迟、接受或其他处置之间选择，并记录自己面对的是未知状态。

偏离并不等于无规则。RFC 9990的 PolicyOverride 可以把偏离事实和原因反馈给 Domain Owner；投递 fail 邮件时，RFC 8601所定义的 Authentication-Results 保留认证结果。RFC 9991则处理可选的详细失败报告。报告、披露与处置是三种不同权力。

完整记录链应包括 SPF 与各 DKIM 结果、Authenticated Identifier、对齐模式、Author Domain、Policy Domain、DNS 答案及 TTL、所用策略值、本地风险证据、override 原因、SMTP 动作与后续用户反馈。它们的主人和时钟都不同。

Heng Lu 关于最小初始规范的论述说明，共享信号可以协调行动，却不必集中未来决定；现实层提醒人们不要把符号状态当成执行权；运行代码优先则要求追问接收方究竟应用、覆盖，还是根本未取到该策略。

准确的状态不是“DMARC 已决定”，而是：这些认证证据产生了这个对齐结果；域名表达了这个偏好；接收方基于这些本地理由作出了这项处置。