Cloudflare DNS 邮件认证：SPF、DKIM、DMARC 与 MTA-STS

Cloudflare 是发信域名最常见的 DNS 托管之一，简单的事确实简单：免费 TXT、即时生效、自动 TTL。坑在橙云。Cloudflare 的代理是为 Web 流量设计的，一旦不小心套在邮件记录前面，SMTP 与认证就会以各种难以理解的方式失灵——邮件进不来，验证永远不过，而面板上一切看起来都"已开启"。

更隐蔽的是 DNS only 与 DNS only 之间的差别：TXT 记录没有代理开关，天然安全；但 CNAME 和 A 记录有，而它们恰好是 DKIM、退信域和邮件服务器的载体。本指南带你在 Cloudflare 面板逐条发布 SPF、DKIM、DMARC，确保邮件记录远离代理，并可选加上 MTA-STS。协议原理见邮件认证总览。

准备工作

• Cloudflare 账号，域名的 DNS 已托管在 Cloudflare（注册商处 NS 已指向 Cloudflare）。
• 发信服务给出的 DKIM 值——Google Workspace、Microsoft 365、SendGrid、Mailgun、Zoho 各有专文。
• 一份以你的域名发信的全部服务清单，SPF 要在一条记录里覆盖所有来源，漏一个就是一条持续失败的发信通道。

最重要的一条：邮件记录一律 DNS only

Cloudflare 的代理只加速 HTTP 与 HTTPS，没有 SMTP 模式。实际影响有三点：

• TXT 记录（SPF、DKIM、DMARC）永远不会被代理——代理按钮对 TXT 不生效，默认就是对的。
• MX 记录根本无法被代理。
• 邮件服务器的 A 记录（如 mail.yourdomain.com 指向 203.0.113.10）才是真正的雷区。橙云一开，外界解析到的是 Cloudflare 的 IP，入站 SMTP 直接失败。务必切到 DNS only（灰云）。
• ESP 的 CNAME（SendGrid、Mailgun 的 DKIM 与 Return-Path）也必须 DNS only：被代理的 CNAME 返回边缘 IP，服务商的域名验证自然过不了。链接追踪 CNAME 是例外，它走 HTTP，开代理无妨。

以下记录都在 DNS > Records 里点 Add record 添加。TTL 保持 Auto 即可——Cloudflare 的自动 TTL 对邮件记录足够短——凡是出现代理开关的位置，确保是灰色。

发布 SPF

每个域名一条 TXT，放在根下，Cloudflare 里 Name 填 @：

Type: TXT
Name: @
Content: v=spf1 include:_spf.google.com include:sendgrid.net ~all
TTL: Auto

把所有发件源合并进这一条——两条 v=spf1 会让 SPF 永久失效——并守住 RFC 7208 的 10 次查询上限。合并时按"发信量从大到小"排序并不影响结果，但能让日后的排查更有条理：出问题时，先看排在前面的商业邮箱服务商是否仍被正确包含。用 SPF 检测验证，或用 SPF 生成器构建；接近上限时看SPF 扁平化指南。

发布 DKIM

DKIM 记录挂在 selector 对应的名称下。Cloudflare 会自动追加 .yourdomain.com，所以只填 google._domainkey 或 s1._domainkey，绝不能带域名，否则就成了双后缀的废记录。

Type: TXT
Name: smtp._domainkey
Content: v=DKIM1; k=rsa; p=MIIBIjANBgkq...(服务商提供的公钥)
TTL: Auto

用 CNAME 的服务商（Microsoft 365、开启自动安全的 SendGrid）则需要关掉代理：

Type: CNAME
Name: s1._domainkey
Target: s1.domainkey.u12345.wl.sendgrid.net
TTL: Auto
Proxy status: DNS only

2048 位公钥可能超过 255 字符，部分服务商会把它拆成两段带引号的字符串。照原样粘进同一个 Content 字段即可，Cloudflare 会正确保存多个字符串；不要手动拼接，也不要删掉引号。值得注意的是，DKIM 验证失败时面板不会报警，记录看起来"已保存"，问题只在收件方的 DMARC 报告里显形。用 DKIM 检测或对完整记录名做 TXT 查询确认，别凭感觉。

发布 DMARC

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1
TTL: Auto

从 p=none 起步，用 DMARC 报告分析器看聚合报告，确认所有正常来源都对齐后再收紧策略。记录用 DMARC 生成器生成。

可选：MTA-STS

MTA-STS 要求其他邮件服务器必须用 TLS 投递。需要两样东西：

• Name 为 _mta-sts 的 TXT：v=STSv1; id=20261104。策略一改，id 就要换，接收方靠它判断是否需要重新拉取。
• 一个 HTTPS 策略文件：https://mta-sts.yourdomain.com/.well-known/mta-sts.txt。网站跑在 Cloudflare Pages 或 Workers 上时，在 mta-sts 子域加个小路由即可——这个走纯 HTTPS，可以开代理。

两样都用 MTA-STS 查询检查；入站邮件的 MX 用 MX 查询核对。

整体验证

Cloudflare 的记录通常几秒到几分钟生效。先跑 邮件健康检查扫全域名，再向外部邮箱发测试信，用 邮件头分析器确认三项全部通过。测试至少覆盖两条路径：日常邮件（走邮箱服务商）和批量邮件（走 ESP），两者的记录不同，一条通过不代表另一条也通过。

常见错误

• 邮件服务器 A 记录开着橙云。入站 SMTP 到不了你的服务器，邮件直接退信。
• ESP 的 CNAME 被代理。CNAME 返回边缘 IP，服务商验证永远失败。
• Name 字段重复写域名。填 google._domainkey.yourdomain.com 会生成双后缀名称，DKIM 静默失败。
• 发布第二条 SPF。Cloudflare 允许 @ 下多条 TXT，接收方却不接受两条 v=spf1。
• 自己给 TXT 值包引号。Cloudflare 会自动处理引号，粘进带引号的值可能把引号当字面内容存下来。

常见问题

Cloudflare 会代理邮件吗？

不会。代理只有 HTTP/HTTPS 模式，SMTP 与认证记录必须以纯 DNS 形式提供。

TTL 要比 Auto 更低吗？

没必要。自动 TTL 足够短，改动几分钟内可见。只有迁移期间需要快速回滚时，手动 TTL 才有意义。

Cloudflare 会帮我扁平化 SPF 吗？

不会。Cloudflare DNS 不改写、不展开 include——那是厂商实现的特性，不是 DNS 标准。替代方案见SPF 扁平化指南。

MX 记录被代理导致邮件坏了，怎么修？

MX 本身无法被代理，真正发生的通常是 MX 指向的那条 A 记录开了橙云。打开 DNS > Records，找到对应的 A 记录，切成 DNS only，等几分钟再测入站邮件。顺手检查发信是否恢复正常：被代理的 A 记录有时会让部分接收方判定发信 IP 与域名不匹配。