RFC 9991（DMARCbis Aggregate Report）XML 格式有哪些重要升级？RUA 报告中的新字段怎么解读？

RFC 9991 是 DMARCbis 标准集的第三部分，它正式将 DMARC 聚合报告（RUA）的 XML 格式从过去实践中的非正式 Schema 升级为 IETF 正式规范。本文将详细解读格式变化、新增字段及其含义。

一、命名空间与根元素变更

最直观的变化是 XML 命名空间（namespace）的更新：

<!-- RFC 7489 实践中的非正式格式 -->
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-1.0">

<!-- RFC 9991 正式格式 -->
<feedback xmlns="urn:ietf:params:xml:ns:dmarcbis-1.0">

这一变更意味着接收方和报告解析工具需要更新以识别新的命名空间。向后兼容性方面，RFC 9991 规定解析器应能同时处理旧命名空间（dmarc-1.0）和新命名空间（dmarcbis-1.0）格式。

二、新增核心字段详解

1. pcf（Policy Count Fraction）

在 <policy_published> 下新增的 <pcf> 字段用于记录本报告周期中实际应用了策略（reject或quarantine）的邮件数与总失败认证邮件数的比例。这一字段解决了原标准中报告采样与策略采样混淆的问题。

示例值：pcf=0.25 表示在 DMARC 验证失败的邮件中，只有 25% 实际应用了 p=reject 策略（因为 pct=25 的限制）。

2. spf_auth_result 与 dkim_auth_result 细化

原格式的 <auth_results> 中仅粗略记录 SPF 和 DKIM 的验证结果（pass/fail）。RFC 9991 将结果细化为多个子字段：

<auth_results>
  <spf>
    <domain>example.com</domain>
    <scope>mfrom</scope>
    <result>pass</result>
    <aligned>yes</aligned>        <!-- 新增 -->
    <selector>default._domainkey</selector>  <!-- 新增 -->
  </spf>
</auth_results>

<aligned> 字段明确记录该验证方法是否与 From 域对齐，<selector> 记录 DKIM 所使用的选择器名称，方便管理员精确定位未对齐的密钥。

3. arc_chain 验证字段

新增的 <arc> 块记录接收方对 ARC（Authenticated Received Chain）的验证结果：

<arc>
  <chain_validation>pass</chain_validation>
  <instance_count>2</instance_count>
</arc>

该字段帮助管理员判断邮件是否经过合法转发链，避免将合法转发误判为伪造。

4. disposition 细化

原 <disposition> 只有 none / quarantine / reject 三个值。RFC 9991 新增了可选子字段：

• <reason>：记录应用该处置策略的具体原因（如 spf-only-fail、dkim-only-fail、both-fail、policy-block）
• <policy_source>：记录策略来源（org-domain、subdomain、sps、arc-override）

三、完整 XML 示例

<?xml version="1.0" encoding="UTF-8"?>
<feedback xmlns="urn:ietf:params:xml:ns:dmarcbis-1.0">
  <report_metadata>
    <org_name>example-receiver.com</org_name>
    <email>dmarc-reports@example-receiver.com</email>
    <extra_contact_info>http://example-receiver.com/dmarc-help</extra_contact_info>
    <report_id>202607281200.id.example</report_id>
    <date_range>
      <begin>1722153600</begin>
      <end>1722239999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pt>
    <pcf>1.0</pcf>              <!-- 新增 -->
    <fo>0</fo>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.1</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>
          <action>reject</action>
          <reason>both-fail</reason>    <!-- 新增 -->
          <policy_source>org-domain</policy_source>  <!-- 新增 -->
        </disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
      <arc>                              <!-- 新增 -->
        <chain_validation>none</chain_validation>
      </arc>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <scope>mfrom</scope>
        <result>fail</result>
        <aligned>yes</aligned>          <!-- 新增 -->
      </spf>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <selector>s1024</selector>      <!-- 新增 -->
        <aligned>no</aligned>           <!-- 新增 -->
      </dkim>
    </auth_results>
  </record>
</feedback>

四、报告解析工具升级建议

1. 确认你的 DMARC 报告分析工具（如 dmarcian、URIports、Postmark 等）已支持 RFC 9991 格式
2. 如果使用自建解析器（Python 脚本、Perl 解析器），需要更新 XML 命名空间识别逻辑
3. 注意新字段的可选性——并非所有接收方都会立即升级到 RFC 9991 格式
4. 建议在过渡期同时处理旧格式（dmarc-1.0）和新格式（dmarcbis-1.0）