合法邮件未通过 DMARC 时，原因几乎总是以下几种：SPF 或 DKIM 结果缺失或未对齐、转发破坏了 SPF、或第三方发件方从未针对你的域名完成认证。修复方法很少是放宽策略，而是找到发送源并正确认证它。
如何知道哪些邮件失败了？
从报告入手，因为报告会准确告诉你哪个发送源失败了以及原因。聚合报告按发送 IP 拆分邮件，并显示每个来源的 SPF 和 DKIM 结果及对齐情况。某个来源原始检查显示 pass，但对齐后显示 fail，这是最常见的模式，它直接指向问题所在。如果你还不熟悉如何阅读报告，如何阅读 DMARC 报告会逐一讲解各个字段。
一旦你能看到哪个来源在失败，原因几乎总是下面其中之一。
原因 1：对齐缺口
这是最常见的原因。SPF 或 DKIM 通过了，但通过的域名与你可见的 From 地址不匹配，因此 DMARC 将其视为失败。这通常意味着发送服务使用的是自己的域名而非你的域名进行认证。
修复方法是让该服务实现对齐。对于 SPF，这意味着使用你自己域名上的 Return-Path（退信域名）发送邮件。对于 DKIM，这意味着使用发布在你域名上的密钥签名，使签名域名与你的 From 地址匹配。大多数邮件平台都支持自定义域名来实现这一点：你发布一两条 CNAME 记录，对齐就自动完成了。相关概念在 DMARC 的工作原理中有详细解释。
原因 2：转发
转发会悄然破坏 SPF。邮件被转发时，转发服务器将其继续发送，而该服务器不在你的 SPF 记录中，因此 SPF 检查在最终目的地失败。你对其他人的转发规则无能为力。
好消息是 DKIM 通常能经受住转发，因为签名随邮件一起传递。这正是 DMARC 只需 SPF 或 DKIM 其中之一通过即可的原因：只要你的 DKIM 设置正确且对齐，转发的邮件仍然可以通过 DMARC，即使 SPF 失败也没关系。应对转发失败的实际做法是确保 DKIM 正确设置并对齐，然后不必再担心转发邮件中 SPF 列的结果。
原因 3：你遗忘的第三方发件方
几乎每个组织通过的发送服务都比它记得的要多：CRM、工单系统、开票工具、营销平台、问卷服务。每一个都需要针对你的域名完成认证，否则其邮件将无法通过 DMARC。报告中出现的新来源通常就是这些服务。
逐一处理它们。对于每个合法服务，按照其说明在你的域名上设置 SPF 和 DKIM（常见的措辞是 "authenticate your domain" 或 "use a custom sending domain"）。然后在下次报告中确认该来源已变为通过且对齐。保持一份持续更新的清单，因为随着团队采用新工具，这部分会不断变化。
原因 4：SPF 过于宽泛或超出查询限制
两个 SPF 特有的陷阱。如果你的 SPF 记录超过了 10 次 DNS 查询（规范中的硬性限制），它可能直接失败，连带拖垮本来正常的邮件。而过于宽松的记录可能会放行你并不打算授权的邮件。审核你的 SPF 记录，在接近限制时合并 include: 条目，并移除不再使用的服务。
不应该做的事
不要通过将策略降回 p=none 来修复失败，然后就放在那里不管。这样做虽然报告不再烦你了，但也不再保护任何人，你原本要解决的伪造问题又彻底暴露了。将失败视为需要认证发送源的信号，而不是退缩的理由。合理的降级方式是将 p= 回退一个等级并持续查看报告，什么是 DMARC 策略对此有详细说明。
整合起来
查看报告，找到失败的来源，判断它是否合法，然后要么认证它，要么确认这是你正在拦截的伪造邮件。逐一处理，直到每个真实发件方都通过并对齐，这样你的策略就可以安全地保持在 reject。如果你还在初始设置阶段，如何设置 DMARC 介绍了基础步骤，Bird 的认证指南包含域名相关的记录。大多数失败看起来很严重，但一旦你找到了对应的发送源，往往只需五分钟的对齐修复即可解决。