把三种身份分开
- Author Domain：收件人看到的 RFC5322
From:域，也是 DMARC policy discovery 的起点。 - SPF 域：通过 SPF 的 MAIL FROM 或空 MAIL FROM 时的 HELO 身份，不一定等于可见 From。
- DKIM 域：通过验证的
DKIM-Signature中的d=值。
DMARC 需要 SPF 或 DKIM 至少一条既通过认证又与 Author Domain 对齐。默认 relaxed 模式允许同一组织域下的子域对齐；若 DMARC 使用 aspf=s 或 adkim=s，则相应身份必须严格匹配。
“SPF=pass”或“DKIM=pass”本身不等于 DMARC 对齐。必须同时比较通过认证的域与可见 From 域。
从真实邮件证据定位
- 保存完整退信。对于同一路径曾成功接收的样本，打开原始邮件头中的
Authentication-Results、Return-Path和DKIM-Signature。 - 记录可见 From 域、SPF 认证域及结果、每条 DKIM 的
d=及结果。 - 若 SPF 通过但不对齐，为邮件平台配置属于你的自定义 MAIL FROM、bounce 或 return-path 域。
- 若 DKIM 通过但不对齐，为平台配置属于你的自定义 DKIM 签名域并发布平台给出的 selector。
- 重新发送新邮件，确认至少一条路径同时显示
pass与 aligned。
常见误修
只新增 DMARC 记录不会让第三方平台自动使用你的域签名；只把平台 include 加进 SPF，也不保证 MAIL FROM 与 From 对齐。转发还可能破坏 SPF，因此可保持有效的 DKIM 签名通常更可靠，但仍必须核对实际消息。
若 Author Domain 是子域，DMARC policy discovery 可能应用该子域的直接记录或 RFC 9989 Tree Walk 找到的上级策略。策略来源与身份是否对齐是两个问题，不能混为一谈。
不要把可见 From 临时改成邮件服务商域来掩盖配置问题，也不要复制服务商以外的 DKIM 公钥。应使用平台正式提供的自定义域功能，让合法业务身份保持可识别和可控。
工具边界
域名体检可以发现 SPF、DMARC 和指定 selector 的 DKIM 公钥问题，并按 RFC 9989 查找可应用策略；仅凭域名无法知道某封邮件实际使用了哪个 MAIL FROM、哪个 d=，或认证是否通过。因此最终结论必须来自真实邮件头或发送平台日志。