谁发送了报告
收件方的组织(如 google.com 或 Enterprise Outlook)、联系地址、唯一的报告 ID,以及以 Unix 时间戳表示的时间范围。
DMARC 汇总报告很难读:压缩的 XML 里满是 IP 地址。把文件拖到这里,就能看到谁在以您的域名发信、其中有多少通过 DMARC、哪些来源失败——在把策略升级到 quarantine 或 reject 之前先弄清楚。
100% 在您的浏览器中运行——不上传任何内容
🔒 隐私优先:报告在您的浏览器中解压和分析,绝不上传。
| 报告方 | 域名 | 时间段 | 策略 | 邮件数 | 报告 ID |
|---|
| 来源 IP | 邮件数 | DMARC | 对齐 | 认证结果 | Header From | 处置 |
|---|
即使 SPF、DKIM 和 DMARC 完美无缺,也无法阻止退信。向无效、一次性或废弃的地址发信,对发件人信誉的伤害丝毫不小。请在下一次营销活动前验证您的名单。
Google、Microsoft、Yahoo 等收件方每天会把报告发送到您 DMARC 记录中的 rua 地址,通常是 .zip 或 .gz 附件。
选择一个或多个文件——XML、.gz 或 .zip。文件在您的浏览器中解压和解析,不会上传。
查看邮件总数、通过 DMARC 的比例、DKIM 与 SPF 对齐通过率,以及收件方采取的处置方式。
每个来源 IP 都会列出其邮件量和结果。失败的合法服务需要配置 DKIM 或 SPF;不认识的来源可能是伪造。
其格式由 RFC 7489(附录 C)定义。每份报告对应一个域名、一个收件方和一个时间段——通常为 24 小时。
收件方的组织(如 google.com 或 Enterprise Outlook)、联系地址、唯一的报告 ID,以及以 Unix 时间戳表示的时间范围。
收件方评估您的邮件时在 DNS 中查到的域名、p、sp、pct 以及 adkim/aspf 对齐模式。
对每个来源 IP:邮件数量、采取的处置(none、quarantine、reject),以及 DKIM 和 SPF 是否对齐通过。两者任一通过,DMARC 即通过。
实际检查的域名及其结果(对齐前)。DKIM 对其他域名通过、或 SPF 对某平台的退信域名通过,能解释大多数 “fail” 行。
不会。文件通过浏览器内置 API 在本地读取、解压和解析,不会发送到我们的服务器,因此可以放心打开包含您基础设施 IP 的报告。
纯 XML、gzip(.gz、.xml.gz——Microsoft 和 Yahoo 常用)以及 ZIP(.zip——Google 常用),可一次处理多个文件。解压使用浏览器内置的 DecompressionStream,当前版本的 Chrome、Edge、Firefox 和 Safari 均支持。如果您的浏览器较旧,请先解压再拖入 .xml。
通常是因为该服务用自己的域名发信:SPF 针对其退信域名通过,DKIM 用其域名签名,两者都无法与您的 From 域名对齐。在该服务中配置使用您域名的 DKIM(或自定义 return-path),这些行就会变绿。
收件方对邮件采取的处理:none(正常投递)、quarantine(垃圾邮件箱)或 reject(拒收)。在 p=none 下始终为 none;这一列能帮您预判收紧策略后会有什么变化。
当邮件列表或转发规则重新发送邮件时,新服务器的 IP 不在您的 SPF 中,因此 SPF 失败。DKIM 通常能在转发中保留,有效的 DKIM 签名可让 DMARC 继续通过。来自邮箱服务商的少量仅 SPF 失败属于正常现象。
在 DMARC 记录中添加 rua 标签,例如 rua=mailto:[email protected]。我们的免费 DMARC 生成器可以帮您生成记录。一两天内,每个收到您邮件的服务商都会开始发送报告。
当报告连续几周显示您几乎所有合法邮件都通过 DMARC,剩余失败只来自未知来源或转发时。请先经过 p=quarantine 阶段,可配合 pct 逐步推进。