DMARC 对齐容易被遗漏。SPF、DKIM 和 DMARC 都已发布，邮件却仍被过滤或拒收。除了商务邮箱指南中的整体配置，还应验证实际发信渠道。
认证通过并不够。至少一项通过 SPF 或 DKIM 认证的域名，必须与可见 From 对齐。缺少这样的结果就会导致 DMARC 失败，但不等于证明冒用。发信平台、CRM、客服、转发和未完成的 DNS 设置，都可能出现对齐问题。
下面说明对齐原理、SPF 的局限以及如何检查重要的接收头字段。转发时，经过验证的对齐 DKIM 很有帮助，但不保证经过任何中间服务器都继续有效。
什么是 DMARC 对齐
DMARC 检查 SPF 或 DKIM 认证域名与可见 From 的关系。任何一项同时认证通过并对齐就足够。没有这样的结果，DMARC 就无法通过。
这来自 RFC 7489。DMARC 基于 SPF 和 DKIM，不另行执行独立认证，而是检查通过认证的域名是否与用户看到的 From 域名对应。
各机制的检查对象：
| 机制 | 接收方验证什么 | DMARC 对齐要求 |
|---|---|---|
| SPF | 信封发件域名 / Return-Path 对发信 IP 的授权 | Return-Path 域名须与 From 对齐 |
| DKIM | DKIM 签名的有效性与 d= 域名 | d= 域名须与 From 对齐 |
| DMARC | 通过且对齐的认证结果 | 以上至少一项须同时通过并对齐 |
只有 SPF pass 或 DKIM pass 不够，其中一项通过认证的域名必须与 From 对齐。这不证明内容安全，也不保证进入收件箱。
DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)为什么 SPF 通过却未满足对齐
Return-Path 属于服务商时，SPF 可以对服务商域名通过，却没有与你的 From 对齐。通过且对齐的 DKIM 仍可以让 DMARC 通过。
发信平台需要处理退信和发送事件，因此部分配置使用服务商自己的 Return-Path 域名。
可见 From：billing@example.com
Return-Path：bounces+123@sendgrid.net
SPF 可以通过，因为 SendGrid 为 sendgrid.net 授权了发信 IP。但 sendgrid.net 不与 example.com 对齐，所以这个 SPF 结果不提供对齐。其他通过且对齐的机制仍可能让 DMARC 通过。
自定义退信域名或 custom Return-Path 可以帮助 SPF 对齐。仅设置链接品牌或跟踪域名不会自动改变信封发件人，应核对服务商实际功能。
bounces.example.com. CNAME u1234.wl.sendgrid.net.完成服务商配置和启用后，发信方可能使用 bounces.example.com 作为信封域名，宽松模式下它与 example.com 对齐。单独发布 CNAME 不代表已经启用这一发信设置，应测试真实邮件。
转发还有其他限制：接收方看到的是转发服务器 IP，而非原始发信 IP，因此 SPF 可能失败。将域名邮件转发到 Gmail和邮箱别名转发介绍相关影响。SPF 有用，但不能覆盖所有转发路径。
为什么对齐的 DKIM 尤其有用
DKIM 可以在转发后继续有效，前提是签名仍通过验证、与 From 对齐，并且签名覆盖的数据在规范化规则下得到保留。修改内容或已签名头字段可能破坏验证。
因此建议配置并测试对齐 DKIM。不过，如果 SPF 已通过且对齐，DMARC 并不强制必须再有 DKIM。服务商仅使用自身域名签名，不会自动提供你的域名对齐。
可见 From：newsletter@example.com
DKIM 签名：d=mailchimpapp.net
DKIM 可能通过却未对齐。只有同时缺少通过且对齐的 SPF 时，DMARC 才会因此失败。
应在实际发信平台配置域名认证。通常要发布服务商提供的 DKIM 记录，随后启用域名，并确认真实邮件使用该域名签名。
s1._domainkey.example.com. CNAME s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com. CNAME s2.domainkey.u1234.vendor.net.正确启用后，平台可以使用 d=example.com，或宽松对齐的子域名，例如 d=mail.example.com。有效且对齐的签名可以在转发导致 SPF 失败时支持 DMARC 通过。
Google 所说明的批量发件要求包括通过成功的 SPF 或 DKIM 满足 From 对齐。应核对当前适用条件。对齐错误可能引发限制，但不是垃圾邮件过滤或拒收的唯一原因。
宽松与严格 DMARC 对齐
宽松模式比较组织域名，严格模式要求精确域名匹配。宽松是默认方式，但仍应根据真实发信路径和要求选择，并非所有环境的唯一正确方案。
相关标签是 SPF 的 aspf 与 DKIM 的 adkim。
| 模式 | 什么算作对齐 | 实际影响 |
|---|---|---|
| 宽松 | mail.example.com 与 example.com 对齐 | 允许同一组织域名下适用的子域名 |
| 严格 | 只接受精确域名匹配 | 不同的正常发信域名可能需要调整 |
示例：
_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"严格模式需要有意验证。应用使用 mail.example.com 签名而 From 为 example.com 时，这项 DKIM 不满足严格对齐。
只有需求明确并测试所有发信源后，才应选择严格模式。宽松模式可能更适合其他环境，但不会自动提供认证成功。
如何排查 DMARC 对齐
检查可信接收服务器自行生成的结果：Authentication-Results、DKIM d=、SPF smtp.mailfrom，以及关联 header.from 的 dmarc。任意附带的头字段都可能被伪造，不能直接当作可信证据。
接收方自身的结果与实际 DKIM 签名，可以显示所用域名。仅靠发信面板不能证明某封邮件的真实路径。
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net header.s=s1;
spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
dmarc=fail header.from=example.com按以下顺序检查：
- 检查
header.from，这是 DMARC 使用的可见域名。 - 检查
smtp.mailfrom中的 SPF 域名。不同的组织域名不提供 SPF 对齐。 - 不要把
header.i当作决定性的签名域名。DMARC 依据成功验证的 DKIM 签名中的d=。 - 如果 SPF、DKIM 都没有提供通过且与 From 对齐的结果，即使对其他域名认证成功，DMARC 仍失败。
还可辅助查询 DNS：
dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com只在转发后出现的 SPF 失败可能来自新的服务器。有效且对齐的 DKIM 仍可以支持 DMARC 通过，但必须检查具体签名。ARC 可以帮助本地例外处理，不会将 DMARC 失败变为验证成功。
搭建域名时，可以参考 TrekMail 的域名设置指南和创建自有域名邮箱。应维护实际信封域名的有效 SPF、启用 DKIM，并正确发布 DMARC。MX 只应按经过验证的切换计划修改。
常见对齐失败模式
第三方发信、转发、不同子域名，以及重复或陈旧的 DNS，都是需要调查的来源。应按真实发信结果判断影响。
常见情况：
- 营销平台使用自身退信域名，SPF 通过却未对齐；DKIM 仍可能让 DMARC 通过。
- 服务商以自身域名签名，DKIM 未对齐；成功且对齐的 SPF 仍可能足够。
- 转发可能导致 SPF 失败，有效且对齐的 DKIM 常成为剩余的通过依据。
- 意外开启严格模式，排除了不同的子域名。
- 旧 DNS 与当前配置不符，但不会自动改变实际签名平台，应分别核对发信与路由。
如果 4.7.32 明确指出 From 未与 SPF 或 DKIM 对齐，应检查这一认证关系。适用条件见 Google 发件人常见问题，其他投递问题可能另有原因。
通过 TrekMail 检查对齐
TrekMail 可以集中邮箱、DNS 状态和发信配置，减少在五个管理面板之间切换。但正确记录和真实邮件测试仍不能省略。
可能的工作方式：
分散管理与集中流程
| 分散管理 | TrekMail 可提供的流程 |
|---|---|
| 分别管理邮箱、发信和 DNS | 集中域名、邮箱、SMTP 选择和 DNS 检查 |
| 逐个核对服务商 SPF 与 DKIM | 使用向导和 DNS 检查，再进行邮件测试 |
| 单独调查转发影响与投诉 | 结合对齐 DKIM 和有记录的转发测试 |
适用付费套餐提供托管 SMTP，自备 SMTP 则可能按套餐连接 SES、SendGrid、Mailgun 等服务。应核对当前条件与真实发信，绿色 DNS 状态不证明所有来源已对齐。
可参考的 TrekMail 资料：
邮件进入垃圾邮件的常见问题也讨论转发。IMAP 与 SMTP 设置介绍客户端连接；客户端登录和域名认证是不同检查。
Starter 的价格参考为每月 $3.50。提供的付费套餐 14 天试用需要信用卡。Nano 有自备 SMTP 的免费选项，支持最多 10 个域名和 5 GB 共享存储。当前功能、限制和条件见 TrekMail 价格。IMAP 迁移复制邮件，不替代完整 MX 或应用切换。
DMARC 对齐最终清单
为每个正常发信源验证至少一项通过且对齐的 SPF 或 DKIM，配置两者可能有运维价值。转发和后续限制仍需独立测试和持续观察。
- 列出所有发信系统：邮箱主机、CRM、账单、客服、商店、表单和营销。
- 确认每项使用的可见 From 域名。
- 检查 SPF 通过与实际 Return-Path 的对齐。
- 配置对齐 DKIM 并测试真实签名。
- 没有明确且经过测试的替代需求时，使用
aspf=r和adkim=r。 - 发送测试，检查接收方可信的 Authentication-Results。
- 尚未验证的发信先使用
p=none；本地过滤仍适用，报告不保证提供。 - 核对清单、分析失败、检查日志并测试低频关键流程后，再考虑限制。
DMARC 对齐把成功认证与可见发件域名关联，但不能单独区分安全内容与欺骗，也不保证投递。需要集中多域名管理时，可比较 TrekMail，同时核对固定费用套餐的资源与功能限制。
