摘要

  • RFC 9990 规定邮件接收方如何按时间窗汇总认证结果、DMARC 对齐、评估处置、来源、数量和本地覆盖理由。
  • 聚合行不是逐封事件账本。一个报告可能跨越策略变更，部分重叠难以拆分，规范也明确提醒报告数据可能被伪造。
  • Daniel Kade 建议在真正依赖报告作出决定时保存一份最小凭证，记录生成方、时间窗、策略时期、文件摘要、重叠处理和决定，不留正文或个人地址。

标准化的是观察报告，不是整个互联网

域名所有者看不到每家收件系统内部发生了什么。DMARC 聚合报告填补了这块视野：哪些源 IP 声称代表域名发信，SPF 或 DKIM 是否通过，是否与 From 域对齐，接收方评估了什么处置，又因何采用本地例外。

这些信息可以发现漏配的选择器、未经登记的发送服务或转发造成的认证变化。它是有用而且必要的运营证据。但仪表盘看到的是愿意并成功发送报告的接收方，不是邮件世界的全知视图。某个接收方可能没有生成文件，可能延迟投递，也可能在目的端不可达时缓存或丢弃数据。

因此，总数的含义应当是“已收到的报告声称覆盖这些消息”，而不是“全球只有这些消息”。聚合本身没有问题；把未知覆盖范围抹成确定分母，才是治理失真。

RFC 9990 连接了哪些字段

RFC 9990 于 2026 年 5 月作为 IETF 标准轨文档发布，规定 DMARC 聚合报告，并与新的 DMARC 规范一起取代 RFC 7489 的相应部分。域名所有者在策略记录中声明报告目的地，邮件接收方评估收到的消息，生成 XML，并向通过检查的目的地尝试投递。

报告元数据包含报告组织、Report-ID 和 UTC 时间范围。policy_published 描述接收方所观察到的策略配置。每行把源 IP、消息数量、评估处置、对齐结果和认证标识组合起来。DKIM 与 SPF 结果各自保留。若接收方没有执行域名所有者请求的动作，理由可以是本地策略、邮件列表、测试模式、可信转发方或其他情况。

这些字段各有边界。时间范围是汇总区间，不是第一封和最后一封邮件的精确事件时钟。数量是接收方按元组归组后的计数。覆盖理由说明接收方如何分类自己的例外，并不证明所有后续过滤步骤。

规范还要求计数包括已经收到、但最终可能被其他过滤器阻断的消息。所以 DMARC 处置不能直接读成投递成功、进入收件箱或被用户读取。它只是更大处置链中的一个观察面。

聚合省去了正文，也省去了事件连接

如果五千封邮件共享相同来源和认证组合，一行就足以暴露趋势。这正是聚合的效率。与此同时，报告不会给五千封邮件各自保留稳定事件 ID，消费者无法仅凭这一行还原先后顺序，也无法把每个数量逐一连接到后续过滤、最终文件夹或用户动作。

当报告只用于排查，这个限制通常可以接受。当机器要据此暂停发送方、改变全局策略或调整架构时，限制就必须重新出现。

数字突然上升，可能是未授权发送，也可能是新增报告方、晚到文件、归组规则变化或重叠时间窗。报告足以触发调查，不足以单独证明原因。把“接收方对自身评估的汇总陈述”改写成“邮件流本身的事实”，等于无声扩大生成方的权力。

一个策略字段可能覆盖两个策略时期

域名在报告周期中修改 DMARC 策略时，接收方不会同时看到变化。DNS 缓存、查询时点和实现方式都会造成差异。RFC 9990 允许接收方分别生成多份报告，也允许生成一份混合报告：其中有些处置依据旧策略，有些依据新策略，但文件里只有一个 policy_published。

持续追踪互联网规模的每次策略转变会给接收方带来很大负担，因此规范把识别混合情况的责任明确留给报告消费者与域名所有者。这是合理的工程折中，也意味着策略字段不能自动充当每条计数的时期证明。

假设域名中午从观察模式切换到更严格动作，日报显示最终配置。午前产生的失败不能被回溯性地归到新策略下。若没有额外时期信息，最诚实的标签是“混合”或“未知”，而不是为每封邮件假造精确归属。

报告邮件通过认证，不等于 XML 中每项观察都被认证

承载反馈报告的邮件必须取得对齐的 DMARC 通过结果，传输也应使用安全通道。若报告目的地属于另一个组织域，目的方必须通过 DNS 明确授权；验证失败时，接收方应忽略该 URI。

