送达率 · 9 分钟阅读

面向自托管发件人的 6 周 IP 预热计划

作者 AcelleMail Team May 8, 2026 9 分钟阅读
deliverability

一份逐日的 IP 预热方案:线性 vs 指数斜坡、为什么第 2 周是瓶颈、AcelleMail 的 WarmupStrategy 模型如何执行、爬升期内要在 SES 信誉反馈里盯什么。

§1

到底为什么要预热?

在邮箱服务商眼里,一台没有发送历史的 IP 与一台刚被接管转手的 IP 看起来完全一样。没有任何合法性信号——至少现在没有。一台全新 IP 在第 1 天就发 5 万封邮件,看起来与一个垃圾邮件团伙临时租用一段未被信誉系统标注的纯净 IP 段抢在被发现前发邮件,毫无区别。

所以 Gmail、Outlook、Yahoo、Apple iCloud Mail 以及各区域服务商首次接触时做的事情都一样:接受一个较小的初始量,观察收件人如何反应(打开 / 点击 / 标记垃圾 / 不读直接删),只有在几天的干净互动之后,才解锁更大的发送量。这"几天"就是预热窗口。跳过它您不会被封——您会在之后好几周里被 限速 并被 丢进垃圾箱,而这比一次性被拒收更难恢复。

§2

线性斜坡 vs 指数斜坡

常见的斜坡形状有两种:

  • 线性——每天固定增量。50 → 100 → 150 → 200 → 250 … 可预测、慢、保守。
  • 指数——按倍数增长。50 → 100 → 200 → 400 → 800 … 更快到达目标量,但尾段更激进。

AcelleMail 内置的预热引擎(模型:app/Model/WarmupStrategy.php)通过常量 GROWTH_STRATEGY_LINEARGROWTH_STRATEGY_EXPONENTIAL 支持两种,并提供两个便捷预设:PRESET_BALANCED(线性、中等增量)和 PRESET_CAUTIOUS(线性、更小增量、更长斜坡窗口)。对于全新且无历史信誉的发件域,cautious 是更安全的默认。对于 From 域已经在另一个 IP 上有信誉、只是迁移 IP 的场景,balanced 或指数可接受。

§3

6 周计划(目标:每天 50,000 封)

下表数字是保守的线性斜坡。它们故意偏保守;纪律比精确数字更重要。打破任何预热的唯一铁律:在新 IP 信誉建立之前,绝不要在第二天把昨天的量翻倍。当每周的退信 + 投诉率在峰值连续一周保持干净,IP 就算"预热完成",预热结束。

发送量说明
150最小样本——先验证整条链路能跑通
2-3100 / 200盯首批 SNS 退信事件
4-7500 / 1k / 2k / 3k互动信号开始累积
第 2 周5k → 10k瓶颈周(见下文)
第 3 周15k → 25k多数服务商此时上调 per-IP 上限
第 4 周30k → 40k盯 per-domain 信誉,而不仅是 per-IP
第 5-6 周45k → 50k目标量;在该水平稳定运行整整一周

§4

为什么第 2 周是瓶颈

第 1 周末您已经证明自己能发送、收件人在互动。第 2 周末您来到每天 10,000——比第 1 天高了一个数量级。这正是 Gmail 与 Yahoo 的批量发件人阈值开始生效的时点:对任一单一邮箱服务商每天超过约 5,000 封时,DMARC 对齐、一键退订、投诉率上限从"建议"变为"强制"。如果上述前置条件少了任何一项,第 2 周就是它显现的时点——不是被封,而是悄悄被路由到垃圾箱。

修复方式就是在预热开始 之前 把三个前置条件全部就位:

  • DMARC 至少 p=quarantine; pct=100,理想是 p=reject,并让 RUA 报告流动起来。
  • 一键退订——通过 List-Unsubscribe + List-Unsubscribe-Post 邮件头(RFC 8058)。AcelleMail 默认输出这两个头。
  • 投诉率预算——Amazon SES 强制 0.1% 的硬性投诉率上限。把 0.05% 作为工作余量。

§5

AcelleMail 如何执行这个计划

控制台命令 app/Console/Commands/WarmupListServers.php 是 cron 入口。它遍历每台挂了策略的活跃发送服务器,在允许任何营销活动消费该服务器之前,先应用当日策略的每日上限。上限保存在 SendingServerWarmupUsage;每日执行日志在 SendingServerWarmupLog。策略本身通过 WarmupStrategy 上的常量支持三种限额类型:

  • LIMIT_TYPE_PER_DAY_CAP——"今天的发送预算是 N,不能再多"
  • LIMIT_TYPE_TARGET_VOLUME——"爬升直到每天 N 稳定,然后标记完成"
  • LIMIT_TYPE_STOP_AFTER_DAYS——"爬升 N 天,然后停止"

对多数运营者来说,正确的组合是 GROWTH_STRATEGY_LINEAR + LIMIT_TYPE_TARGET_VOLUME:线性爬升到每日目标,然后解除预热,转为正常运行。策略可以挂到任何发送服务器——SES、Mailgun、通用 SMTP、自定义——与底层驱动无关。

§6

在 SES 信誉面板上要盯哪些指标

如果您按 /pricing 推荐的搭配在 Amazon SES 上做预热,SES 控制台"Reputation metrics"面板里有三个数字在爬升期重要:

  • Bounce rate(退信率)——AWS 在 5% 告警,10% 暂停。您应该远低于 2%。
  • Complaint rate(投诉率)——AWS 在 0.1% 告警,0.5% 暂停。把 0.05% 作为工作余量。
  • Daily sending limit(每日发送上限)——SES 会随发送历史的累积自动增长。如果它停止增长,说明您的预热斜坡已经跑得比自动放量还快。

这三个都是 per-account,不是 per-IP,所以指标是您全部发送的合计派生量。如果第 2 周退信率开始爬升,放慢——不要硬撑。服务商已经注意到了什么,现在去排查的成本远小于被暂停后再恢复的成本。

§7

什么时候可以跳过预热

只有两种情况可以跳过预热:

  1. 您在用共享 IP 的 SES(默认情况——SES 生产账号共用一个被管理的 IP 池)。该池已经预热完成;您继承它的信誉。除非您升级到 SES 专用 IP,否则预热无关。
  2. 您现有的 From 域已经在另一个 IP 上建立了信誉,现在迁移到新 IP。您仍要预热,但用指数预设而不是保守线性,因为 From 域信誉会带过来。

除此之外的所有人——新域名、专用 IP、全新自托管的 Postal MTA——预热都不是可选项。日级别 SES 看板解读的更长篇版本在 /guide/email-deliverability §7

在您自己的基础设施上运行。

AcelleMail 是一次性授权的自托管邮件平台。完整源代码,不按订阅者计费。

试用在线演示