[ 诊断和资源 ]

邮件认证标准及源码库

精心策划的主要源库将协议规则、参数注册、提供者义务和观察到的实现分开。每个条目都标识了其来源可以回答的问题。

由EmailAuth研究团队提供 · 6 分钟阅读

[ 要点 ]

  • RFC 9989涵盖当前核心DMARC ; RFC 9990 和 9991 涵盖不同的报告类型。
  • 将DKIM算法更新与基本签名规范一起使用。
  • IANA活跃状态和历史状态并不是产品兼容性证书。
  • 发布日期、提供商执行日期和当地接受日期是不同的记录。
在此页面上

从权威和问题开始

电子邮件身份验证库应该帮助读者选择正确的主要文档,而不仅仅是收集链接。协议规则、参数注册表、提供商要求和产品观察回答了不同的问题。本策划指南记录了 2026 年 11 月 8 日审查的关键来源的范围和状态。其条目拥有稳定的读者锚定;他们没有确定租户、接收者或EmailAuth实现是否符合这些来源。

对于每项操作要求,保留发布机构、文件标识符、版本或修订日期、受影响人群、责任所有者和验收证据。发布日期并不自动成为提供商执行日期。工作库还需要维护:更改的链接、新的更新和未解决的源冲突必须可见,而不是隐藏在旧的已审核徽章后面。

DMARC核心RFC 9989

RFC 9989 是2026年5月的核心 DMARC 规范,涵盖经过身份验证的标识符, 结盟、策略发现和评估策略语义。它是 RFC编辑信息记录 将其标识为拟议标准;该文档是标准跟踪并废弃了 RFC 7489 和 9091。将其用于当前核心规则,同时单独测试遗留实现差异。策略版本仍然是DMARC1 ,而不是根据新 RFC 编号发明的版本。

汇总报告RFC 9990

RFC 9990 是单独的 2026 年 5 月汇总报告规范。这 RFC编辑记录 确定拟议标准的状态。它解决了报告结构、处理、外部目的地、重复和隐私/安全考虑因素。它应该支持报告解析器的接受情况,而不是被视为每个接收者发送完整报告或仪表板总计正确的证据。

失败报告RFC 9991

RFC 9991 是 2026 年 5 月的标准跟踪故障报告规范,更新了RFC 6591并与其他两个文档一起参与替换 RFC 7489。其重点是特定于消息的诊断、报告格式、外部目的地和隐私。在此审查期间,单独的信息页面阅读受到速率限制;成功读取的 RFC 文本支持指定类别。不要混淆 故障报告 汇总统计数据或假设发布 ruf 可以保证报告。

SPF RFC 7208

RFC 7208,于 2014 年 4 月在标准轨道上发布,定义 SPF 身份、策略记录选择、评估和结果处理。这是解释一个问题的主要出发点 permerror 或 DNS 查询期限限制。阅读相关部分及其依赖项,而不是将SPF减少为允许的 IP 地址列表或假设每个DNS操作都相同。

DKIM RFC 6376和算法更新

RFC 6376,于 2011 年 9 月在标准轨道上发布,定义 DKIM 签名、选择器、密钥和验证。阅读其加密条款 RFC 8301,2018 年 1 月,以及 RFC 8463,2018 年 9 月。前者禁止 RSA-SHA1,并强化 RSA 密钥要求;后者定义 埃德25519 使用。较旧的基础文档仍然有用,无需将每个原始算法推荐都变为最新。

SMTP DNS和显式无邮件

RFC 5321,2008 年 10 月,提供SMTP传输和目标解析规则。 RFC 1034 和 RFC 1035,1987 年 11 月,提供基本的DNS概念和记录结构。使用 RFC 2308,1998 年 3 月,用于否定答案的区别,而不是过时的否定缓存快捷方式。这些参考文献是以后更新的起点,而不是完整的现代DNS实现规范。

RFC 7505,2015 年 6 月,为明确不接受邮件的域定义了 null MX 。其发件人指南警告不要使用 null-MX 域 邮件来自 或从身份可见:接收者可以拒绝该流量。使发件人指导与SPF和SMTP的空反向路径区分开来。故意无邮件记录并不是MX丢失或故障。

认证结果来源RFC 8601

RFC 8601,2019 年 5 月,定义了 Authentication-Results标头 及其信任考虑因素。在评估谁做出了身份验证断言以及该断言是否属于接收系统的可信边界内时使用它。它不会将从消息复制的任意标头转换为经过身份验证的证据,也不会从传递令牌建立收件箱放置。

IANA参数注册表

这 DMARC参数注册表,在检索到的记录中于 2026 年 5 月 22 日更新,将标签连接到引用以及活动或历史状态。它标记了 pct、rf 和 ri 历史记录,并包括 np、psd 和 t 等活动标签。这 DKIM参数注册表 识别已注册的签名标签和相关定义。注册是词汇参考,并不能证明部署正确支持参数。

状态和实施是单独的证据

