DMARC 报告分析器
把收件方发给你的聚合报告文件拖进来——.xml、.xml.gz，或装了多个报告的 .zip——就能看到 XML 埋藏的信息：哪些来源以你的域名发信、其中多少通过了 SPF 和 DKIM 对齐、哪些两者都失败了，以及先修什么，全都用通俗语言写明。一切解压和解析都在你的浏览器中完成；文件绝不会离开你的浏览器，因为一份 DMARC 报告就是一张地图，画着谁在替你发信——以及谁在冒充你。
或者把文件拖到这个框里的任何位置。不同收件方、不同日期的报告会合并成一张表，按来源分组。
已读取的报告
需要修复的问题
来源
| 来源 IP | 发件人域名 | 邮件数 | 处置方式 | SPF 对齐 | DKIM 对齐 | DMARC |
|---|
当某一行有任意一种对齐通过时，该行即通过 DMARC——这正是收件方采用的定义。两者都失败的行会被高亮显示。要检查记录本身、而不是它们生成的报告，请使用电子邮件送达能力检查。
聚合报告到底是什么
DMARC 有两半。第一半是你发布的记录——策略、对齐模式、报告地址——也是包括本站电子邮件送达能力检查在内的每个检查工具都能读到的那一半。第二半是反馈回路：每个看到声称来自你的域名的邮件的大型收件方，都会把所见情况汇总，并通常每天一次、以 XML 形式把汇总发到你的 rua 地址。那份文件是还有谁以你的名义发信的唯一证据。欺骗活动、同事两年前接入的营销平台、还在使用一台已停用服务器的监控服务——这一切都会先出现在聚合报告里，比出现在其他任何地方早几周，前提是有人读它们。几乎没人读，因为带有嵌套 policy_evaluated 元素的原始 XML 近乎无法阅读，而文件就那样压缩着堆在邮箱里。这个分析器填补的正是这个空白：同一份文件，转化成一张来源与判定表，并把每个失败翻译成它需要的修复方法。配套指南读懂你的 DMARC 报告用一个完整的实例，讲解了这种格式的术语——处置、对齐，以及认证结果与对齐结果的区别。
两个习惯能让报告更有价值。第一，在强制执行之前先阅读报告：带报告的 p=none 策略是一套监控系统，它运行的那几周正是你摸清每一个合法发件方的时间，这样之后转向隔离和拒绝时就不会误伤真实邮件。第二，把每一个未知来源都当作一张工单，而不是一件稀奇事——识别它、对齐它，或者看着强制执行掐断它，但绝不要让一个无法识别的发信流躺在“大概没问题”那一堆里，因为欺骗恰恰就藏在那一堆里。注意聚合报告刻意不包含的内容：没有邮件正文、没有主题行、没有收件人地址。它们是按来源统计的计数和判定，因此可以分享给服务商的支持团队——是以你主动交出文件的形式，而不是上传给某个工具。本页保持了这一特性：分析就在文件已经所在的地方进行，在你的机器上。
常见问题
什么是 DMARC 聚合报告？
它是收件方（Google、Microsoft、Yahoo 等）每天发送到你的 DMARC 记录中 rua 标签所指地址的反馈文件。对于每一个声称来自你的域名发信的来源，报告都会列出来源 IP、邮件数量、收件方采取的处置方式，以及 SPF 和 DKIM 是否与你的发件人域名对齐。它是你的域名被冒用能以数据形式显现的唯一地方，而不是等到一位困惑的客户来投诉。配套指南读懂你的 DMARC 报告逐行剖析了一份真实报告。
怎样才能收到我自己域名的这些报告？
发布一条带有报告地址的 DMARC 记录——v=DMARC1; p=none; rua=mailto:[email protected]——收件方在一两天内就会开始发送。如果你还没有记录，或者想检查现有的记录，先运行电子邮件送达能力检查：它会读取记录、策略，以及是否发布了报告地址。报告以小型 XML 文件的形式到达，通常经过 gzip 压缩或打包在 zip 里，而这正是本分析器能打开的格式。
在这里打开报告安全吗？文件会去哪里？
哪里也不去。文件在本页中、你的浏览器里解压和解析；不会上传、传输或存储。这是有意为之的设计，因为聚合报告是你邮件基础设施的一张地图——你使用的每一个发信服务、每一个 IP，以及针对你的任何冒用行为。把这张地图上传到陌生人的服务器，或者粘贴到一个会保留日志的 AI 聊天中，就是把地图交到它本不该去的人手里。
一个我不认识的来源 SPF 和 DKIM 都失败了。这是冒用吗？
要么是冒用，要么是一个没人告诉过你的发件方——而仅凭报告无法区分这两者，这也是为什么分析器把它表述成一个需要追查的问题，而不是一个结论。按顺序排查：这个 IP 是否属于你的组织付费的服务商（CRM、客服系统、旧的营销工具、被遗忘的监控服务）？流量是稳定而少量（配置错误的内部系统）还是突发而大量（一次群发活动）？只要你的策略是 p=none，这类邮件无论如何都会被投递；一旦每个合法来源都完成对齐、你开始强制隔离或拒绝，这个无法识别的发信流无论属于哪一种都会被拒收。
我自己的合法邮件失败了。先修什么？
修对齐，而且几乎总是在服务商那边。SPF 无法对齐，是因为服务商用自己的退信域名发信——用一个自定义的回信路径子域名来修复，让信封域名变成你的。DKIM 无法对齐，是因为服务商用自己的域名签名或者根本不签名——在服务商的设置里打开用你的域名进行 DKIM 签名即可修复。只要有一种机制对齐就足以通过 DMARC，但 DKIM 是两者中更稳固的，因为它能在转发后存活。按流量顺序逐个修复发件方，看着后续报告变干净，然后再提升策略。