外贸站和企业邮箱用户常常遇到两个困扰：客户说收到了”你发的”奇怪邮件，但你们根本没发过；或者自己发的开发信、订单确认频繁进了对方垃圾箱甚至被退回。这两个问题往往指向同一个根源——域名的邮件认证配置出了状况，而 DMARC 报告正是帮你定位问题的关键证据。本文教你如何看懂 DMARC 聚合报告（Aggregate Report），从报告字段入手排查域名邮件被冒用与退信，并把策略逐步收紧到 reject，帮助你在不动业务邮件的前提下把冒用风险降下来。
先搞清楚：DMARC 和 SPF、DKIM 是什么关系
要看懂报告，得先弄清三个认证机制各自管什么。SPF（发件人策略框架）声明”哪些服务器有权替我的域名发信”；DKIM（域名密钥识别邮件）给每封信盖一个加密签名章，证明内容在途中没被篡改；DMARC（基于域名的邮件认证报告与一致性行协议）则站在两者之上做两件事：核对发件域名是否与 SPF/DKIM 的通过结果”对得上”（也就是 alignment），以及把每天的验证结果汇总成报告寄回给你。
这三条记录都以 TXT 形式存放在 DNS（域名解析系统）里。你可以在本机直接查询确认是否已配置：
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT default._domainkey.example.com +short
一个典型的 DMARC 记录长这样：
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100
其中 p 是未通过验证时收件方的处理动作，rua 是聚合报告的接收邮箱。三者关系可以参考下面这张结构图：
聚合报告长什么样：XML 结构与关键字段
DMARC 聚合报告通常每天从 Gmail、Outlook 等大型邮箱服务商寄到你的 rua 邮箱，格式是 ZIP 压缩的 XML 文件。打开后主要看三层结构：
<record>：每一条代表”某个来源 IP 以你的域名发了一批信”，source_ip是发信服务器地址，count是这批信的数量<policy_evaluated>：认证判定结果，disposition的取值 none 表示放进了收件箱、quarantine 表示进了隔离区（垃圾箱）、reject 表示直接拒收<auth_results>：SPF 与 DKIM 各自的验证结果，dkim的result=pass且domain与你的域名一致，才构成 DMARC 通过
一个精简后的报告片段如下：
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>320</count>
</row>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>
手动读 XML 很快就会疲劳，实际操作中更推荐用可视化面板聚合多天的数据。主流方案包括 Postmark 的免费 DMARC 工具、dmarcian、EasyDMARC 等，把报告邮箱指向它们后，会自动把 source IP 归属、认证通过率、趋势变化整理成图表，排查效率比翻邮件高很多。
用报告排查邮件被冒用：三步定位伪造来源
域名被冒用最典型的信号是：报告里出现陌生来源 IP，发信量大，而且 SPF 和 DKIM 全部失败。因为伪造者无法拿到你的域名私钥，也控制不了你的 SPF 记录，这些邮件的认证结果几乎必然不通过。排查可以按三步走。如果你用的是 VPS 主机（虚拟专用服务器）自建邮局，还要顺手检查这台服务器有没有被植入发信脚本——被入侵的 VPS 常常正是冒用来源之一。
第一步，筛选出 dkim=fail 且 spf=fail 的记录，按 source_ip 汇总数量。把可疑 IP 拿去查询归属（whois 或 IP 库），判断它是营销群发平台、被入侵的服务器，还是完全无关的扫描流量。
第二步，区分”合法第三方”与”真冒用”。企业常常忘了自己授权过的服务也在替域名发信，比如客服工单系统、CRM 群发平台、GitHub 的通知邮件。这些服务用自己服务器的 IP 发信，如果你的 SPF 里没有它们，也会显示失败。判断依据是：来源 IP 是否属于你认识的服务商、发信频率是否稳定、内容主题是否正常。每一台替你发信的服务器都应登记在案，下图示意了这个核对关系：
第三步，确认冒用后逐步收紧策略。如果当前是 p=none，冒用邮件仍在正常投递；先把 SPF/DKIM 都通过的记录比例核对清楚（通常连续一周以上合法流量认证通过率超过 98%），再把策略升到 p=quarantine 观察两周，确认没有误伤后升到 p=reject。跳过观察直接上 reject，很容易把自己客户的正常回信一起拒掉。
用报告排查退信：对齐失败才是隐藏原因
很多退信并不是内容问题，而是 DMARC 对齐失败导致的拒收。典型场景是：SPF 本身通过了，但 DMARC 仍然判失败。原因是 SPF 验证的是”信封发件人”（Return-Path），而 DMARC 核对的是邮件头里用户看到的 From 域名。当客服系统替你发信、From 写你的域名、Return-Path 却写服务商的域名时，SPF 过了、DMARC 却对不上，收件方按 p=quarantine 或 p=reject 处理，表现出来就是”对方说没收到”或退信通知。
排查退信时在报告里重点核对三种组合， 服务器配置类问题多数都能在这个环节定位到：
| SPF | DKIM | DMARC 判定 | 常见原因 |
|---|---|---|---|
| pass | fail | 可能失败 | Return-Path 域名与 From 域名不一致，缺少 DKIM 签名 |
| fail | pass | 可能失败 | 发信 IP 不在 SPF 记录里，但 DKIM 已对齐时仍可通过 |
| fail | fail | 失败 | 未授权来源发信，冒用或漏配的第三方服务 |
如果发现某个一直合作的第三方平台长期 spf=fail，解决办法不是放宽策略，而是让对方提供自己的 DKIM 公钥并加进你的 DNS（用 adkim=s 严格对齐时尤其重要），或者在 SPF 的 include: 里补上服务商声明。每补一条记录后等一天，看第二天报告里该来源的通过率是否回升，退信是否随之减少。企业邮箱的稳定性也直接影响这一环节——如果发信服务器本身频繁切换出口 IP，SPF 会不断失效，这类场景可以参考虚拟主机与企业邮局方案由服务商固定发信出口的做法。
日常监控节奏：每周 15 分钟的检查清单
DMARC 报告的价值在于持续观察，而不是配完就不管。我们建议的做法是每周固定时间花 15 分钟过一遍聚合数据：
- 合法流量认证通过率是否保持在 98% 以上，下滑先查 SPF/DKIM 记录是否被人改动
- 是否新增了陌生的失败来源 IP，数量是否持续增长
disposition=reject/quarantine的比例是否异常升高，升高常伴随你的邮件被误判- 第三方服务商（工单、CRM、营销平台）的通过率有没有突然掉到零，掉零多为对方改了发信架构
DMARC 记录属于 DNS 层面的一次性配置，但发信链路的服务器稳定性同样影响通过率。关于主机选择与网站性能的讨论中我们提过，网络出口质量不只影响页面加载，也会左右邮件投递体验。观察通过率时，把至少 7 天的数据放在一张趋势图里看更稳，下面是认证通过与失败流量占比的示意：
从 5 万发信量案例看报告排查全流程
举一个贴近实际的例子。某外贸公司月发信量约 5 万封，客户反馈订单确认频繁进垃圾箱。聚合报告跑了一周后发现三个事实：自建邮件服务器 IP 的 DKIM 全部失败，占比 62%；一家客服工单平台的 IP SPF 失败但 DKIM 通过，占比 8%；剩下 30% 来自 Google Workspace，全部通过。
定位结果：自建服务器的 DKIM 密钥在半年前迁移机房时换了配置，default._domainkey 记录还是旧公钥，签名验不过；工单平台用的 Return-Path 是服务商域名，aspf=r 宽松对齐下 SPF 虽然不算对齐，但 DKIM 补上了缺口。修复动作分三步：先在 DNS 里更新 DKIM 公钥，第二天报告里自建 IP 的 DKIM 通过率从 0 回到 100%；再让工单平台接入他们提供的域名专属 DKIM；最后把策略从 p=none 升到 p=quarantine，两周后升到 p=reject。整个过程没有动邮件内容，垃圾箱问题消失，冒用邮件也开始被 Gmail 直接拒收。
这个案例说明的路径对所有域名都通用：先用报告把流量切成”谁在发、认证过不过”，再按比例从最大的失败源开始修，最后才动策略。如果你用的是虚拟主机或 VPS 自建邮局，排查 DNS 记录前先确认主机商是否提供 DKIM 配置入口，像 Hostease 的虚拟主机面板内置了 SPF/DKIM 记录生成功能，比手工拼接 TXT 记录更不容易出错。
总结：把报告变成邮件安全的例行体检
总结整套方法：DMARC 聚合报告是域名邮件安全的体检单，冒用排查看”陌生来源 + 双认证失败”，退信排查看”对齐失败 + disposition”，策略收紧必须建立在连续观察合法流量通过率的基础上。如果你刚开始配 DMARC，建议从 p=none、rua 指向可聚合分析的平台起步，每周核对一次报告；等连续两周合法流量通过率稳定在 98% 以上，再按 quarantine → reject 的节奏推进。把这套检查纳入每周运维例行动作后，域名邮件被冒用的风险和莫名退信都会被提前拦截在报告里，而不是等客户来投诉才发现。