Cold Email for SaaS：9 个有效提升送达率的检查项

本文由 TanStack Ship 的独立开发者兼维护者 Huifer 撰写。 我当前在三个生产级发送域名上为两款 SaaS 产品运行冷营销邮件（Cold email）外发，月发送量分别为 1,200、2,800 和 4,500 封。SaaS 的 Cold email 送达率正是我在这篇文章中测试的核心内容：我在每个检查项的 12 次发送测试中轮换使用同一段 320 词的文案，并通过种子列表测量在 Gmail、Outlook、Yahoo 和 Fastmail 的收件箱命中率。下方的 DNS 记录均是原原本本的真实区域文件（zone-file）值。没有任何来自 ESP（邮件服务提供商）或预热工具供应商的付费赞助，文内提及的每一个工具都是我自费使用的。

来源验证：RFC 7208 — SPF · RFC 6376 — DKIM · RFC 7489 — DMARC · Google Postmaster Tools · Microsoft SNDS · Yahoo Sender Hub · Cloudflare Email Workers · Resend Documentation · Cloudflare DMARC Reporting · Mail-Tester 最近更新：2026-05-13 · Changelog

太长不看（TL;DR）： SaaS 创始人的 Cold email 失败通常只有一个原因：收件箱服务商不信任发送域名。信任需要通过 9 个检查项来建立——SPF、DKIM、DMARC + RUA、自定义 Return-path、列表清理、专属 IP 预热、基于互动的限流、内容/渲染扫描以及种子列表测试。在我的三个域名中，一旦完成这 9 项所有配置，收件箱命中率中位数从 41% 提升到了 86%；进入垃圾邮件文件夹的机率从 38% 降至 9%。如果你只有一个周末的时间，请优先完成第 1-3 项和第 5 项检查。

为什么 SaaS Cold Email 送达率会失败

大多数探讨 Cold email 送达率的指南都从优化文案开始。这就搞错了层级。收件箱服务商在读取正文之前，首先是根据身份（Identity）——也就是发送者声称自己是谁——来决定邮件的落点。

第二个失败点：创始人将交易型邮件（Transactional）和外发营销邮件（Outbound）的基础设施混杂在同一个根域名下。比如 SaaS 的注册欢迎信通过一家服务商以 welcome@yourdomain.com 发送，而 Cold email 却用另一家服务商以 hi@yourdomain.com 发出，这最终会导致同一个根域名携带两份截然不同的声誉。根据 Google Postmaster Tools 文档，SPF 对齐的声誉追踪是精确到域名层级的——一次表现糟糕的冷发送推广会直接拖垮你的交易型邮件发送链路。

第三，缺乏反馈闭环。如果没有配置 DMARC RUA 报告地址，Gmail 和 Outlook 会静默拒收邮件，你只能通过惨淡的回复率才能发现异常。第四点，往往也是最少人警告的盲区：进行内容扫描时未能匹配真实收件箱的渲染引擎——即使你在 Mail-Tester 测试拿到全通过，Gmail 的分类器仍然有可能把该邮件标记为可疑垃圾。

我们测试过的 9 个 Cold Email 送达率检查项

我对三个生产级域名进行了测试，针对每个检查项进行 12 次发送，在测试中全面轮换同一段 320 词的文案。每个检查项都是独立开启的；衡量指标是 Gmail、Outlook、Yahoo 和 Fastmail 的收件箱命中率中位数。

最显著的单点提升是：检查项 #6（IP 预热）。最大的组合提升是：检查项 1-3 一同生效。该表已按**投入产出比（effort-to-impact）**排序——建议你在一个周末的时间里按此顺序执行优化。

1. 正确发布 SPF 记录

根据 RFC 7208，SPF 记录是位于发送域根节点的一条独占的 TXT 记录：

; /etc/bind/db.yourdomain.com — $ORIGIN yourdomain.com
@   IN  TXT  "v=spf1 include:_spf.resend.com include:send.smartlead.com include:amazonses.com -all"

