在任意 DNS 服务商发布 SPF、DKIM 与 DMARC 记录

SPF、DKIM 和 DMARC 说到底只是几条 DNS 记录——但发布它们绊倒的人比邮件认证流程里任何一步都多，因为每个 DNS 面板都在用略微不同的措辞索要同样的三样东西。在 Cloudflare 里完美生效的记录，搬进 Route 53 可能悄无声息地变成废数据：一个面板要的是主机名前缀，另一个要的却是完整域名。

本指南先给通用方法论——三个字段、TTL 与主机名写法陷阱——再给主流服务商的速查表，最后是用验证工具证明记录确实生效的步骤。至于各协议做什么、按什么顺序启用，先读 邮件认证指南。

你需要准备什么

• 真正在为你的域名提供解析的那个 DNS 面板的权限——动手之前先确认 NS 指向哪里。
• 邮件服务商给出的记录值：SPF 的 include、DKIM 的 selector 与公钥、DMARC 策略。
• 五分钟时间和 TXT 查询工具，用于验证。

DNS 记录的通用解剖

无论面板把字段叫什么，它要的都是同样三样东西：

• 类型——SPF 与 DMARC 永远用 TXT；DKIM 视服务商说明用 TXT 或 CNAME。
• 主机名（也叫 Name、Host、Record name）——记录挂在哪台"主机"下。
• 值（也叫 Content、Data、Answer）——记录内容，原样粘贴，一字不改。

主机名字段是新手翻车最集中的地方。三条记录住在三个不同的位置：

SPF:     yourdomain.com                        (域名根)
DKIM:    sel2026._domainkey.yourdomain.com     (服务商指定的 selector)
DMARC:   _dmarc.yourdomain.com                 (固定前缀 _dmarc)

大坑：前缀写法 vs 完整域名写法。有的面板只要域名之前的那一段——根记录填 @、DMARC 填 _dmarc、DKIM 填 sel2026._domainkey——然后自动补上 yourdomain.com；有的面板却要你填完整名称（有时还要求带结尾的点）。如果你把完整域名填进了自动补域的面板，就会造出 yourdomain.com.yourdomain.com——一条合法却永远不会被任何人查询的记录。这是邮件配置里最经典的 DNS 错误，而且失败得悄无声息：面板显示保存成功，邮件认证失败。

TTL 与传播。TTL 是解析器允许缓存你记录的时长。多数面板默认 300–3600 秒；配置期间选短的（300 就行），改动传播得快。一般几分钟到几小时可见，最坏情况按 24–48 小时预留。

主流服务商速查表

建站平台要多提醒一句：如果你的建站工具是用"指向"（在注册商处改 A 记录）而非改 NS 接入域名的，它的 DNS 面板只是摆设——记录必须加在 NS 实际指向的地方。

发布三条记录

1. SPF——域名根下的一条 TXT。所有来源合并进唯一一条、以 ~all 结尾；出现两条 v=spf1 就是永久失败。语法与查询次数用 SPF 检测验证。
2. DKIM——selector 主机名下的一条 TXT（或 CNAME），服务商指定写哪种。值是一长串公钥，原样粘贴。用 DKIM 检测确认可解析。
3. DMARC——_dmarc 前缀下的一条 TXT，从 p=none 加 rua 报告地址起步。用 DMARC 生成器生成，再用 DMARC 检测复核。

先验证，再往上盖楼

别信面板的"保存成功"，要信公共 DNS。用 TXT 查询直接查每条记录：SPF 查域名根、DKIM 查 selector 主机名、DMARC 查 _dmarc.yourdomain.com。工具返回什么，接收方邮件服务器看到的就是什么。传播完成后查询仍为空，说明记录挂错了主机名——优先排查"域名叠域名"错误。想一次复查全套，用 邮件健康检查。

按平台查阅的详细步骤

上面的通用方法适用于任何服务商。如果你的邮件跑在某个具体平台上，下面这些文章给的是该平台的真实控制台路径、它要求的 include 值，以及它生成的记录名：

• 邮箱服务商：Google Workspace、Microsoft 365、Zoho Mail、Fastmail、阿里云邮箱、腾讯云 SES。
• 发信平台：SendGrid、Mailgun、Amazon SES、Postmark、Brevo、Mailchimp、HubSpot、Klaviyo、Salesforce Marketing Cloud。
• 自建与面板：Postfix、Roundcube、cPanel 与 Plesk。
• DNS 层本身：Cloudflare DNS 上的邮件记录，以及 在 Cloudflare 上做 SPF 扁平化。

记录生效后还有两个相邻话题值得一读：MTA-STS 与 TLS-RPT（传输层安全）和 BIMI（在收件箱显示认证徽标）。

常见错误

• 选了叫"SPF"的记录类型。部分面板仍保留遗留的 SPF 类型，它已被弃用——接收方只查 TXT。一律用 TXT。
• 两条 SPF 记录。为新服务又加一条 v=spf1 会让整个域名的 SPF 全线失败。新的 include 要合并进已有记录。
• 把完整域名填进前缀字段（或把裸前缀填进要完整域名的字段）。两种都把记录挂到错误的名字下——包括经典的 yourdomain.com.yourdomain.com。
• 给 DKIM 值擅自加引号或去引号。公钥按服务商给的原文粘贴。2048 位密钥超长需要拆成多段带引号的字符串时，按给定方式保留拆分——Route 53、Google Cloud DNS 要手工拆，有的面板自动处理。
• NS 指向别处却去注册商面板改 DNS。真正管用的是 NS 记录委派给的那家面板。

几个值得单独展开的面板

一些注册商和邮件主机的面板怪癖多到值得单独写一篇。这些专篇覆盖了确切的字段行为和服务商自己的记录：

• GoDaddy——Name 字段是相对前缀，以及引号陷阱。
• Namecheap——最常漏的保存步骤，以及 Email Forwarding 覆盖 SPF 的坑。
• OVHcloud——CNAME 式 DKIM，以及默认 SPF 里的 PTR 问题。

常见问题

怎么知道我的面板用哪种写法？

看列表里已有的记录：如果显示的是 www、mail 这样的裸前缀，说明面板自动补域名；如果显示的是以你域名结尾的完整名称，就填完整名称。拿不准时，先保存一条测试记录，用 TXT 查询看它落在了哪里。

记录保存了，工具却查不到，为什么？

三个常见原因：传播延迟（等一等再查）；记录存到了错误的主机名（域名叠叠乐或漏了前缀）；面板里编辑的域名和你查询的域名不是同一个。查 DKIM 和 DMARC 时要精确查询对应主机名，别查域名根。

DKIM 或 DMARC 记录能用 @ 吗？

不能。@ 永远代表域名根。DKIM 挂在 selector 主机名下、DMARC 挂在 _dmarc 前缀下——按面板约定把这些前缀（或完整名称）填进主机名字段。

TTL 对认证有影响吗？

只影响改动传播速度，接收方不给 TTL 打分。调试期用短 TTL，改错也能快速止损；稳定后想加大缓存再调高不迟。