Gmail 与 Yahoo 在 2024 年 2 月推出的批量发件人规则,到底改变了什么

2024 年 2 月 1 日,Google 与 Yahoo 同步开始对任何向其用户群发送量超过 每天 5,000 封 的发件人执行新要求。两份公告至今仍是规范引用——Google 的"Email sender guidelines" 与 Yahoo 的"Sender best practices"——内容几乎一致。三条核心要求:

1. 认证。SPF 与 DKIM 必须有;DMARC 至少 p=none 必须有。未对齐的邮件要么进垃圾箱要么被拒收。
2. 一键退订。List-Unsubscribe 邮件头(RFC 2369,1998)早就存在;2024 新增的是 一键 要求——退订 URL 必须接受单次 POST 请求并直接处理,不允许中间确认步骤(RFC 8058,2017)。用户在邮件客户端里点一下就完成退订。
3. 投诉率上限。批量发件人必须始终把垃圾投诉率保持在 0.3% 以下。持续超出会触发自动降级,邮件被丢进垃圾箱。

2024 之前,大多数自托管运营者只跑 SPF + DKIM,跳过 DMARC。理由是:DMARC 不过是在另两个之上加一层策略,而拿回报告在运维上很烦人。这个理由现在不成立了。

具体地说,2024 的规则要求 DMARC 必须 存在——哪怕只是 p=none——并且必须对齐。DMARC 中的"对齐"意味着 SPF 的 From 域或 DKIM 的签名域,要与可见的 From: 邮件头匹配,严格或宽松对齐都行。一种常见失败:发件人把 marketing@yourcompany.com 作为可见 From,但邮件实际通过第三方 CRM 转发,而 CRM 用自己的域名签 DKIM——对齐失败,DMARC 失败,Gmail / Yahoo 静悄悄地把邮件路由到垃圾箱。

修复方式就是标准的 DMARC 上线流程:先发布 p=none 配 RUA 报告,观察两到四周日聚合数据,识别并修复未对齐的发送流,渐进推进到 p=quarantine,最终稳定在 p=reject。没有捷径。

技术门槛就是两个邮件头,均依据 RFC 8058:

邮件客户端(Gmail、Yahoo、Apple Mail)会把它渲染为邮件头部的一键"Unsubscribe"链接。用户点击时,客户端向该 URL POST List-Unsubscribe=One-Click。您的服务器处理退订并返回 200 OK。没有确认页,没有验证码,不需要登录。

AcelleMail 默认会为任何启用了退订处理的营销活动名单输出这两个邮件头。运营者真正栽跟头的是自定义集成——绕过营销活动引擎的事务型流程、把邮件头剥掉的第三方 SMTP 中继、重定向到 CMS 确认页的退订 URL。每一种都是送达率的扣分项。

最简单的验证方式:给自己发一封测试邮件,在 Gmail 里点"显示原始邮件",搜索 List-Unsubscribe-Post。如果邮件头缺失,或者值不是 One-Click,就是不合规。在每日发送量跨过 5,000 到任一服务商之前修好它。

投诉率指收件人把您的邮件标记为垃圾邮件的比例,按日计算,采用滚动窗口。Google 的公告要求"持续低于 0.3%",同时把"我们希望看到您持续低于 0.1%"作为工作余量。

两条实施注意事项:

1. 按域名计,不是按账号计。如果您把营销邮件拆到子域(如 news.yourcompany.com),投诉率只针对该子域计算。子域突破 0.3% 不会 自动连累根域上的事务型邮件,这正是把营销邮件隔离到子域这种标准做法的原因之一。(参见 /glossary/email-deliverability。)
2. Gmail 和 Yahoo 的测量方式不同。Gmail 用"已打开收件人中点击垃圾按钮的比例"。Yahoo 在自家界面采用类似指标。两个数字应该跟踪在 ~0.05% 之内;大幅偏离通常说明受众结构有偏差,而不是发件人本身有问题。