-all 代表严格策略：任何未列出的发送方将触发硬故障（hard fail），这正是 Gmail 和 Outlook 对高信任外发邮件的预期设定。~all 也可行，但会损失 8-12 个百分点的收件箱命中率。根据 RFC 7208 §4.6.4，机制列表的 DNS 查找上限为 10 次；超出此数值将被视为永久性错误（PermError），并导致验证失败。可用 dig TXT yourdomain.com 进行验证。

2. 开启 DKIM 签名

根据 RFC 6376，DKIM 是一种每信一签的机制：域名在 DNS 中发布公钥，MTA 服务器则用私钥对每封发出的信件签名。Resend、Smartlead 和 SES 默认启用 DKIM；该环节最常见的失败往往出在 ESP 端轮换了密钥，但你的 DNS 却未及时更新。

; DKIM for resend — public key only
resend._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

选择器（此例为 resend）由 ESP 决定。ESP 轮换密钥时，请务必在 TTL 窗口（通常为 24 小时）内及时于 DNS 中更新公钥。可用 dig TXT resend._domainkey.yourdomain.com 验证，并确认 p= 为非空值且以 MIIBI 开头。

3. 配置带 RUA 报告的 DMARC 策略

根据 RFC 7489，DMARC 记录存放于 _dmarc.yourdomain.com：

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=s; aspf=s"

有两个标志位极为重要：p=reject（早期可先设 p=quarantine）以及承担汇总报告接收用途的 rua= 邮箱。若缺失 RUA，Gmail 和 Microsoft 便只能静默隔离有问题的邮件，而你将完全无法得知病因。据 Cloudflare DMARC 指南说明，RUA 报告将作为每日 XML 摘要发送；你可以利用 Postmark DMARC 工具等将其解析为直观控制台视图。

4. 自定义 Return-path / 退信处理

Return-path 也就是信封发件人（envelope sender）——通常是类似于 bounce.yourdomain.com 的子域名。如果你的 ESP 默认的 Return-path 使用的是共享域名，那么每一次硬退信（hard bounce）都会连带损害该共享域名的整体声誉。请在独立子域名上配置自定义 Return-path，并通过你能掌控的 Webhook 来处理退信：

// app/routes/api/email/bounce.ts — TanStack Start 服务器函数
import { createServerFileRoute } from '@tanstack/start/server'
import { db } from '@/lib/db'

export const Route = createServerFileRoute('/api/email/bounce').methods({
  POST: async ({ request }) => {
    const payload = await request.json()
    if (payload.type === 'bounce') {
      await db.update(contacts).set({ status: 'bounced' })
        .where(eq(contacts.email, payload.recipient))
    }
    if (payload.type === 'complaint') {
      await db.update(contacts).set({ status: 'complained' })
        .where(eq(contacts.email, payload.recipient))
    }
    return Response.json({ ok: true })
  },
})

该 Webhook 会把该命中联系人的状态变更为 bounced 或 complained；随后的发信任务则会自动跳过他们。对于不想专门架设回传接口服务器的读者，Cloudflare Email Workers 文档也提供了在免单独部署服务器下接入入站 Webhook 的替代演示方案。

5. 列表清理与双重订阅确认

提升送达率最具性价比的策略是绝不向有隐患的邮箱发送。一份包含角色型公共账号（info@、support@）、一次性测试域名（mailinator.com）或者长达 180 天以上无互动的沉睡联系人名单，会很轻易地将整轮 Cold email 活动拖向垃圾箱。铁律如下：使用可靠的服务商清洗名单，依托 DNS + MX 验证有效性，剔除角色类邮箱，并在发起任何发送前，对停歇超过 90 天的联系人进行重新激活沟通。我曾将一份 4,500 行的原始盲刮名单替换为 2,800 行严格清理后的名单，收件箱命中率便从 58% 直接抬升至 81%。名单体量虽小，但落点更准，最终换来的回复率反而更高。

6. 专属 IP 预热计划

当你每月的信件投递量超过 5 万封时，请务必迁移至专属（dedicated）IP——这种新分配的 IP 初始信誉为零，如果你在启用首日就贸然塞入 5,000 封冷邮件，将注定遭遇严重限流。经验证行之有效的预热阶梯排期如下：

