指南身份验证

SPF 和 DKIM 都通过，DMARC 却失败

两项检查都显示 pass，DMARC 却仍然显示 fail。原因是有一个域名与你的 From 地址不一致。发一封测试邮件就能看出是哪一个，而解决办法是在实际发信的那一方改一项设置。

更新于 2026年10月5日阅读约 9 分钟

要点速览

只有当 SPF 或 DKIM 是为你 From 地址里的域名通过时，DMARC 才会通过。为服务商的域名通过不算数。
在 Gmail 中用 Show original 打开一封已发送的邮件，比较 Authentication-Results 头里的 smtp.mailfrom、header.i 和 header.from。
先解决 DKIM：在每一个替你发信的服务上，开启用你自己的域名签名。DKIM 签名经得起转发，SPF 不行。
默认情况下，子域名就算足够接近。如果你的 DMARC 记录里有 adkim=s 或 aspf=s，那就不算。
预热修不好对齐问题。预热邮件是通过你的邮箱发出的，邮箱失败，它们也跟着失败。

DMARC 问的不是 SPF 和 DKIM 有没有通过。它问的是，其中有没有一项是为你 From 地址里的域名通过的。如果 SPF 是为服务商的退信域名通过的，DKIM 是为服务商的签名域名通过的，那么两行都写着“pass”，DMARC 却仍然是“fail”。解决办法在发信一方：让它用你的域名签名，或者使用你域名下的退信地址。两者做到一项就够。

这种匹配有个专门的词，叫对齐（alignment）。它是 DMARC 中 DNS 检测工具看不到的部分。你的邮件是否对齐，只有在一封真正发出的邮件里才看得出来。本页教你怎么读这样一封邮件。

每封邮件都带着三个域名

一封邮件最多会在三个地方带上你的域名。每项检查看的地方都不一样。

码头上并排放着一面带信封徽记的海军蓝三角旗、一只挂着黄铜标牌的邮袋和一封盖着火漆印的信；火漆印与三角旗上的徽记相同，标牌则不同 — 三角旗是 From 行，邮袋上的标牌是 Return-Path，火漆印是 DKIM 签名。DMARC 要求标牌或火漆印与三角旗一致。

位置	又叫	谁来看
读者看到的 From 行	Header From、`header.from`	DMARC。它是衡量另外两项的标尺。
Return-Path	信封发件人、MAIL FROM、退信地址、`smtp.mailfrom`	SPF。它检查发信服务器是否有权使用这个域名。
DKIM-Signature 头中的 `d=` 值	签名域名、`header.d` 或 `header.i`	DKIM。它检查这个域名的签名是否有效。

SPF（RFC 7208）和 DKIM（RFC 6376）各自只回答一个很窄的问题，而两个问题都不涉及你的 From 行。一家邮件营销服务可以让 SPF 为它自己的退信域名通过，用它自己的密钥签名，而邮件仍然可以自称来自你。DMARC 堵上了这个缺口。2026 年 5 月起成为 DMARC 标准的 RFC 9989 规定，只有当结果背后的域名与 From 域名一致时，这个结果才被采纳，并用一句话说明了对 DKIM 这样要求的理由：

DMARC 要求对经 DKIM 验证的标识符进行标识符对齐，因为一封邮件可以带有任何域名的有效签名，哪怕是不法分子使用的域名。

SPF 也是同样的道理，因为任何人都可以为自己拥有的域名发布 SPF 记录。所以规则是：SPF 通过并且其域名对齐，或者 DKIM 通过并且其域名对齐，DMARC 才通过。

用一封真实邮件找出不一致的地方

你需要一封按平时发信方式发出的邮件，以及一个用来接收的 Gmail 地址。

从有问题的邮箱或工具，向一个你能打开的 Gmail 地址发一封邮件。
在电脑上用 Gmail 打开它。点击 Reply（回复）旁边的 More（更多），再点 Show original（显示原始邮件）。Google 在用完整邮件头追踪一封邮件中介绍了同样的步骤。
找到 Authentication-Results 头，收件服务器在其中记下各项检查的结果（RFC 8601）。比较三个值：smtp.mailfrom= 后面的域名、header.i=@ 后面的域名（有些收件方写作 header.d=），以及 header.from= 后面的域名。如何读邮件头会一步步讲解这一行。

