DMARCbis 中的 subdomain policy（sp=）和 organizational domain 概念有没有变化？

子域策略（sp=）和组织域（Organizational Domain）是 DMARC 部署中两个非常重要的概念。DMARCbis 对它们进行了多项重要修订和细化，使得大规模多域名部署更加可控。

一、sp=（子域策略）标签的变化

1.1 默认值问题得到解决

RFC 7489 对 sp= 标签的定义存在一个长期问题：如果 DMARC 记录中没有 sp=，子域的行为应该回退到 p= 策略还是另有默认值？原标准对此表述模糊，导致不同接收方的实现存在差异。

RFC 9989 明确：

• 如果 DMARC 记录中不包含 sp= 标签，子域将使用主域 p= 策略作为默认值
• 如果主域 p=none，没有任何 sp= 的情况下，所有子域也是 none
• 最佳实践：建议始终显式地设置 sp=，而不是依赖默认回退

示例：
v=DMARC1; p=reject; sp=reject   → 主域和子域均 reject
v=DMARC1; p=reject              → RFC 9989: 子域也适用 reject（与 p= 相同）

1.2 sp= 与 sps= 的交互规则

DMARCbis 新引入的 sps=（单子域策略）可以与 sp= 配合使用（详见 FAQ-02）。优先级顺序为：

1. 子域上独立的 DMARC 记录（_dmarc.sub.example.com）
2. 父域记录中的 sps= 匹配
3. 父域记录中的 sp= 默认值
4. 父域记录中的 p=（作为 sp 的 fallback）

二、组织域（Organizational Domain）的变化

2.1 默认公共后缀列表

RFC 9989 明确指定了组织域的判定标准：

• 使用 Public Suffix List (PSL) 作为默认的公共后缀列表
• 接收方必须维护或引用最新的 PSL 副本
• 组织域 = 注册域（registered domain）= 公共后缀的上一个超级域

示例：
example.co.uk       → 组织域：example.co.uk
sub.example.co.uk   → 子域，组织域：example.co.uk
mail.example.com    → 子域，组织域：example.com

2.2 公共后缀异常列表（Exception List）

DMARCbis 引入了一个重要的新概念：Public Suffix Exception List（公共后缀异常列表）。某些域名在 PSL 中被归类为公共后缀，但实际上可能是某个组织拥有的注册域。例如：

• cloudfront.net（AWS）在 PSL 中是一个公共后缀
• 但 myapp.cloudfront.net 实际上是 AWS 客户的自定义域名——接收方不应自动将组织域判定为 cloudfront.net

异常列表机制允许接收方为特定公共后缀设置例外规则，使 DMARC 评估更准确。

2.3 多个组织域的边界情况

对于大型集团或企业收购后的多域名场景，DMARCbis 新增了一条规则：

• 如果接收方无法确定唯一的组织域（例如邮件 From 域是一个公共后缀本身），应回退到 p=none 处理
• 发送方可以通过配置 sps= 或 dpub-domain 来辅助接收方决策

三、子域策略的实际部署建议

3.1 典型策略模板

; 设置 1：所有子域无例外（严格）
v=DMARC1; p=reject; sp=reject

; 设置 2：子域隔离，主域拒绝
v=DMARC1; p=reject; sp=quarantine

; 设置 3：子域有特例（DMARCbis 新增 sps=）
v=DMARC1; p=reject; sp=reject; sps=news.example.com:quarantine; sps=dev.example.com:none

3.2 检查清单

1. DMARC 记录中是否显式声明了 sp=? 如果没有，所有子域默认使用 p= 策略
2. 是否有子域需要不同的 DMARC 策略？考虑 sps=
3. 你的组织域在 PSL 中是否有特殊情形（如 .com 域没问题，但 .co.uk 或 .cloudfront.net 类型的域）
4. 收购或合并后的多域名是否被正确识别为同一组织域