要拿到可见性,请注册 Google Postmaster Tools(免费,需要对您的域名做 DNS 验证)和 Yahoo 的 Complaint Feedback Loop。两者都暴露每日投诉率数字。AcelleMail 通过 SNS webhook 消费 SES 层面的投诉反馈(app/SendingServers/Webhooks/ComplaintReceived.php),这是发送服务器层面的事实来源。Gmail / Yahoo 的比率是送达后的,SES 的比率是接收时的。

严格意义上,2024 规则只适用于批量发件人——即向 Gmail 或 Yahoo 任一方每天发送超过 5,000 封。低于这个阈值,要求是"最佳实践"而非强制。

但实际操作上,这没什么意义。低于 5,000 的发件人同样会因为缺 DMARC、缺一键退订、或投诉率高而被丢进垃圾箱。服务商跑的启发式判断基本一致;差异在于:超过 5,000 服务商会把您放进"批量发件人"队列、自动化更严格;低于 5,000 则进入人工审核 / 互动驱动的轨道。无论哪种,在 5,000 以下忽略这些规则,都会带来可测量的送达率损失。

正确的框架是:2024 规则只是把主流服务商既有的事实标准 编码化 了。它没有发明新要求,只是让既有要求变得显式且可执行。每天 5,000 封以下的自托管运营者,也应该把这些规则当作工作门槛来对待。

三种模式在 2024 年 2 月到 3 月规模化崩盘,至今仍在造成可测量的送达率损失:

1. 转发器导致的 DMARC 失败。那些经营邮件列表、把邮件转发到订阅者个人邮箱的运营者(经典"list service"模式)发现自己转发的邮件被大规模拒收。修复方式是改写转发邮件的 From 头(ARC 方案),或把列表切到从列表自己的域名直发。Mailman 3 与 Postal 的列表模块都支持。
2. 第三方 CRM 发件。通过附挂在 CRM 上的 SMTP 中继发送、并由 CRM 用自己的域签名,会破坏 DMARC 对齐——除非 CRM 同时在您的子域下发布自己的 DKIM。SES、Mailgun、SparkPost、SendGrid 都支持这一点;较老或较小众的中继可能不支持。
3. 未认证的事务型流程。"我们在跑应用的同一台机器上用 Postfix 发密码重置邮件,不签 DKIM"——任何有意义的发送量下都不再 work。修复方式是为根域发布 DKIM 公钥,并在该 Postfix 上配置 OpenDKIM——一次性工作,回报覆盖全部事务型流量。

2024 规则的影响比第一眼看到的要深得多。它不仅抬高了门槛——还把门槛变得具体且可测试。Sender Score、Talos、GlockApps、Postmark 以及各种送达率监控厂商,在几个月内就把这三大支柱纳入了自己的检查项。到 2025 年中,整个商业化送达率工具生态都把 DMARC + 一键退订 + 投诉率作为前提条件;那些"我们帮您 debug SPF"的老牌服务要么升级、要么悄悄退役。

对自托管运营者来说,2024 规则加速了一场本已在进行中的转变:从"想从哪发就从哪发"(2010 年代自托管的常态)转向"只从一个您主动管理其信誉的域,发送已认证、已对齐、易于退订的邮件"。这是更高的运营门槛,但带来一个低风险的稳态。AcelleMail 服务于这个稳态的工具——WarmupStrategy、BounceHandler、退订名单、NeverBounce / ZeroBounce 验证适配器——在 2024 之前就已经在代码库里;变化的是它们从可选变成了必需。

如果您过去 6 个月没对自己的发件域做过一次 2024 规则合规审计,今天就是个好时机。五分钟版本:给自己发一封测试,在 Gmail 里"显示原始邮件",确认三个 pass 判定加上 List-Unsubscribe-Post: List-Unsubscribe=One-Click 邮件头。如果都过,您就没问题。如果没过,要走的路也已经被踩得很熟。