下面是一封 SPF 和 DKIM 通过、DMARC 失败的邮件的典型样子。邮件头做了删节，用的是示例域名：

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

从下往上读。From 域名是 example.com。SPF 通过了，但针对的是 send.vendor-mail.example。DKIM 通过了，但签名属于 vendor-mail.example。两个都不是 example.com，所以没有任何东西为 From 行里的名字作保。

把该服务设置成用你的域名签名之后，同一封邮件是这样的：

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF 仍然指向供应商。这没问题。DKIM 现在匹配了，而 DMARC 只需要一项对齐并通过。

多接近才算够：宽松与严格

两个域名不必完全相同。默认是宽松对齐：两者属于同一个注册域名就够了，标准把它称为组织域名（organizational domain）。严格对齐则要求完全一致。你可以在 DMARC 记录中用 adkim（针对 DKIM）和 aspf（针对 SPF）两个标签来选择。

SPF 或 DKIM 通过时对应的域名	From 域名	宽松（默认）	严格
`example.com`	`example.com`	对齐	对齐
`mail.example.com`	`example.com`	对齐	不对齐
`example.com`	`news.example.com`	对齐	不对齐
`vendor-mail.example`	`example.com`	不对齐	不对齐

标准指出，“几乎所有域名所有者都发现，宽松对齐足以满足他们的需要”。但还是要检查一下你自己的记录。Google 的设置 DMARC 页面顶部的示例记录以 adkim=s; aspf=s 结尾，所以从那里照抄的记录是严格的。如果你的记录带有这两个标签，而又有工具从子域名发信，就把它们删掉。Google 自己也在该页面上警告，严格对齐“可能导致来自关联子域名的邮件被拒收或被归入垃圾邮件”。

不一致通常从哪里来

从自己的服务器发信的服务

邮件营销平台、CRM、开票工具和客服系统，都是从它们自己的基础设施替你发信。在你接入自己的域名之前，它们通常使用自己域名下的退信地址，并用自己的密钥签名。Amazon 的文档直白地说明了为什么这里很少有 SPF 对齐：Return-Path“用于退信和投诉，而服务商（SES）要用自己拥有的地址来跟踪它们”（Amazon SES）。解决这个问题的设置在每个服务里叫法都不同，而最后都落到你这边的几条 DNS 记录上。

服务	接入你的域名之前	要找的设置
Twilio SendGrid	邮件显示为“via sendgrid.net”（经由 sendgrid.net）发送。	Domain authentication（域名身份验证）：为退信子域名和两个 DKIM 密钥添加 CNAME 记录。
Amazon SES	Return-Path 是 `amazonses.com` 的一个子域名。	签名用 Easy DKIM，SPF 用自定义 MAIL FROM 域名（custom MAIL FROM domain）。
Mailchimp	域名已验证归属（verified），但尚未完成身份验证（authenticated）。	Email domain authentication（邮件域名身份验证）：两条用于 DKIM 的 CNAME 记录。

以上是各供应商截至 2026 年 10 月的自述。其他服务的做法大同小异。可以在它们的帮助中搜索“authenticate domain”“custom DKIM”或“branded sending domain”。

邮件服务商用它自己的域名签名，或者根本不签名

如果邮箱建在你自己的域名上，Return-Path 通常就是你自己的地址，所以只要你的 SPF 记录列出了服务商，SPF 就对齐了。看 smtp.mailfrom= 后面的值就知道。需要动手打开开关的是 DKIM。

