报告首先是一份观察记录
主题中出现“Report domain”的邮件，并不自动代表故障告警。接收邮件的服务商在报告中汇总特定时段内观察到的、使用您发件人域名的邮件，结果可能完全正常。它不是账户遭入侵的确认，也不是某一封邮件的退信通知。
DMARC 聚合报告通过域名 DMARC 记录中的 rua 目标地址请求接收。实际数据位于 XML 附件内，附件通常经过压缩。因此，邮件正文为空并不代表报告无用。同样，熟悉的发件人显示名称也不能证明报告真实，应通过受控的流程处理这些文件。 [1] [3]
先确认时间范围，再统计数量
先查看 report_metadata：报告由谁生成、report_id 是什么、date_range 覆盖哪个 UTC 时段？再核对 policy_published 中的域名。邮件进入收件箱的日期不等于统计时段。count 统计的是具有相应验证结果组合的邮件数量，不是客户数、人数或安全事件数。
保存多份报告时，应建立可重复执行的计数规则。比对报告提供方、域名、报告 ID、时间范围和内容。相同报告的再次发送不能增加总量。两份报告的时间部分重叠时，未必有足够信息精确扣除重叠部分；应标明这一限制，不要给出看似精确的总数。 [1]
SPF 通过，不一定意味着 DMARC 通过
auth_results 保存独立的 SPF 和 DKIM 验证结果；policy_evaluated 保存它们在 DMARC 下的评估，包括域名对齐。应将这些信息与 header_from，也就是可见发件人字段中的域名比较。如果缺少与可见发件人域名的必要关联，仅仅验证通过发信服务商自己的域名还不够。
SPF 或 DKIM 至少有一个验证成功，并与可见 From 域名对齐，DMARC 才算通过。因此，SPF 失败时，邮件仍可能凭借有效且对齐的 DKIM 签名通过 DMARC。一封邮件也可能有多个 DKIM 签名，结果各不相同。应寻找成功且对齐的验证标识，不能仅凭某个孤立的“fail”下结论。 [1] [2]
确认报告范围
核对报告提供方、域名、时间范围和报告 ID，排除重复副本。
识别发信路径
将来源、SPF/DKIM 结果及域名对齐情况与已授权发信清单比对。
查明差异
修复合法发信故障、调查未知来源，或记录已确认的观察结果。
形成可核查的决定
记录负责人、已检查的发信路径和下次复查日期。实际送达情况另行验证。
示意性分析流程，不包含真实邮件或客户数据。DMARC 验证结果与实际送达证据需要分别判断。
常见结果组合应该怎样判断
下表针对 policy_evaluated 内的 SPF、DKIM 值，不针对 auth_results 的原始值。它用于帮助判断，不证明某个具体服务已获授权，也不证明邮件内容可信。 [1] [2]
左右滑动可查看完整表格。
| 报告结果 | 含义 | 下一步 |
|---|---|---|
| SPF pass，DKIM pass | 两个验证路径均通过 DMARC 评估。 | 确认来源属于已授权的发信服务。 |
| SPF fail，DKIM pass | 通过 DKIM 满足 DMARC。 | 单独调查 SPF 差异及可能的邮件转发。 |
| SPF pass，DKIM fail | 通过 SPF 满足 DMARC。 | 检查该路径的 DKIM；仅依赖 SPF 对转发的适应性较弱。 |
| SPF fail，DKIM fail | 没有成功且对齐的身份验证路径。 | 区分合法配置错误、转发影响和未授权使用。 |
| 结果缺失或无法读取 | 该记录不足以支持可靠判断。 | 检查报告格式和处理流程，不计作零失败。 |
陌生 IP 地址需要核实归属
服务商名称或数据中心所在地，不能证明某次发信由谁发起。共享邮件基础设施可能承载许多客户的邮件。应将来源与企业实际授权的服务逐一核对：普通邮箱、网站表单、开票系统、支持平台和邮件简报都应分别列入清单。
相关域名、DKIM 选择器、发信日志以及受控接收的邮件，可帮助确认发信路径。不要为了消除警告就把未知 IP 加入 SPF。先查明授权关系。如果合法服务出现问题，应指定修复负责人，并明确复查所需的证据。网页邮箱成功发出测试邮件，不代表网站表单的发信配置同样正确。 [2] [4]
“none”不等于进入收件箱
disposition 描述接收方在 DMARC 评估中报告的处理方式。none 不是送达证明；quarantine 也不能可靠地指出某封邮件最终所在的文件夹。接收系统可以应用其他规则。即使 DMARC 通过，也不保证进入收件箱，更不保证内容可信。调查具体邮件丢失时，需要结合发信日志、退信，以及可获得的接收端原始邮件。
报告也只反映出具报告的系统在指定时段内的观察。报告缺失或数据存在空缺，不等于没有发信，也不等于没有滥用。应记录这些空缺。比较趋势时，使用同一组报告提供方和等长时段，并先核对覆盖范围是否变化。 [1] [4]
把发现转化为明确的处理任务
如果某条已授权、对业务重要的发信路径无法通过 DMARC，或其结果发生无法解释的变化，就应处理。持续出现的未知来源也需要确认归属。措施应由证据决定，而不是自动加强或放宽 DNS 策略。调整策略前，先列出并验证合法发信路径，修复已知身份验证问题。 [2]
- 核对报告提供方、域名、UTC 时段及重复报告。
- 区分原始 SPF/DKIM 结果与 DMARC 域名对齐结果。
- 将异常来源落实到具体服务和负责人。
- 检查经授权的测试邮件、相关邮件头及发信日志。
- 确定修复内容、变更时段和回退步骤。
- 变更后分别核查身份验证与实际送达情况。