发送方可以证明对自身域名的控制权。但它仍然可以在 From 地址中显示你的域名。仅凭成功的身份验证并不能确立使用该显示身份的权限。
为什么 SPF 和 DKIM 可以通过而 DMARC 失败？
两项检查都可以验证与可见 From 域名不匹配的域名。
SPF 检查连接服务器是否被授权使用用于投递失败通知的信封发件人域名。DKIM 验证与签名域名关联的加密签名，签名域名由签名的 d 标签标识。
信封发件人在 SMTP 会话中提供。它与收件人邮件客户端显示的 From 请求头是分开的。
例如，控制 attacker.example 的发送方可以为该域名通过 SPF 和 DKIM。发送方可以将 billing@example.com 放入 From。两项结果都未验证 example.com，因此 DMARC 失败。
组织域名是包含域名及其子域名的管理边界，例如 example.com 之于 news.example.com。
什么算作对齐？
宽松对齐要求共享组织域名。严格对齐要求域名完全相同。
RFC 9989 定义了接收方如何发现该边界。
| 已验证域名 | From 域名 | 对齐方式 |
|---|---|---|
foo.example.com | news.example.com | 宽松，因为两者共享 example.com |
news.example.com | news.example.com | 严格，因为域名完全相同 |
foo.example.net | news.example.com | 均不对齐，因为组织域名不同 |
adkim 标签控制 DKIM 对齐。aspf 标签控制 SPF 对齐。每个标签接受 r 表示宽松或 s 表示严格，默认为宽松。
仅在需要域名完全相同时使用严格对齐，因为它会排除兄弟子域名之间原本有效的匹配。以 foo.example.com 签名的服务无法满足 From 位于 news.example.com 时的严格对齐。
规范指出几乎所有域名所有者都认为宽松对齐已经足够。你的域名匹配需求决定了宽松对齐是否适用。
DMARC 是否需要两种方法都对齐？
不需要：SPF 或 DKIM 中任一方法的对齐通过即可。
接收方独立评估两种方法。通过但未对齐的结果无法提供 DMARC 通过。
转发可能因更改连接服务器而破坏 SPF。如果转发方保留了签名内容，DKIM 可以存续。来自对齐域名的完整签名可以让邮件在 SPF 失败的情况下仍通过 DMARC。
如果转发更改了签名内容，DKIM 也可能失败。如何修复 DMARC 失败介绍了诊断方法。
为什么发送服务可能破坏 SPF 对齐？
当服务使用的信封发件人域名与你的可见 From 域名不对齐时，SPF 对齐就会失败。
如果服务使用自己不相关的退信域名，SPF 可以为该域名通过。DMARC 会因未对齐而拒绝该结果。将服务添加到你域名上的 SPF 记录并不会改变接收方检查的域名。
在你自己的域名下配置自定义返回路径（用于投递失败通知的域名）。在宽松对齐下，bounce.example.com 可以与 example.com 处的 From 匹配。
DKIM 提供另一条途径：配置服务使用对齐的域名进行签名。你可以在聚合报告中确认两项结果，该报告汇总了接收方的检查。
如何使用 Bird 配置返回路径？
你在发送域名下发布 Bird 的返回路径别名。
将该别名发布为 CNAME 记录。返回路径别名提供了 Bird 的 SPF 设置，因此你无需在域名根目录为 Bird 发送单独添加 SPF 记录。
API 的 return_path.name 字段接受 1 到 63 个字母、数字或连字符，首尾必须为字母或数字。更长的标签或以连字符开头的标签无效。
Bird 会附加你的发送域名。例如，mail.example.com 上的 send 会变成 send.mail.example.com。该返回路径可以在宽松模式下与 mail.example.com 处的 From 对齐。
退信域名指南介绍了该记录。你还需要发布 DKIM 记录。Bird 接受发送域名或其组织域名上的有效 DMARC 策略。p=none 的监控策略（不表达对失败的处理偏好）即可满足要求。
规范如何发现组织域名？
RFC 9989 在域名层级中搜索确定适用策略和域名边界的记录。这个搜索过程称为 DNS 树遍历。
该规范取代了 RFC 7489 所描述的公共后缀列表方法。该列表用于识别共享注册后缀，例如 com 和 co.uk。
这一区别影响宽松对齐，因为发现的组织域名决定了相关名称是否匹配。它还影响哪个父级策略适用于子域名。已发布的规范并不能确定特定接收方实际使用了哪种发现方法。
百分比标签能否控制执行？
pct 百分比标签无法提供可靠的部分执行。RFC 9989 将其排除。
附录 A.6 描述了对中间百分比值的不一致处理。因此，将其设置为 pct=50 无法保证更严格的处理恰好影响一半失败邮件。
例外值为零和一百，分别对应无百分比执行和完全执行。一些中间方还将 pct=0 视为重写可见 From 地址以避免下游失败的信号。
在通过 none、quarantine 和 reject 更改策略之前，先使用报告修复合法的失败。值 none 不表达处理偏好。值 quarantine 将失败标记为可疑。值 reject 标识未经授权的域名使用。策略指南介绍了部署方法。
对齐通过是否证明邮件安全？
对齐通过证明了对 From 域名的授权使用，但不能确定邮件是否需要或是否安全。
接收方可以使用自己的过滤规则拒绝或隔离通过的邮件。它也可以在其他证据支持投递时接受失败的邮件。
域名授权和发送方信誉（接收方对发送方流量的评估）回答的是不同的问题。排查投递问题时请同时检查两者。
简而言之
身份验证必须匹配可见域名。
SPF 和 DKIM 可以为不相关的域名通过验证，因此 DMARC 要求对 From 中的域名进行对齐通过。
任一对齐的方法都可以提供通过。
当转发破坏 SPF 时，完整的对齐 DKIM 签名可以保留 DMARC 通过。
宽松和严格使用不同的匹配规则。
宽松对齐接受共享的组织域名。严格对齐要求域名完全相同。
域名发现和执行是不同的机制。
RFC 9989 使用 DNS 树遍历来发现域名边界。它将不可靠的百分比标签排除在策略格式之外。