互联网草案是一份工作文档,而不是仅仅因为它与 RFC 相似而发布的 RFC。 RFC 2026第 2.2 节 解释这种区别;后来的流程更新意味着其历史标准阶梯不应被视为完整的当前流程。还将标准跟踪与信息性、实验性和当前最佳实践文档区分开来。引用实际状态记录,而不是假设每个编号的 RFC 都具有相同的权限。

对于提供商规则,分别记录产品、路线、云环境、受影响的发件人、公告和执行日期。官方页面之间的冲突属于要求登记册,直到适用的当前来源或受控观察解决它。综合解析器结果可以测试本地解释,但不能证明远程采用。

确切的目录要求仍然开放:要求登记,包括权限、范围、生效日期、所有者和验收证据。下面的策划图提供了源条目和提议的所有权,但未完成组织特定的验收。摄入还要求工作功能和测试。静态锚点和主链接已交付,但功能工具的接受度、适用性、技术审查和出版批准仍然悬而未决。

[ 外卖 ]

将文件的权限、状态和范围与要求相匹配,然后单独收集实施证据。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

方案审核员

选择正确的索赔机构

基础 RFC、算法更新和注册表服务于相关但不同的目的。

后续步骤

  1. 记录文档标识符、状态、日期和相关部分。
  2. 在应用旧指南之前,请阅读更新和过时的关系。
  3. 将核心政策和每个报告规范分开。

运营负责人

将来源转化为适用的要求

仅当其范围适合实际路线和实施时,已发布的规则才成为可操作的声明。

后续步骤

  1. 识别受影响的产品、云、发件人和收件人。
  2. 指定所有者并定义可观察的验收条件。
  3. 保留官方来源的分歧和缺失的实施证据。

库维护者

随着时间的推移保留有用的参考

参考资源需要稳定的导航和可见的维护历史记录。

后续步骤

  1. 当标题或解释性文本发生变化时,保留条目锚点。
  2. 在定义的触发器上查看注册表状态和源修订。
  3. 报告无法访问的来源,而不将部分读取视为完整审查。

[ 常见问题解答 ]

常见问题

当前哪个文档定义了DMARC政策和一致性?

RFC 9989 ,于 2026 年 5 月发布。其 RFC 编辑器记录标识了提议标准状态,并且它废弃了 RFC 7489 和 9091。这并不能证明特定接收器已采用它。

为什么汇总报告和故障报告分开列出?

RFC 9990定义了汇总报告; RFC 9991定义了消息特定的故障报告并更新了RFC 6591 。它们的格式、证据和隐私影响各不相同。

新的DMARC RFC 是否意味着DNS版本变为 DMARC2?

否。当前策略语法保留DMARC1 。文档编号不是策略版本标签的值。

原始DKIM算法文本可以单独使用吗?

否。请阅读RFC 6376及其适用的更新,包括RFC 8301和RFC 8463 。他们更改或扩展加密要求,而不是替换基本规范的每个部分。

IANA主动标签建立了什么?

它标识注册的当前参数及其在该注册表中的引用。它并不证明产品接受它或实现所有相关的语义。

互联网草案与已发布的标准相同吗?

不,这是一份工作文件。在将其文本视为当前发布的协议要求之前,请检查发布和状态记录。

应如何记录冲突的提供商页面?

保留每个来源、修订日期、受影响的服务和冲突。需要适用的当前澄清或受控证据,而不是仅仅因为一页看起来较新而选择数字。

这个库完成调试注册了吗?

不会。它提供实质性来源条目和建议的所有者角色。组织特定的所有者、生效日期的适用性、验收证据和单独的工作功能摄入仍然开放。

[ 来源 ]

来源

  1. IANA DKIM参数注册表
  2. IANA DMARC参数注册表
  3. RFC 1034 :域名概念和设施
  4. RFC 1035 :域名实施和规范
  5. RFC 2026 :互联网标准流程修订版 3
  6. RFC 2308 : DNS查询的负缓存
  7. RFC 5321 :简单邮件传输协议
  8. RFC 6376 :域名密钥识别邮件签名
  9. RFC 7208 :发件人策略框架
  10. RFC 7505 :空MX无服务资源记录
  11. RFC 8301 : DKIM的加密算法和密钥用法更新
  12. RFC 8463 : DKIM的新加密签名方法
  13. RFC 8601 :用于指示消息认证状态的消息头字段
  14. RFC 9989 :基于域的消息身份验证报告和一致性
  15. RFC 9989的 RFC 编辑信息记录
  16. RFC 9990 : DMARC聚合报告
  17. RFC 9990的 RFC 编辑信息记录
  18. RFC 9991 : DMARC故障报告

[ 词汇表 ]

词汇表

标准轨道
互联网标准路径规范的文档类别;准确的成熟状态应单独检查。
拟议标准
检索到的 RFC 9989 和 9990 的 RFC 编辑器记录中显示的具体状态;它不是互联网草案。
互联网草案
一份工作IETF文档,不得仅仅因为其格式与 RFC 相似而将其视为已发布的 RFC。
更新关系
一种文档关系,表明另一个 RFC 的指定条款已更改或扩展,需要将它们一起阅读。
验收证据
可重复的观察或测试,证明满足适用的当地要求,与规定的来源分开。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库