指南身份验证

No DMARC record found：你的域名缺的那一行记录

你的域名还没有 DMARC 记录。这里告诉你该添加哪一行、它放在 DNS 的什么位置，以及添加之后你的邮件会有什么变化。内容已对照 RFC 9989 以及 Gmail、Yahoo 和 Outlook.com 的发信方规则核对。

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

要点速览

这条提示的意思是 _dmarc.yourdomain.com 上没有 TXT 记录。你的邮件服务器没有坏。
添加一条 TXT 记录，主机记录为 _dmarc，记录值为 v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com。使用 p=none，邮件的投递和原来完全一样。
Gmail、Yahoo 和 Outlook.com 只要求大量发信方设置这条记录。但还是加上：Google 按整个域名计数，大量发信方的身份一旦确定就不会撤销，而且只有记录存在之后才会开始收到报告。
如果检测工具仍然什么都找不到，就检查是否改错了 DNS 服务商、主机名是否重复，或者是否有两条 DMARC 记录。两条记录会互相作废。
标准在 2026 年 5 月随 RFC 9989 发生了变化：pct 没有了，新增了 t 和 np。截至 2026 年 10 月，Google 的帮助仍在介绍 pct。

“No DMARC record found”（未找到 DMARC 记录）的意思是，某个检测工具向 DNS 查询 _dmarc.yourdomain.com 上的 TXT 记录，却什么也没查到。你的邮件服务器没有任何故障。解决办法是添加一条 TXT 记录，主机记录为 _dmarc，记录值为 v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com。使用 p=none，你的邮件会和以前完全一样地投递。你只是告诉收件方你参与了 DMARC，并且开始收到报告。

DMARC 是三条邮件记录中的第三条，另外两条是 SPF 和 DKIM。SPF 列出可以为你的域名发信的服务器。DKIM 为每封邮件签名。DMARC 告诉收件方，当这两者都不能为你 From 地址里的域名作保时该怎么办，以及把每日汇总发到哪里。自 2026 年 5 月起，它由 RFC 9989 定义，取代了较早的 RFC 7489。许多指南讲的仍是旧版本，截至 2026 年 10 月，Google 的帮助页面也是如此。

要添加的记录

登录管理你域名 DNS 的地方。那是你的域名服务器（nameserver）所指向的公司，不一定是你购买域名的那一家。用以下内容添加一条新记录：