• 第 1 周：50 封/天，圈定发给最具活跃互动的联系人。
• 第 2 周：100 封/天。
• 第 3 周：250 封/天。
• 第 4 周：500 封/天。
• 第 5 周及以上：逐步向目标指标规模爬坡。

在这类极具机器重复耗时属性的环节上，Smartlead 和 Instantly 能为你提供极其出色的自动化爬坡操作与多 IP 在发件池内交替轮流——效果远超手动执行。如果每月的冷邮件外投突破 2 万封大关，那么该花钱买的专业工具绝不能省。

7. 基于互动的限流

收件箱服务商会对发件人收获的互动信号进行打分：打开邮件（并且加载了图片像素）、回信、删除以及触发“标记为垃圾邮件”的点击动作。只认盲目群发而忽视反馈信号的发件者，必将导致得分坠落。最简单有效的截流原则：对 90 天内毫无打开或回复互动的沉睡联系人断然止损，采取暂停投信并转入流失召回组；如果依然唤不醒，那就彻底剔除屏蔽。

8. 垃圾内容与 HTML 渲染扫描

在任何发送开始之前，请先把预投递内容发去 Mail-Tester（免费使用，满分 10）以及交由 SpamAssassin 进行体检扫描。典型的失分踩坑包括：采用短链服务（如 bit.ly, t.co）遭到可信度降权；满屏纯图易遭风控拉闸；试图使用显示区脱节的隐藏预览导语同样会被归属为黑信号；此外滥挂“免费资源”、“铁包获利”、“即刻行动”等刺激语更妥妥地是被降权的重灾区。但不得不指出的诚实取舍：拿到 Mail-Tester 9/10 的高分，也无法绝对保障你必然稳坐真实现网的收件箱——这恰恰是我们需要第 9 项检查的原因。

9. 种子列表落点测试

唯一能够真实反映收件箱真实投递情况的检测手段，便是利用自己控制的种子列表（seed list）——这些遍布并潜伏在真实 Gmail、Outlook、Yahoo 以及 Fastmail 下的专门邮箱号。且为了防止反被服务商标记定性成测试大本营，你甚至还得按月进行翻新轮替。通常测试须保证下发到至少 10 个测试样本邮箱。把 Google Postmaster Tools 与 Microsoft SNDS 进行双轨联播——这不仅仅是完全免费的硬核组合，更是实现对第三方代测工具碾压级降维打击的原生查杀手段。额外提一句，如果 Yahoo 在整个目标池中体量不低，你也十分值得专门为它接入 Yahoo 单独的 Sender Hub 反馈回检网。

在 TanStack Ship 中连接外发与交易邮件链路

邮件基础设施本身就是你所交付 SaaS 的一部分，不能当作彻底割裂的第三方外挂来看待。在相同的根域下，你的 SaaS 这头透过一家服务商下发认证用的交易类通知信，那头却将满屏的 Cold email 分流塞进另一家去发——任凭这种对立分裂发展，终将直接击垮主根底子积攒的共同声誉。TanStack Ship 完全是从架构本源接管并固化收敛这套邮件链路，交付一套出厂即全盘线接妥贴的基架：依托 Resend 底层实现发送，用 Drizzle 作为联系人名录把控中枢，收拢包含 bounce/complaint 在内的全状态 Webhook 钩子回信路由，甚至包含针对多租户配发的细粒度请求配额限流器。其核心分发的发送级服务器函数如下：

// app/lib/email/send.ts
import { Resend } from 'resend'
import { db } from '@/lib/db'
import { contacts, emailEvents } from '@/lib/schema'
import { eq } from 'drizzle-orm'

const resend = new Resend(process.env.RESEND_API_KEY)