Google Workspace。在你为自己的域名开启 DKIM 之前，Google 一直是用它自己的某个域名签名。Google 帮助页面的早期版本写道，这时 Gmail 会“用这个默认的 DKIM 域名密钥签名：d=*.gappssmtp.com”。现在的页面不再提这个域名，所以请检查你自己的邮件头：header.i 以 gappssmtp.com 结尾，就说明你的密钥还没有启用。在管理控制台（Admin console）中依次进入 Apps、Google Workspace、Gmail、Authenticate email（验证电子邮件），生成密钥，添加它显示的 TXT 记录，然后点击 Start authentication（开始验证）（设置 DKIM）。
Microsoft 365。Microsoft 在 2026 年 8 月更新的文档写道：“目前，自定义域名的外发邮件不会进行 DKIM 签名”。你需要发布两条 CNAME 记录，并在 Defender 门户中启用签名（如何为自定义域名的邮件使用 DKIM）。

为 DKIM 密钥添加的记录总是位于 _domainkey 之下，名称由服务商决定。Google Workspace 的记录是这样的，密钥做了删节：

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

连接到你的邮箱并通过它发信的工具，不会加上自己的签名。这类工具发出的邮件，和你手写的邮件看起来一模一样，所以要在邮件服务商那里解决，而不是在工具里。

邮件被转发了

收件人自动转发你的邮件时，邮件是从一台你的 SPF 记录没有列出的服务器到达的。SPF 要么失败，要么是为转发方的域名通过。只要没人改动邮件，DKIM 签名就能完好无损地走完这一程。会加页脚或主题标记的邮件列表，则会把签名也破坏掉。这一点你从自己这边修不了。Google 的发件人常见问题说，对 Gmail 而言，“转发的邮件或邮件列表的邮件不要求 DMARC 对齐”。这正是要让 DKIM 对齐、不能只靠 SPF 的原因。

一封封了口的信从一艘邮船递到另一艘邮船；每艘船都有自己的邮袋和标牌，信上的火漆印完好无损 — 转发会换掉邮袋和上面的标牌。信上的火漆印保持完好。

那不是你的邮件

如果你的 DMARC 报告显示，有失败来自你从没用过的服务器，那可能是有人在用你的地址发信。这些邮件本来就该失败。什么都不用修，它们反而是你日后收紧策略的理由。

先解决 DKIM，再解决 SPF

任何一项都能让 DMARC 通过。DKIM 是更值得拥有的那一项，因为它随邮件一起走。M3AAWG 的最佳实践把它定成了一条规则：“所有外发邮件都应使用与 RFC5322.From 头的域名对齐的 DKIM 密钥签名。”RFC 9989 建议两者都用。

列出所有以你的域名发信的东西。邮箱、邮件营销工具、CRM、发票、网站上的联系表单。你漏掉的那些，DMARC 报告会点出来。
逐个测试，用上面的邮件头检查，记下两个域名里哪一个不是你的。
开启用你的域名签名，凡是 header.i 显示别的名字的地方都要开，并发布服务给你的记录。如果你的 DNS 托管商支持，就选 2048 位的密钥。Gmail 要求至少 1024 位，建议 2048 位。
设置自定义退信域名，只要服务提供这个选项，就设在 bounce.example.com 这样的子域名上。这样 SPF 也对齐了。
再发一次测试邮件，看有没有 dmarc=pass。DNS 更改可能需要一段时间才生效。Google 给新 DKIM 密钥开始生效留出的时间最长为 48 小时。

把供应商加进你自己的记录是没用的。如果 Return-Path 在供应商的域名上，那么在你的 SPF 记录里为供应商加一条 include: 不会改变任何事，因为 SPF 查的是那个域名的记录，不是你的。DMARC 记录也无法列出受信任的第三方。标准说，这方面“没有普遍接受的机制”。

如果邮件头显示 dmarc=pass，邮件却仍然进垃圾邮件夹，原因就不再是身份验证了。SPF、DKIM 和 DMARC 都通过了，邮件还是进垃圾邮件夹从这里接着讲。

策略还是 p=none 时，DMARC 失败的代价

使用 p=none，就是请收件方在失败时不采取任何行动，所以不会有邮件因为你的策略被拒收。但它仍然在两方面对你不利。