这些控制很重要。它们减少无关域伪造报告邮件的风险，也防止恶意域名把大量报告引向不愿接收的第三方。然而，反馈邮件的域对齐证明、外部目的方的接收意愿、文件完整性和 XML 中观察的真实性，是四个不同命题。

RFC 9990 直接指出，聚合报告中的数据可能被伪造，攻击者可能用大批虚假报告影响策略或平台架构。规范没有因此否定报告，而是提醒消费者不要把传输身份扩张成内容真相。

Report-ID 解决重传识别，不解决集合是否相交

Report-ID 必须在发往同一域名的报告中保持唯一。原始文件名记录生成方、策略域和时间边界；重传时必须沿用同一文件名。这让消费者有机会识别同一文件的再次到达。

但两个不同 Report-ID 仍可能包含重叠数据。RFC 9990 把处置选择留给消费者：拒绝、丢弃、检查后处理或接受。若两个周期只部分相交，规范承认没有清晰办法分离重叠影响，消费者可能只能整体接受或整体拒绝。

于是，“每个唯一 ID 都相加”不是中性实现，而是一项证据决策。只要总数会推动高后果动作，去重规则、相交判断和负责人就应留在审计链里。

外部目的方同意接收，不代表它的分析自动正确

许多组织把报告交给专业服务处理。外部授权记录证明服务愿意为请求域名接收报告，并且可以撤回，尽管 DNS TTL 会延迟效果。这种机制把报告请求与第三方同意分开，是必要的防滥用设计。

授权并没有认可服务的解析器、归一化、归因模型、保留策略或建议阈值。域名所有者仍需知道：哪些文件被接纳，哪些行被丢弃，部分重叠如何处理，扩展字段如何解释，以及哪条规则把异常转成策略建议。

工具可以外包，理解证据范围的责任不能随 DNS 记录一起外包。

补足来源链，不应反过来收集每封邮件

聚合报告不包含邮件正文、个人邮箱地址或用户身份特征。这种最小化应当保留。另一方面，流量模式本身仍可能敏感，尤其在中介服务或公共后缀报告场景中。更强的审计不能以重建个人通信为代价。

消费者真正需要的是文件与决定之间的来源链：文件摘要、生成方、策略域、时间窗、策略时期、接受的数据集摘要、异常检查与决定。它们不要求保存正文、收件人或收件箱位置。

报告处理器还必须把压缩包和 XML 当作不受信输入。压缩炸弹和 XML 资源耗尽属于规范点明的风险。语法解析成功与证据接纳应分成两道门：能读的文件仍可因身份、重叠或策略背景不清而被隔离。

在依赖点保存“聚合采用凭证”

Daniel Kade 提议，当报告开始支撑具体决策时，另存一份小型凭证。这不是 RFC 9990 的要求，也不改变原始 XML。

第一组记录原始制品：Report-ID、原文件名、SHA 摘要、大小、接收时间、传输认证结果和生成方身份依据。第二组记录声明范围：策略域、UTC 起止、报告模式版本、时间窗是否完整、迟到或已知部分缺失。

第三组描述策略时期：保存 policy_published，并明确标注“单一”“混合”或“未知”。第四组保存重叠判断：相关报告、交叉窗口、替换、合并、拒绝、接受或隔离的选择，以及采用的规则与负责人。

第五组绑定转换结果：解析器与归一化版本、接受行集摘要、拒绝行数、忽略扩展和异常检测结果。这样能从仪表盘回到稳定输入，却不需要保存邮件流。

最后记录实际依赖：调查、联系发送方、轮换密钥、改变策略、维持现状、回滚或被新报告取代。凭证应列明阈值、决策角色、不确定性和纠正链接。

它不是给报告增加不可能的绝对证明，而是防止机构在使用报告时遗忘其观察边界。

证据边界

已核对来源证明报告字段、混合策略许可、重叠难题、外部授权、隐私风险和伪造警告。它们没有提供 RFC 9990 的部署比例、重叠发生率，也没有证明任何命名接收方或供应商曾提交错误数据。

本文不主张聚合报告只是意见，不主张 DMARC 通过无效，也不主张保留逐封邮件。更窄的结论是：标准化聚合仍是某个运营观察者的陈述。高后果决策需要保留从这份陈述到策略时期、去重处理、转换和授权行动的连接。

来源