DMARCbis 中新增的 pct= 采样百分比政策和原来的 pct 标签有什么变化？是否支持逐子域策略？

DMARCbis 标准对 pct= 标签进行了关键的语义重构，并引入了全新的 sps=（Single subdomain Policy）标签来解决子域策略的灵活性问题。本文将详细解读这些变化。

一、pct= 标签的语义重构

原 RFC 7489 的 pct= 歧义

在 RFC 7489 中，pct= 的最初定义是"策略应用的百分比"。具体描述为：当设置了 p=quarantine 或 p=reject 时，只对 pct% 的失败邮件应用该策略。然而，在长达十年的实际部署中，大量邮件管理员和报告解析器错误地将 pct= 理解为"报告采样百分比"——即只对 pct% 的邮件生成 DMARC 报告。

这种歧义导致了严重的实际后果：某些 DMARC 报告解析器丢弃了超出 pct 范围的邮件数据，造成报告数据不完整；而发送方则误以为 pct= 可以控制报告量以节约处理资源。

DMARCbis 对 pct= 的明确重构

RFC 9989 对 pct= 做了以下三项关键修改：

1. 明确 pct= 只影响策略应用，不影响报告生成：无论 pct= 的值是多少，接收方都应对所有进行了 DMARC 评估的邮件生成聚合报告（如果配置了 RUA）。这一修改消除了十年的歧义。
2. 报告中的 pcf 字段：RFC 9991 新聚合报告格式中新增了 pcf（Policy Count Fraction）字段，明确记录当前报告周期中实际应用了策略的邮件数量与总失败邮件数的比例。
3. pct=0 的特殊含义：DMARCbis 规定 pct=0 表示"当前不应用任何策略"但"仍在采集报告数据"。这为逐步部署提供了一种更清晰的过渡状态。原有的 p=none 策略配合 pct=0 在 DMARCbis 下将产生"p=none 且无实际操作"的效果。

示例配置对比：
RFC 7489: v=DMARC1; p=reject; pct=25
→ 歧义：25% 的失败邮件被拒，还是只有 25% 的邮件产生报告？

RFC 9989: v=DMARC1; p=reject; pct=25
→ 明确：25% 的失败邮件被拒，100% 的邮件产生报告

迁移建议

如果你的 DMARC 配置中使用了 pct=，建议验证以下两点：

• 检查你的报告分析工具是否已更新以支持 RFC 9991 格式（特别是 pcf 字段）
• 确认你设置的 pct 值符合业务意图——例如，pct=10 在旧标准下可能让发送方认为"只有 10% 的邮件出了报告"，现在这是明确错误的

二、逐子域策略：新增 sps= 标签

这是 DMARCbis 最重要的新功能之一。原 DMARC 只支持一个 sp= 标签统一应用于所有子域。对于运营大量子域的大型企业而言，这种"一刀切"的做法非常不便。DMARCbis 引入了 sps=（Single subdomain Policy）标签。

sps= 语法

v=DMARC1; p=reject; sp=reject; sps=marketing.example.com:none; sps=dev.example.com:quarantine

在以上示例中：

• p=reject 为主域 example.com 的策略
• sp=reject 为所有未列出的子域的默认策略
• sps 为 marketing.example.com 和 dev.example.com 设置了例外策略

sps= 的优先级规则

1. 接收方首先检查 _dmarc.<子域> 是否有独立的 DMARC 记录——如果有，使用该记录
2. 如果没有独立的子域记录，检查父域的 DMARC 记录中是否有 sps=<该子域>:<策略>——匹配则使用 sps 指定的策略
3. 如果 sps 也不匹配，使用 sp= 默认策略
4. 如果 sp= 不存在，回退到 p= 主域策略

sps= 的限制

• DMARCbis 规定单个 DMARC 记录中最多可包含 10 个 sps= 标签（实际部署建议不超过 5 个）
• sps= 指定的子域必须是被验证为属于该组织域（Organizational Domain）的子域
• sps= 必须依赖 sp= 提供 fallback 策略

三、sps= 典型使用场景

• 第三方 ESP 发信：主域 p=reject，但允许第三方营销平台通过子域 news.example.com 发信，策略设为 none 或 quarantine
• 内部开发环境：主域强制策略 p=reject，dev.example.com 设为 quarantine 以容忍开发中的 DKIM 配置错误
• 合并/收购：被收购域作为子域管理期间使用特殊策略，避免影响主域信誉