验证码邮件总进垃圾箱：先把 SPF、DKIM、DMARC 补齐再换服务商

先别急着换服务商

社区里有人问：我在小服务器上发注册验证码和一些推广邮件，量不大，但 Gmail 老是判成垃圾，是不是该换一个支持 DMARC 的邮件服务？

顺序反了。DMARC 是你自己域名下的一条 DNS 记录，不是服务商卖给你的一项功能。服务商能替你做的是两件事：把 DKIM 签好、给你一个干净的发信 IP。但如果你的域名从没声明过「对不上的信该怎么处理」，收件方就只能在「看不出真伪」的那堆信里猜——垃圾算法必然误伤，你换哪家都一样。

为什么只有 SPF 和 DKIM 还不够

SPF 和 DKIM 都是十多年前就有的技术，解决的是「这封信确实来自某个地方」。问题出在真实环境：一个域名往往有好几处在发信，网站程序、表单通知、CRM、第三方 SaaS 各发各的。只要其中一路没签上，你的域名就同时在发「能认证」和「不能认证」两种信，收件方没法区分哪一种才是冒充的。

DMARC 补的就是这一层：它让你在 DNS 里明确告诉收件方，不匹配的信该怎么处置；同时反过来看见自己到底漏了哪些发信源——以前除了退信，你根本不知道有多少合法邮件没能通过认证。

一条记录长什么样

DMARC 记录是域名下的一条 TXT 记录，形如：

v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@yourdomain.com

几个标签值得记住：p 是策略（none / quarantine / reject）；pct 是施加比例，可以先只对 20% 的邮件生效做灰度；sp 单独管子域；adkim 和 aspf 控制「对齐」的严格程度；rua 收聚合报告，ruf 收取证报告。

关键词是对齐：DMARC 不只要求 SPF、DKIM 通过，还要求它们跟你在信头里展示的那个域名对得上。很多人两条都配了、DMARC 还是失败，卡的就是这一步。

五步走，别一步跳到 reject

官方给的部署顺序就是这么设计的，慢是有道理的：

1. 先把 SPF 和 DKIM 铺满——列清你域名下所有在发信的系统，漏一个就有一批信对不上。
2. 确认每个发信源的标识符能正确对齐。
3. 先发一条 p=none 的记录，只收报告、不动策略。
4. 看 rua 聚合报告，把没认证的发信源找出来，能补就补、不能补就砍掉。
5. 再逐步把策略改成 quarantine，最后才是 reject。

小团队的节奏大概是：p=none 跑上一两周，报告干净了再往 quarantine 挪。直接上 reject，最先丢的往往是你自己那条订单通知。

DMARC 之外还剩三件事

• 反向解析（PTR）和发信 IP 的历史信誉——这才是换服务商真正能改善的部分，新域名新 IP 本来就要养。
• 发信量本身。从每天几十封突然跳到几万封，比配置错误更容易触发风控；验证码这种量级一般没问题，推广信要单独分批。
• 你机器所在的商家允不允许你这么发。前面那台便宜 VPS 的条款里就写着按 SMTP 连接数监控出站邮件，超量可以不通知直接停掉出站——配置再标准，端口被掐也白搭。

想省事的话，部署工具在官方资源页上有一批，生成记录和读聚合报告都有现成的；但先把「我这个域名到底有几处在发信」这张清单列出来，那是任何工具都替不了你做的事。