字段	填写内容
记录类型	`TXT`
主机记录或名称	`_dmarc`
记录值或内容	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`
TTL	保持默认

写成区域文件（zone file）里的一行，完整的记录是这样的：

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

把 example.com 换成你自己的域名。三个部分的作用如下：

v=DMARC1 表明这一行是 DMARC 记录。它必须放在最前面，DMARC1 要大写。否则，收件方会忽略整条记录。
p=none 是策略：照你原本的方式处理我的邮件。不会有邮件因为这条记录被拦截或被移到垃圾邮件夹。
rua=mailto:… 是接收每日报告的地址。发布记录之前，先创建这个地址，或者一个会转发给你的别名。

Google 在设置 DMARC 中列出了同样的三个字段。它还要求在添加 DMARC 之前，SPF 和 DKIM 已经正常运行 48 小时。如果你的检测工具也指出了这两项的问题，先把它们修好。

怎样确认已经生效

自己去问 DNS。在 macOS 或 Linux 上，打开终端使用 dig。在 Windows 上，使用 nslookup。

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

如果记录已经生效，这一行会带着引号返回。这是 Google 自己的域名在 2026 年 10 月 5 日的回答：

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

返回为空，说明记录还不存在，或者不在收件方查询的位置。等你自己的查询能显示出这一行，再用给出那条提示的检测工具重新检测一次。例如，MXToolbox 把这个问题表述为“No DMARC Record found”，并解释说“你的域名没有已发布的 DMARC 记录”。

DMARC 记录的每个部分是什么意思

一条记录是一串用分号隔开的 tag=value（标签=值）对。按标准，只有 v 是必需的，而且必须排在第一。把 p 放在第二位：Google 的帮助写明“v 和 p 标签必须列在最前面”，旧标准也要求同样的顺序。以下是 RFC 9989 第 4.7 节中的标签：

标签	含义	如果省略
`v=DMARC1`	这是一条 DMARC 记录。	记录会被忽略。
`p`	对未通过的邮件怎么处理：`none`、`quarantine` 或 `reject`。	如果有有效的 `rua`，按 `none` 处理。否则记录不会被应用。务必设置。
`rua`	每日汇总报告发到哪里。多个地址用逗号隔开。	不会发送报告。
`sp`	为实际存在的子域名（如 `news.example.com`）单独设定的策略。	子域名沿用 `p` 中的策略。
`np`	为不存在的子域名单独设定的策略。由 RFC 9989 新增。	它们沿用 `sp`，没有则沿用 `p`。
`adkim`、`aspf`	DKIM 和 SPF 的域名必须与你的 From 域名匹配到什么程度：`r` 表示宽松，`s` 表示严格。	宽松。
`t`	`t=y` 把更严格的策略标记为测试：请收件方降一级执行。由 RFC 9989 新增。	`t=n`，策略按字面执行。
`ruf`、`fo`	关于单封未通过邮件的报告。	不会发送。Gmail 不支持 `ruf`，Outlook.com 也没有发送这类报告的计划。

较早的记录常以 pct=100 结尾。这个标签原本是为了让策略只应用于一部分未通过的邮件。RFC 9989 把它连同 rf 和 ri 一起删除了，并给出了理由：

运营经验表明，“pct”标签通常得不到准确的应用，除非指定的值是 0 或 100（默认值）；而在其他取值下，各种实现之间的偏差大小相差悬殊。

收件方必须忽略自己不认识的标签，所以旧的 pct=100 没有害处。2026 年 10 月 5 日，yahoo.com 和 microsoft.com 的记录里仍带着它，Google 的帮助页面也仍然建议用 pct 逐步推行。在新记录里，就不要写它了。

每天只发几封邮件，还需要 DMARC 吗？

按照几家大型邮件服务商公布的规则，一旦你大量发信，DMARC 记录就是必需的。低于这个量，它只是一项建议。

收件方	所有发信方	大量发信方
Gmail 个人账号	SPF 或 DKIM	每天 5,000 封起：SPF、DKIM 和一条 DMARC 记录。策略“可以设为 none”。From 域名必须与 SPF 域名或 DKIM 域名一致。
Yahoo	“至少实施 SPF 或 DKIM”	SPF 和 DKIM，外加“一条有效的 DMARC 策略，至少为 p=none”。Yahoo 的页面没有给出“大量”的具体数字。
Outlook.com、Hotmail、Live	没有明文要求	每天发送超过 5,000 封邮件的域名：SPF、DKIM，以及策略至少为 `p=none` 的 DMARC。

出处是 Google 的电子邮件发件人指南、Yahoo 的发件人最佳实践和 Microsoft 针对大量发信方的公告，均截至 2026 年 10 月。如果你从一个邮箱每天发三十封邮件，它们都不要求你有这条记录。但仍有三个理由现在就加上。

阈值按域名计算，而且不会清零。Google 把来自同一个主域名（包括子域名）、发往个人 Gmail 账号的所有邮件加在一起。它的发件人常见问题说：“只要有一次达到上述标准，发信方就会被永久视为大量发信方。”
Google 和 Yahoo 都建议所有人设置。Google 写道，“我们建议你始终为自己的域名设置 SPF、DKIM 和 DMARC”。Yahoo 则“强烈敦促所有发信方为每一个发信的域名发布 DMARC 策略”。
没有这条记录，你就收不到报告。靠这些报告，你才能看到哪些服务器在用你的域名作为 From 发信，无论是你自己的工具还是陌生人。

对大量发信方来说，缺少这条记录是有后果的。Google 的发件人常见问题为此列出了临时错误 4.7.31：“发信域名没有 DMARC 记录，或者 DMARC 记录没有指定 DMARC 策略”。同一页面说，自 2025 年 11 月起，不符合要求的邮件会面临“临时和永久性的拒收”。

记录加了，检测工具还是什么都找不到？

那通常是下面某个原因。用上面的 dig 查询逐一排查。

你改的不是正确位置的 DNS。如果你的域名服务器在另一家公司，而不在域名注册商那里，那么在注册商处填写的记录永远不会被查询。dig +short NS example.com 会显示是谁在为你的域名应答。
主机记录不对。记录放在了 example.com 本身上，或者像上面说的那样放在了重复的名称上。收件方只查询 _dmarc.example.com。
有两条 DMARC 记录。标准在这一点上很严格：“如果对同一个目标返回了多条 DMARC 策略记录，它们会被全部丢弃。”把它们合并成一条。两个报告地址放进同一个 rua，用逗号隔开。
第一个标签不是一字不差的 v=DMARC1。小写、DMARC 1 这样的笔误，或者 p= 排在它前面，都会让记录无效。
记录类型不是 TXT，或者记录值是从文档里连同弯引号一起粘贴过来的。把记录值作为纯文本输入，不要加引号，除非你的 DNS 服务商的帮助要求加。
旧的应答还在缓存里。解析器会把“没有这条记录”记住一段时间。在查询后面加上你自己某台域名服务器的名称，直接向它查询，例如 dig +short TXT _dmarc.example.com @ns1.example.net。如果那里能显示出记录，检测工具随后也会跟上。

报告发到哪里，拿它们做什么

每一个收到过以你的域名作为 From 的邮件的收件方，都会向 rua 地址发送报告。按 Google 的页面关于 DMARC 报告的说法，它们“通常每天通过电子邮件发送一次”。报告是一个 XML 文件，通常经过压缩，作为邮件附件发送。RFC 9990 说明了它的格式。

三只海鸥把卷起来的小纸条送到港务办公室墙上的木制信件架 — 每一个收到过以你名义发出的邮件的收件方，每天都会向 `rua` 中的地址发送一份简短的报告。

Google 提醒说，大型组织“每天可能收到数百甚至数千份报告”，并建议使用群组或专用邮箱。数量取决于你发多少、发往多少个域名，所以一两个邮箱产生的报告要少得多。一个 dmarc@ 这样的别名，配上一条把报告过滤到单独文件夹的规则，就够用了。

这个地址应当与记录在同一个域名上。如果你想把报告发到别处，另一个域名必须发布一条自己的记录表示同意。没有它，收件方必须忽略这个地址（RFC 9990 第 4 节）。

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

这就是免费的 Gmail 地址不能用作报告地址的原因：我们在 2026 年 10 月 5 日检查时，gmail.com 没有发布这样的记录。

在文件里，每个 record 块代表一台发信服务器：它的 IP 地址、邮件数量，以及 policy_evaluated 下 DKIM 和 SPF 是否为你的域名通过。你要找两样东西。你认识的服务器如果显示 fail，就需要修复，SPF 和 DKIM 都通过，DMARC 却失败说明了怎么修。你不认识的服务器，要么是你忘掉的某个工具，要么是有人在冒用你的名义。

p=none 之后：什么时候收紧策略

p=none 是一种监测模式。它满足邮件服务商要求的最低标准，但挡不住任何人伪造你的地址。只有 p=quarantine（请收件方把未通过的邮件视为可疑）和 p=reject（请收件方拒收）才能做到。

收紧之前，你邮件的每一个合法来源都必须通过。RFC 9989 说，在尝试强制执行之前，这类缺口“必须先行解决”，并且视你发信的频率而定，“可能需要许多个月”的报告才能确定。Google 的推行页面则认为一周的报告“通常就够了”。如果只有一个邮箱和一两个工具，你更接近 Google 的数字，但还是留出几周时间，让每月一次的发票批量发送和联系表单也出现在报告里。

至于这一步具体怎么走，两个来源说法不同。Google 仍然建议使用 p=quarantine; pct=5，再逐步提高数字。标准已经去掉了 pct，改为提供这种写法：

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y 请收件方暂时把未通过的邮件降一级处理，也就是按 none 处理。报告一直干净的话，就去掉 t=y。要注意，不认识这个标签的收件方会忽略它，完整执行 quarantine；而且截至 2026 年 10 月，Google 的页面没有提到 t。如果更严格的策略会波及你暂时修不好的邮件，就继续用 p=none。

WarmupBay 在哪里派上用场

连接邮箱时，WarmupBay 会检查其域名的 SPF、DKIM 和 DMARC。如果缺少 DMARC 记录，它会给你一条现成的，供你复制。你仍然可以开始预热。如果 72 小时后记录仍然缺失，预热会停止。

WarmupBay 不能替你添加记录，因为 DNS 是你自己的；它也不收集或阅读 DMARC 报告。它做的是记录就位之后的那一步：你的邮箱每天与共享池中的其他邮箱交换几封邮件，从三封开始，每天增加一封，让发送活动逐步增长。每天 10 封邮件是免费的。看看检查和预热包含哪些内容，或者等记录就位后连接你的邮箱。

常见问题

example.com 上的 DMARC 记录也覆盖 news.example.com 这样的子域名吗？

覆盖。收件方先查询 _dmarc.news.example.com 上的记录。如果没有，就退回到组织域名 example.com 的记录。应用于子域名的策略，如果你设置了 sp 就用 sp 里的，否则用 p 里的。

可以只发布 v=DMARC1; p=none，不带 rua 地址吗？

可以。这是一条有效的记录，也算作已发布策略。但你收不到报告，也就看不到自己的邮件是否通过、还有谁在用你的域名。Yahoo 说强烈建议设置一个可用的 rua 地址，Google 则建议始终加上。

只用来做外联的第二个域名，也需要 DMARC 记录吗？

需要。收件方查的是每封邮件 From 地址里的域名，所以主域名上的记录覆盖不到另一个域名。在第二个域名上使用同样的一行。如果它的报告要发到主域名下的地址，主域名就必须发布“报告发到哪里”一节所说的授权记录。

从不发邮件的域名应该发布什么？

严格的一对。对于从不发信的域名，M3AAWG 建议使用 SPF 记录 v=spf1 -all 和 p=reject 的 DMARC 记录，这样就没人能把它们用在 From 地址里。对 DMARC 来说，就是在 _dmarc 下放一行 v=DMARC1; p=reject。

对我的邮件来说，p=none 比 p=quarantine 或 p=reject 差吗？

Gmail、Yahoo 和 Outlook.com 公布的发信方规则要求至少 p=none，没有要求更严格的。策略决定的是未通过 DMARC 的邮件会怎样，其中包括冒用你名义的伪造邮件。有一项功能要求更高：BIMI，也就是显示在你邮件旁边的徽标，按 Google 帮助的说法需要 quarantine 或 reject。