大量发信方规则。Gmail、Yahoo 和 Outlook.com 都要求大量发信方的邮件对齐，对 Gmail 和 Outlook.com 来说，是指每天 5,000 封起。Google 的发件人常见问题列出了临时错误 4.7.32，针对的是 From 头“与经过验证的 SPF 或 DKIM 组织域名都不对齐”的邮件，并指出后果是“临时或永久性失败代码，或被归入垃圾邮件夹”。
它挡住了下一步。一旦你改用 p=quarantine 或 p=reject，你自己每一封未对齐的邮件都将被当作垃圾邮件或被拒收。在 Gmail，退信写的是“Unauthenticated email from domain-name is not accepted due to domain's DMARC policy”，错误 5.7.26（排查 DMARC 问题）。

如果你根本没有 DMARC 记录，请从该添加的那条记录开始。它还会开启报告，让你一次看到所有发信服务的对齐情况。

预热在这里能做什么，不能做什么

预热修不好对齐问题。WarmupBay 连接到你的邮箱并从它发信，所以它的预热邮件由你的服务商发送和签名，和你自己写的邮件完全一样。如果你的邮箱通不过 DMARC，它们也跟着通不过。先把记录修好。

WarmupBay 能帮上忙的是之前和之后的部分。连接邮箱时，它会检查该域名的 SPF、DKIM 和 DMARC；如果 72 小时后这些记录仍然缺失，它会停止预热。记录到位之后，你的邮箱每天与共享池中的其他邮箱交换几封邮件，仪表盘会显示它们落在了哪里：收件箱、Gmail 标签页还是垃圾邮件，Google 和其他服务商分开显示。它不测试来自你的邮件营销工具或 CRM 的邮件，因为那些邮件从不经过你的邮箱；它目前也还无法连接 Microsoft 365 或 Outlook.com 邮箱。每天 10 封预热邮件是免费的。等邮件头显示 dmarc=pass 之后，就连接你的邮箱吧。

常见问题

SPF 通过并且对齐，DKIM 没有对齐。这样够吗？

对 DMARC 来说，够了。有一项对齐并通过就够。但收件人一旦转发你的邮件，这就不够了，因为那时 SPF 不再匹配。Google 还在发件人常见问题中写道，SPF 和 DKIM 同时对齐今后很可能成为要求，所以无论如何都应为你的域名设置 DKIM。

为什么 DMARC 对一些收件人失败，对另一些却通过？

因为邮件到达他们那里的路径不同，或者发信的服务不同。收件人把邮件转发到另一个邮箱，或者邮件经过邮件列表，都会改变 SPF 看到的内容，有时也会改变 DKIM 看到的内容。也可能是你的几个发信服务里，有一个还没设置好。汇总报告按发信服务器列出结果，能看出是哪种情况。

Reply-To 地址会影响 DMARC 吗？

不会。DMARC 只使用 From 头里的域名。Reply-To 地址、显示名称和 Sender 头都不在检查范围内。

不打开邮件头，怎么看出对齐问题？

看 DMARC 汇总报告。每条记录都有一个 policy_evaluated 块，里面有 dkim 和 spf 两个结果，它们是经过对齐检验之后的结果。下面的 auth_results 块显示原始结果以及这些结果对应的域名。原始结果是 pass，评估结果却是 fail，正是本页讲的情况。在 DMARC 记录中加上 rua 地址，就能收到这些报告。

邮件头里写的是 dkim=fail 或 dkim=neutral。这是同一个问题吗？

不是。那说明签名本身没有通过验证，是另一种故障。如果文字是 body hash did not verify，Google 的故障排查页面给出了原因：邮件在签名之后被改动过，比如被某个网关加上了页脚。对齐问题指的是签名有效，但属于另一个域名。

每个替我发信的服务都需要单独的 DKIM 密钥吗？

实际上是的。每个服务用自己的密钥签名，并以自己的选择器名称把密钥发布在你域名的 _domainkey 之下，所以多个密钥可以并存，互不冲突。这和 SPF 不同，一个域名只能有一条 SPF 记录。