新标准不等于立即重做配置
RFC 9989 于 2026 年 5 月发布，取代此前的 DMARC 规范，其中一项变化是删除百分比参数 pct。
企业首先应核对现状：DNS 中发布了什么策略，操作文档依赖哪些假设，谁有权批准修改？标准的发布日期不能证明某家邮件服务商已经采用了哪个版本。应向服务商确认实际使用的系统，再决定是否调整正常工作的记录。 [1]
主邮箱只是发信渠道之一
除了日常邮箱，还应登记网站表单、开票软件、客服平台和邮件订阅服务。每条渠道都需要负责人、显示的发件地址、发信服务和已检查的样本邮件。网页版邮箱的一次成功发信，不能证明网站的发信流程也正常。
检查问题应具体，例如：开票平台能否使用指定发件域名发送发票，收到的原始邮件能否证明这一点？保留相关邮件头及检查时间。凭据和邮件正文不应放入广泛共享的 DNS 清单。
当 SPF 或 DKIM 至少有一项认证通过，且其域名按所选对齐模式与可见的 From 域名对齐时，DMARC 即可通过。 [1]
发信渠道
记录邮箱、网站、CRM 或开票服务及其负责人。
认证结果
检查实际收到的邮件中的 SPF 和 DKIM 结果。
域名对齐
将通过认证的域名与可见的 From 域名比较。
每条渠道都有证据
记录结果、时间和需要调整的项目。域名获得授权，并不等于邮件内容可信。
示意性检查流程。分别查看认证机制，并核对它们与收件人看到的 From 域名的关系。
重新核对旧的分阶段启用方案
特别检查仅依赖 pct=10 或 pct=25 逐步启用策略的旧操作指南。旧规范曾包含这个机制，但历史指南不能证明今天所有收件系统的行为。
每次修改应明确涉及哪些发信渠道、谁负责，以及验证失败后恢复哪个配置。向相关服务商确认支持情况。为了完成这项检查，无须预先降低已经有运行证据的严格策略。 [5]
左右滑动可查看完整表格。
| 检查范围 | 需要的证据 | 决定 |
|---|---|---|
| 发信清单 | 每个获授权的发信服务均有负责人。 | 先查清未知来源。 |
| 策略 | 记录当前 DNS 值和回退值。 | 批准可追溯的修改。 |
| 兼容性 | 服务商确认具体环境的行为。 | 不假定所有收件方均已更新。 |
| 验收 | 分别验证约定的发信渠道。 | 通过后再调整下一组渠道。 |
将报告转化为明确的工作
DMARC 汇总报告描述观察到的发信来源和认证结果。失败报告是另一种报告，可能包含更多邮件相关数据。
我们的建议是为每条异常渠道明确后续工作：它是否属于获授权的服务，由谁调查，何时再次检查？未知记录首先是待核实的问题。没有异常的报告同样不能替代企业自己的发信清单。还应规定谁可以读取报告文件，以及何时删除。 [2] [3]
单独核对服务商要求
Gmail 区分一般发件方和批量发件方。Google 要求后者配置 SPF、DKIM 和 DMARC；满足该项要求时，DMARC 策略可以设为 none。
这一最低要求并不决定您的域名应采用何种保护策略。因此，应分别记录两个目标：满足收件服务商要求，以及建立可靠的授权发信清单。实际送达情况和垃圾邮件分类需要另行观察。 [4]
从一个重要渠道开始
先选择报价或发票等对业务重要的渠道。使用下列清单形成可验证的修改任务，避免一次调整整个邮件系统。
- 保存当前 DMARC 记录和操作指南。
- 列出仍在使用的发信服务及负责人。
- 逐条检查经授权发送的测试邮件。
- 核实旧百分比启用方案及服务商支持情况。
- 约定修改时段、验收标准和回退流程。
- 修改后结合报告与实际送达情况进行复查。