先弄清谁在用这个域名发信
假设一家企业的财务同事收到客户转来的邮件：有人以公司域名的地址发出“更换收款账户”的通知。管理员登录 DNS 后发现，域名早年配置过一条 SPF 记录，但没有 DMARC，也说不清营销平台、工单系统、招聘系统和海外子公司各自用什么方式发信。此时最容易犯的错误，是马上发布一条拒收策略，结果第二天发票邮件和工单通知大量进入客户的垃圾箱，业务部门要求立刻撤回，治理就此搁置。真正的第一步不是改策略，而是把以本域名对外发信的所有系统找出来。
2026 年 5 月发布的 RFC 9989 是当前的 DMARC 核心规范，取代了 2015 年的 RFC 7489，记录版本仍写作 v=DMARC1。DMARC 让域名所有者声明，对未通过 SPF 或 DKIM 对齐检查的邮件，接收方可以不做处理、隔离或拒收，并可以把聚合报告发回给域名所有者。NIST 的可信电子邮件指南同样建议部署 SPF、DKIM 和 DMARC。依据这些机制，JOTOglobal 建议由邮件管理员牵头，与采购、市场、人事和各区域 IT 一起列出发信来源清单，写明系统名称、业务负责人、发信域名或子域名、是否由第三方代发，以及目前是否已签署 DKIM。清单中无人认领的来源要单独标注，留待报告核实。
用监测模式读懂聚合报告
清单初步完成后，管理员先发布策略为 none 的 DMARC 记录，并指定一个专用邮箱或报告处理平台接收聚合报告。这个阶段不会改变邮件投递结果，目的是观察各接收方看到的真实情况。RFC 9990 规定了聚合报告的格式，报告会按发信 IP 汇总邮件数量以及 SPF、DKIM 的检查和对齐结果。管理员每周把报告中的来源与清单逐项对照：清单里有、报告里也有且已对齐的，标为通过；报告里出现但清单里没有的，交给安全团队判断是遗漏的业务系统还是冒用者；清单里有但始终未对齐的，交由对应业务负责人整改。报告可能包含收件方和转发路径信息，接收邮箱的访问权限应限定在邮件和安全团队之内，并约定保留期限。
整改通常集中在三类问题。第一类是第三方平台用自己的域名签署 DKIM，需要在平台中配置使用企业域名或专用子域名签名。第二类是 SPF 记录不断叠加 include，查询次数接近协议限制，应清理已停用的服务，必要时把营销等大批量发信迁到独立子域名。第三类是转发和邮件列表会改变邮件路径，可能导致 SPF 失败，此时 DKIM 签名能否保持完整就更关键。每项整改都在清单中记录完成日期和验证方式，例如由业务负责人发一封测试邮件，再从报告或收件方的认证结果头中确认已对齐。
分阶段收紧策略并设置回退
当报告中已知来源全部稳定对齐，并且连续几个报告周期没有出现新的合法来源后，再把策略从 none 调整为 quarantine。RFC 9989 已不再把 pct 作为当前机制的一部分，因此企业不宜依赖“只对一部分邮件执行”的方式过渡，更稳妥的做法是先对影响较小的子域名执行，或先收紧用于营销的独立子域名，再处理主域名。每次调整前，由邮件管理员写明变更内容、观察期、负责接收业务投诉的联系人，以及出现大面积误判时退回上一阶段的条件和操作人。
在隔离阶段，业务负责人重点检查发票、合同、密码重置和客户通知等关键邮件是否仍能到达收件箱，客服团队记录客户反馈的异常。确认没有合法邮件受影响后，再评估是否进入 reject 阶段。对于从不发信的子域名，RFC 9989 提供了针对不存在子域名的 np 标签，可以考虑为这类子域名声明更严格的策略，减少被冒用的空间。所有阶段的 DNS 变更记录、报告摘要和业务确认应保存在变更单中，便于日后有人质疑为什么某封邮件被拒收时，能够追溯当时的依据。
验收证据、误区与适用边界
验收时，建议保存四类证据：当前公开的 SPF、DKIM 选择器和 DMARC 记录查询结果；最近一个周期的聚合报告摘要，显示合法来源全部对齐；关键业务系统的测试邮件及其认证结果头；以及业务负责人对清单中各自系统的签收。常见误区包括：认为发布 DMARC 记录就能阻止所有钓鱼邮件，实际上它只针对冒用本域名的情况，对相似域名和外部账号冒充并无直接作用；认为设为 reject 后就可以不再看报告，实际上新系统上线或供应商更换都可能产生新的未对齐来源。因此建议把发信来源清单纳入新系统上线和供应商变更的检查项，由采购或项目负责人在启用前通知邮件管理员。
本文的盘点、分阶段收紧和验收流程是 JOTOglobal 提出的组织建议，阶段时长、观察指标和是否最终进入拒收，应由企业根据自身邮件量和业务风险确定。不同接收方对 DMARC 策略的执行方式可能不同，聚合报告也可能存在延迟或缺失，因此报告只能作为判断依据之一。若企业邮件由外包服务商运营，应在合同或工单中明确记录修改 DNS 的授权人和回退责任，涉及受监管通信的行业还需遵循所在行业的留存与通知要求。