对齐：宽松 vs 严格 — 如何选择与验证
对齐（Alignment）决定了 DMARC 判定是否“把 SPF/DKIM 的通过，算在 header.from 所属的组织域名上”。宽松（relaxed, r）允许子域与根域算同一个组织域；严格（strict, s）要求完全一致。选择错误，轻则导致阶段性失败，重则在切换时引发大面积投递异常。
验证对齐
体检会显示宽松与严格的布尔结果，并列出 header.from/smtp.mailfrom/dkim d= 字段。
一、判定逻辑（实用角度）
- 宽松：
example.com与mail.example.com视作同组织域（例如tldts的组织域算法）。 - 严格：
header.from必须与smtp.mailfrom或dkim d=完全一致。
| 维度 | 宽松（r） | 严格（s） |
|---|---|---|
| 判定 | 按组织域匹配（example.com ≈ mail.example.com） | 完全匹配（header.from 必须等于 d=/smtp.mailfrom） |
| 适用 | 多品牌/多 ESP/高变更频率 | 单品牌/统一路由/高风控要求 |
| 风险 | 欺骗风险略高 | 配置变更成本更高 |
| 迁移 | 先 r 再 s（关键域先行） | 直接 s（需严格管理来源） |
二、如何选择（三条原则）
- 先稳后严：先选宽松确保流量稳定、数据齐全，再在关键域/核心流程切到严格。
- 按组织与品牌结构决定：多品牌与多 ESP 的团队优先 r；单品牌统一路由可以直接 s。
- 与 DMARC 路线图同步：切到
p=reject前，确保关键域达到严格对齐。
三、落地清单与常见坑
- 梳理实际发件来源：ESP/自建 MTA/业务系统
- 统一 header.from 的品牌与域结构（避免混用子域）
- 确保 DKIM d= 与 smtp.mailfrom 可按域路由配置
- 先在低风险域启用严格对齐，观察 1–2 周
- 生成 PDF 证据并保留（scanId/sha256/Verify）
- 避免“临时改 header.from”：上线后未回退导致对齐长期失败。
- 注意自动化系统（如客服单、CRM）带来的“隐性来源”。
四、联动与延伸
五、证据：可验证的对齐变更
每次对齐策略变更，务必生成 PDF 并保留 scanId/sha256；遇到争议时，使用 Verify 多解析器复算即可“自证清白”。