摘要

  • 11 月 1 日的 DKIM2 第 09 版新增域名策略记录；10 月 27 日的第 08 版没有这项父域控制。
  • 父域可在自己的 _domainkey 位置发布 strict，阻止子域签名把父域 From 地址判为“Authentic”。没有该标志，草案沿用允许子域的默认路径。
  • 策略只管发布它的域名，不沿 DNS 层级上下继承。查询暂时失败是 TEMPERROR，多条有效策略记录是 PERMERROR。

外包商只租了侧门，正门却认了他的印章

企业把 mail.example.com 委托给发信服务商，服务商掌管这个子域的签名钥匙。在 DKIM2 第 09 版的拟议规则里，这枚子域签名也可能让读者看到的 example.com From 地址获得“Authentic”判定。起草者说，这承接 DKIM1 中已经普遍存在的用法，避免现有委托突然失效。第 08 版尚无新增的域名策略记录和对应的反向匹配检查。

父域要收回这项权力，得自己动手。第 3.8 节把 TXT 策略放在 _domainkey.example.com，以 v=DKIM1 开头，可选的 f= 标志列表中写入 strict。它告诉 DKIM2 验证方：子域不获准为使用 example.com 的 From 地址建立真实性。没有 strict、没有 f=，或者根本没有该记录，草案都保留子域的默认资格。这里说的是拟议 DKIM2 的 From 判定，不是已经投递的 DKIM1 邮件发生了变化。

第 7 节把路线写得很清楚：先拿 From 域名与相关签名的 d= 比对；若不匹配，再对调方向。后一趟能从子域签名向上碰到父域 From，父域的 strict 就在这里截断它。由父域本身签名的邮件不需要这条向上路径。策略也不会从父域自动传给其他子域，更不会由子域倒过来支配父域。

DNS 不是无声的配角。两条有效策略记录会触发 PERMERROR；暂时取不到记录则触发 TEMPERROR。把错误当作许可，会抹掉草案刻意画出的边界。IETF 状态页显示第 09 版仍是工作组 Internet-Draft，状态 I-D Exists；已查原始文件没有新规则的互操作部署记录。