只收信也要配 DKIM 吗？不需要，但 SPF 和 DMARC 要看情况

2026-10-28 · 邮件 / 域名

搜「域名邮箱配置」，十个教程里有九个让你把 SPF、DKIM、DMARC 三条全配上，好像缺一条就收不到信。如果你只是拿域名收验证码、转发到现有邮箱，这个结论是错的——至少 DKIM 那条纯属白做。

原因很简单：这三条记录解决的是三个不同的问题，而「只收信」只碰到其中一个。

三条记录各管什么

记录	验证的是	谁在查	只收信需要吗
SPF	这封信是不是从「被授权的 IP」发出来的	收信方的服务器，查发件域的 SPF	看情况，见下
DKIM	这封信有没有被改过，签名对不对	收信方，用发件域的公钥验签	不需要
DMARC	SPF/DKIM 失败时怎么办，报告发给谁	收信方，查发件域的 `_dmarc`	不需要，但建议配

关键点：这三条都是别人发信给你时，用来验证「你的域名」的记录。你收信这个动作本身，不触发任何一条。

DKIM 的工作方式是：发信方用私钥给邮件签名，把签名放在邮件头里；收信方用 DNS 里查到的公钥验证。

你没有私钥，因为你根本不发信。没有私钥就签不了名，配一条空的 DKIM 记录除了让 DNS 看起来「很齐全」之外没有任何作用。

有些教程会说「配了 DKIM 能提高送达率」。这句话对发信成立，对收信不成立——送达率是「你发出去的信进不进对方收件箱」的指标，和你收信没关系。

你用 Cloudflare Email Routing 转发时，实际发生的事情是：别人发给 contact@你的域名 → Cloudflare 的 MX 收下 → Cloudflare 用它自己的服务器把邮件转发到你的 Gmail。

这一步里，Cloudflare 会重写信封发件人（envelope sender），并且用它自己的 SPF 域名去通过检查。所以你域名上的 SPF 记录，对「转发出去的那一段」不起决定作用。

但 Cloudflare 在启用 Email Routing 时会自动写一条：

v=spf1 include:_spf.mx.cloudflare.net ~all

这条留着没坏处。它的作用是声明「只有 Cloudflare 的服务器有权用我的域名发信」——万一将来你接入了别的发信服务，这条记录就是第一道闸。

DMARC 本身不阻止任何东西，它只做两件事：告诉收信方「SPF/DKIM 都失败时怎么处理」，以及「把汇总报告发到这个地址」。

只收信的场景下，第一条用不上（没人用你的域名发信）。但第二条有用：

v=DMARC1; p=none; rua=mailto:dmarc@tynqueevue.com; fo=1

p=none 表示「只观察，不处置」，rua 是报告接收地址。配了之后，如果有别人伪造你的域名发信，你会收到汇总报告——这是一条「这个域名有人在维护」的实质证据，比页面上写「本站已备案」有用得多。

注意 p=none 阶段不要急着改成 p=reject。先收几周报告，确认没有正常的发信源被误伤，再收紧。

只收信 + Cloudflare Email Routing 的最小集合：

记录	要不要	说明
MX	必须	Cloudflare 自动写入三条，优先级 10/20/30
SPF (TXT @)	自动带的，留着	`include:_spf.mx.cloudflare.net`
DMARC (TXT _dmarc)	建议	为了收报告，`p=none`
DKIM	不用	没有私钥，配了也是空转
CAA	建议	限制谁能给这个域名签证书

dig +short tynqueevue.com MX
dig +short tynqueevue.com TXT
dig +short _dmarc.tynqueevue.com TXT

三条都有输出就齐了。DKIM 查不到是正常的——本来就不该有。

最后提醒一句：MX 记录不能开 Cloudflare 的橙色云朵代理。开了之后邮件直接收不到，而且错误信息只会说「连接超时」，不会告诉你是代理的问题。