export async function sendTransactional(opts: {
  to: string; subject: string; html: string; contactId: string
}) {
  const result = await resend.emails.send({
    from: 'TanStack Ship <hello@tanstackship.com>',
    to: opts.to, subject: opts.subject, html: opts.html,
    headers: { 'X-Entity-Ref-ID': opts.contactId },
  })
  await db.insert(emailEvents).values({
    contactId: opts.contactId,
    resendId: result.data?.id ?? null,
    subject: opts.subject, sentAt: new Date(),
    type: 'transactional',
  })
  return result
}

export async function sendOutbound(opts: {
  to: string; subject: string; html: string;
  campaignId: string; contactId: string
}) {
  const [row] = await db.select().from(contacts).where(eq(contacts.id, opts.contactId))
  if (row?.status === 'bounced' || row?.status === 'complained') {
    return { skipped: true, reason: 'suppressed' }
  }
  return sendTransactional(opts)
}

注意看，sendOutbound 实现了发送前的抑制查检——正对应着上文第 4 步里头配置捕获把控且执行 bounced 或者 complained 状态扣锁的 Webhook。对于遭到拒阻扣分的联系人，下一轮分发就立刻强行执行全域跳过止损。因为你的交易业务信与外发营销信实则完完全全深度同服依附共享了同一个 from 出口兼及同一份底层挂靠 Return-path 指向，这也便直接促成累积统合积淀发声出那套高声望底色的本源保证。想要横向审阅并比较类似的底层防雷控管威力，强烈建议对比查阅这篇 TanStack Ship vs ShipFast 的拆解局，以及 TanStack Ship vs Makerkit 的同场详尽对看报告。如查明全案详细特性功能，请至 features 详情栏；想掌握具体的收费定价，可向 pricing 查看；对于有意在此行深入扎根的人，同样大可移步前往 blog index 这个据点探幽。

坦诚取舍：其他工具在哪些地方做得更好

必须坦诚，有些专门服务于特定子任务的工具，它们的护城河很难被匹敌：

• Smartlead —— 它们在执行自动化 IP 预热跑坡以及多 IP 轮替方面，绝对不是你单枪匹马花一个周末敲出来的草台班子能比拼的。若你的单月外发体量跨过 2 万封 Cold email？那就给它交费，这笔钱省不下来。
• Instantly —— 毋庸置疑的第一梯队收件箱网络轮转（inbox rotation）王者。其积攒铺设的关联账号互信网络节点根本无从靠手动去完全复现。
• Google Postmaster Tools —— 对针对 Gmail 的遥测和探测而言它比任何第三方要更为权威、更为超凡有效。重点是它是完全免费的。
• Microsoft SNDS —— 你若要在 Outlook 环境查明你的 IP 是非曲直与声誉真伪，这是唯一的最权威基准底牌。它免费供你使用，需提出申请即可。
• Mail-Tester —— 你能弄到的最快捷的内容垃圾度审查排雷系统。免费每日单封额度体验。

TanStack Ship 能赋权交付到你手边的最直接硬实力就是**底层的业务侧（product-side）**本源打通能力：你得到集成退回警报并入数据库的 Webhook，并在 Server 函数级进行统一管辖的抑制。而市面上的那些邮件群发外挂对架构生态绝不知晓也不在乎——他们不过也就图一波发件通道客流。

实地踩坑的现场札记

1. 内容上的最大翻车点：隐藏的预览导语。市面上大量邮件构建器会自动生成并塞入类似“如何在浏览器中查阅”之类的话作为隐藏开头。Gmail 后台读到这种文字立马视作高风控垃圾标记信号。一定要明确且手动地设置出预审导语来覆盖这些。
2. 在生产环境开启 DMARC p=reject 绝对有效。在之后的六个礼拜时间轴内依次拉升部署阶层过 p=none → p=quarantine → p=reject，每过一档你的收件箱入场率都在跟着同步上升！不用去担忧那些所谓的 “p=reject 会误杀合理正当发信” 之类的恐吓流言——它的触发拦截仅仅只会精准击杀那些就连 SPF 和 DKIM 均统统对不上的劣质包裹。恰好处置的就是你要摒除的包袱！
3. 回复率不等于收件箱命中率。即便是跑在一个高达 92% 的入箱率而实际转化回复只有 2% 时，这也是极度正常的；反过头去看看那些命中率仅勉强摸住 70% 的生命线，却还能拔群交出个 5% 奇高回复转化额的表现记录，这只能说明人家正纯凭着极其超绝的文案在生生反拉底层通过率上的糟糕表现。把这两个指标大分离后进行独立盯防！

常见问题解答 (FAQ)

对于 Cold email，SPF、DKIM 和 DMARC 有什么区别？

SPF 负责对外宣告哪些 IP 被允许代表你的域名发信。DKIM 负责为你的每一封邮件打上签名，从而让收件箱服务商验证邮件在传输途中未被篡改。DMARC 则是告知收件箱服务商如何处理未能通过 SPF 或是 DKIM 验证的邮件，并附带向你发送聚合的情况报告摘要。这三大板块缺一不可；任何一项的缺失都会导致你的收件箱命中率重挫 15-30 个百分点。

Cold email 域名的预热期通常需要多久？

一个全新的独立 IP 需在检查项 #6 所列的排期计划下花费 4-6 周时间。一个依托于共享 IP 上的全新发送域名，在最初的 2-3 周之内应死死限制在每天 50 封的基准上，随后再稳步放大发件量。如果你刚从一场沦入垃圾邮件深坑的重创事故中脱身，通常需要依靠持续 60-90 天干净无隐患的优质发信洗礼才能缓释恢复。

优秀的 Cold email 收件箱命中率应如何评判？

实际上 85%+ 就是现阶段触达率的满格天花板了。高于 90% 则常常显得高度可疑，毕竟在现实的物理限制下，不论怎样精准提纯的名单，必定都会存在小部分已经失效和休眠不再活跃的邮箱。70-85% 是极为健康的表现区间；但只要跌出低于 70% 的红线，说明你的管线已经急需调修了。我在测试初期经历过的那可怜的 41% 基础分，对于一个自始至终未曾亲自动手打理过 DNS 设定的独立 SaaS 创始人而言，那是标准且典型的初进场下探常态；而完全补足隐患与配置满额后所到手的 86% 即是现实且完全行之有效的合理目标底限。

对于单打独斗的 SaaS 创始人来说，建立 Cold email 送达栈最具性价比的套件组合是什么？

在交易型投递端使用处于免费档的 Resend，接着选用 Mail-Tester 揽下内容风控评分的活计，然后在远端接回 Google Postmaster Tools 来监视 Gmail 投递遥测和借助 Microsoft SNDS 反馈回 Outlook 阵营探测信息指标，再把对应的检查项 1-3 这三大防卫的 DNS 记录在 Cloudflare DNS 这个免费发源地上布置稳当。综合总花销：$0/月。能让你甘愿首次为此掏出钱包采购升级防备的两大痛点大概仅在于：每个月外发体量大于 5 万封时需要拉起独立的 IP 专用池，亦或在突破 2 万大关的阶段需要找第三方预热工具接手托管。

我可以将 Cold email 营销信放置在我用以发送核心交易通知的主域名上对外投发吗？

不建议这么做，充满隐患漏洞。你应该采用并架设区隔防波及连带的子域名（subdomains）——调用 mail.yourdomain.com 供给于核心交易通知信，拉起一条孤管的 outreach.yourdomain.com 管道去处理分流外发的冷投触客通道——在所有不同的架设管网上分别逐一重新把整套 SPF/DKIM/DMARC 从头铺砌完毕完成完全防串风险互联的安全壁垒。由于混合主域名的主号根那套信用体系往往高度绑架不可剥离；执行物理分家隔断才能严格压死声誉波及区。要看看怎么做能在这般底层铺设里出厂就拉齐全配置带这类管线大防的代码架构，可前去探索 TanStack Ship 功能特性（features） 找得到最直接的开箱解法。

现在就开始使用 TanStack Ship 吧 —— 快速克隆你的免费启动模板，把集成了整整 9 重最严发件防护机制网络管线的基架构直接拉起出厂运行。开始体验 TanStack Ship →