别让第一封邮件进垃圾箱：vibe 项目的事务邮件基础设施指南

引子：你的第一个用户，可能永远收不到那封验证邮件

想象这个场景：你花三周 vibe 出一个 SaaS，上线第一天，第一个真实用户注册了。他填完邮箱，盯着收件箱等验证链接——一分钟、五分钟、十分钟，什么都没有。他去垃圾箱翻了一眼，也没有。于是他关掉页面，再也没回来。你损失的不是一个用户，是你永远不知道自己损失了一个用户。

这不是危言耸听。注册验证、密码重置、订单通知、账单提醒——这些统称为事务邮件（transactional email），是几乎每个 vibe 项目上线第一天就要发的东西。但绝大多数 vibe coder 的处理方式是：随便找个 SMTP 填进环境变量，能发出去就完事。结果是：验证邮件全进垃圾箱，或者干脆被 Gmail 拒收，而你浑然不知，因为"发送成功"不等于"送达收件箱"。

这篇指南要解决的就是这件事。我的核心判断先摆出来：邮件基础设施是上线日 Day 1 的工程，不是 Day 30 的优化项。你宁可晚两天上线，也别带着裸奔的发信配置上线——因为发信声誉一旦搞砸，修复的时间是以周甚至月计的。

一、事务邮件和营销邮件：两个世界，别共用一条命

先分清：什么是事务邮件

事务邮件是由用户行为触发、一对一发送、用户明确期待收到的邮件：注册验证、密码重置、登录提醒、订单确认、发货通知、账单收据、评论回复通知。营销邮件则是你主动发起、一对多发送的：产品更新周报、促销、新功能广播。

两者的本质区别不在内容，而在收件人的期待值。用户在注册后 30 秒内是"期待"验证邮件的，这时候邮件进收件箱是顺理成章；没人期待周二早上的促销邮件，它天然站在垃圾邮件的嫌疑人名单里。Gmail 和 Outlook 的过滤系统正是围绕"期待值"建模的——打开率、回复率、"这不是垃圾邮件"点击率、投诉率，每一项都在给发件人打分。

发信声誉：你看不见的信用分

每个发信域名和发信 IP 在 Gmail、Outlook、Yahoo 那里都有一笔"信用账"。新域名从零开始，类似于没有征信记录——能发，但额度低、审查严。你的每一次发送都在加分或减分：用户打开、回复、移出垃圾箱是加分；被标记为垃圾邮件、退信率过高、大量用户不打开是减分。

关键机制有三条，vibe coder 必须刻在脑子里：

• 声誉是按"通道"隔离的，但默认不隔离。如果你用同一个域名、同一个服务商账号既发验证邮件又发营销群发，Gmail 看到的是同一个发件身份。营销邮件天然投诉率高，一旦某次群发的投诉率超标，掉的是整个域名的分——你的密码重置邮件跟着一起进垃圾箱。
• 2024 年起，Gmail 和 Yahoo 对群发者动了真格。单日向 Gmail/Yahoo 用户发送超过 5000 封就被定义为 bulk sender，必须配齐 SPF、DKIM、DMARC，提供一键退订，投诉率必须压在 0.3% 以下（最好 0.1%）。这条线离小项目看似很远，但它说明了一个趋势：邮箱服务商对"身份不明的大声嚷嚷"越来越没有耐心。
• IP 声誉和域名声誉是两回事。共享 IP 意味着你的"邻居"也在影响你的分数——这就是为什么选服务商时要看它管不管得住自己的共享 IP 池，以及要不要为你单独买独立 IP。

DNS 记录与邮件投递关系示意图

一个真实类型的事故：一次群发，拖垮整整三周的验证邮件

讲一个在独立开发者圈子里反复上演的类型化事故（细节做了模糊处理，但机制千真万确）：一位开发者做了个 AI 记账工具，上线两个月一切正常，验证邮件到达率一直很好。某天他心血来潮，给 8000 个注册用户群发了一封"重大更新"——用的就是发验证邮件的那个域名和同一个 Resend 账号。

群发本身没出大错，但其中有几百个邮箱是用户随手填的无效地址，退信率直接冲到 6%，还收到了几十个"举报垃圾邮件"。三天后，新用户开始反馈收不到验证邮件。查日志：发送全部"成功"，但 Gmail 的 Postmaster Tools 里域名声誉从 High 掉到了 Low，大批验证邮件被扔进垃圾箱。他花了三周时间：停掉一切营销发送、只保留事务邮件、慢慢把声誉养回来，注册转化率才恢复正常。

这个故事的教训只有一句话：事务邮件和营销邮件必须物理隔离——不同的子域名、不同的发送通道，最好是不同的服务商账号。比如验证邮件走 send.yourapp.com，营销邮件走 news.yourapp.com 或干脆另一个域名。一个通道出事，另一个不受牵连。这是整篇指南里性价比最高的一条建议，成本为零。

所以，第一原则

永远不要用你的个人 Gmail、QQ 邮箱、163 邮箱发事务邮件（发信量一大就被限流封号，而且没有 DKIM 对齐）；永远不要把事务邮件和营销邮件混在同一个发信身份里；上线第一天就把域名声誉当成资产来经营——因为它真的是资产，丢了要按周赎回来。

二、服务商选型：Resend、AWS SES、Postmark 怎么选

个人 SMTP（比如直接拿 Gmail 的 SMTP 发）直接出局，原因上面讲了：没有发信声誉管理、没有退信 webhook、量稍大就被限流。剩下三家是 vibe coder 圈子里讨论最多的，各有各的性格。先说我的结论，再摆数据：

• 默认选 Resend。除非你有明确理由不选它。
• 量大、抠成本，选 AWS SES。月发送过 10 万封之后，SES 的成本优势会大到让你无法忽视。
• 对到达率极度敏感（登录验证、金融通知），选 Postmark。贵，但它就是吃"送达"这碗饭的。

三家对比（截至 2026 年 10 月的公开定价，实际以官网为准，可能变动）

维度	Resend	AWS SES	Postmark
免费额度	每月 3000 封（每天上限 100 封），1 个域名	新账号无免费额度（只有 AWS 新用户赠金）；沙盒期每天限 200 封且只能发给已验证地址，需申请提额	每月 100 封，硬上限，仅够调 API
付费起点	$20/月（含 5 万封）；$35/月（含 10 万封），超量约 $0.90/千封	按量计费约 $0.10/千封（2026 年 7 月起新账号默认 Essentials 约 $0.16/千封，可切回经典按量档）	$15/月（含 1 万封），超量 $1.80/千封起，量大档单价可降到 $0.5/千封左右
月发 1 万封约花多少	$20（Pro 档）	约 $1–1.6	$15
月发 10 万封约花多少	$35	约 $10–16	约 $100–177（含超量费）
到达率口碑	好，共享 IP 池管理得不错；独立 IP 为 $30/月插件	取决于你自己：共享 IP 便宜但邻居不可控，独立 IP 约 $24.95/月/IP，需自己养声誉	业内标杆，常年自称并实测接近 99% 级别收件箱率；事务与营销用 Message Streams 物理隔离
开发者体验	极好：REST API、官方 SDK、React Email 写模板，10 分钟接完	原始：API/SMTP 能用，但模板、退信处理、统计面板都要自己搭	好：API 简洁，Mustache 模板服务端渲染，45 天日志保留
最大坑点	免费版每天 100 封的上限，上线当天就可能打爆；营销邮件按联系人另计费，别搞混	沙盒期和提额流程劝退新手；出了问题全靠自己排查，支持响应慢	贵：同量级下单价是 Resend 的数倍；免费额度几乎等于没有

看表格要会算账：月发 1 万封，SES 只要 1 块多美金，Resend 要 20 美金——差了十几倍。但对一个 vibe 项目来说，每月 18 美金的差价，买的是"不用自己搭退信处理、不用写工单申请提额、10 分钟接完 API"。你的时间比这贵得多。成本优化是规模化的烦恼，不是上线日的烦恼。

一人项目的决策树

1. 还没上线 / 刚上线（月发送 < 3000 封）：直接 Resend 免费版。注意每天 100 封的上限——上线推广当天如果注册爆发，验证邮件可能被限流。稳妥做法是上线前就升到 $20 的 Pro，或者至少准备好一键升级。
2. 有收入、月发送 1–10 万封：继续 Resend Pro。$35 解决一切，别折腾。
3. 月发送稳定超过 10 万封，且邮件成本开始肉疼：评估迁到 AWS SES。迁移本身不难（都是 SMTP/API），难的是把退信 webhook、模板、统计这些 Resend 白送的东西自己补回来。我的判断线是：当 SES 每月能帮你省下超过 100 美金时，再动手迁。省 20 美金不值得搭进去一个周末。
4. 业务对"收不到邮件"零容忍（比如登录全靠邮箱验证码、金融交易通知）：直接 Postmark。它贵，但它的整个产品就是围绕"送达"构建的：独立的 Message Streams、严格的共享 IP 治理、45 秒内送达的实测口碑。这种场景下，一次登录失败的用户流失，远比每月多花的几十美金贵。
5. 已有 AWS 全家桶、团队里有人玩过 SES：可以直接从 SES 起步，跳过 Resend。但要预留半天时间走完沙盒提额和 DKIM 配置。

还有一条容易被忽略的：别在多个服务商之间来回横跳。发信声誉是跟域名的，换服务商意味着换 IP 池，等于信用记录搬家，每次都要重新"养"。选定一家，至少用满三个月再评估。

三、DNS 三件套实战：SPF、DKIM、DMARC

这是整篇指南里最"动手"的部分，也是回报最高的部分。配齐这三条 DNS 记录，你的邮件在 Gmail 眼里就从"身份不明"变成"身份可验证"——这是进收件箱的入场券，不是加分项。用大白话讲：

• SPF：你在 DNS 里贴一张"授权名单"，声明哪些服务器可以代表你的域名发邮件。收件方查到发信 IP 不在名单上，就知道这封可能是伪造的。
• DKIM：给每封邮件盖一个数字签名（非对称加密），收件方用你公布在 DNS 里的公钥验签。签对了，说明邮件确实是你发的、且中途没被篡改。
• DMARC：告诉收件方"如果 SPF 和 DKIM 都没通过，你该怎么处理这封邮件"（直接扔掉？隔离？还是放行但给我打个报告）。同时它要求"对齐"——邮件头里的 From 域名必须和 SPF/DKIM 验证的域名一致，防止"挂羊头卖狗肉"。

三者的关系记住一句话：SPF 说"谁可以发"，DKIM 说"发的是不是我"，DMARC 说"冒充我的怎么办"。缺任何一个，你的发信身份都是瘸腿的。

实战：Cloudflare + Resend，15 分钟配完

假设你的域名是 yourapp.com，发信用子域名 send.yourapp.com（再次强调：用子域名发事务邮件，主域名留干净，这是隔离声誉最便宜的办法）。

第 1 步：在 Resend 控制台添加域名。登录 Resend → Domains → Add Domain，填 send.yourapp.com。它会给你三组 DNS 记录的值（DKIM 的公钥值是它生成的，每个账号不一样，下面示例里的 p=MIIB... 请替换成控制台实际给你的值）。

第 2 步：去 Cloudflare 添加三条 TXT 记录。Cloudflare 面板 → 你的域名 → DNS → Add record，类型都选 TXT：

记录 1（SPF）：
名称：send
内容：v=spf1 include:amazonses.com ~all

记录 2（DKIM）：
名称：resend._domainkey.send
内容：p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...（Resend 控制台给的完整公钥）

记录 3（DMARC，挂在主域名下）：
名称：_dmarc
内容：v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com; fo=1;

几点必须注意的细节，新手九成栽在这里：

• Cloudflare 添加记录时，名称只填主机部分（填 send 而不是 send.yourapp.com），它会自动补后缀。填成全称会导致记录变成 send.yourapp.com.yourapp.com，这是 DNS 配置里最经典的低级错误。
• 这三条记录的代理状态必须设为"仅 DNS"（灰色云朵）。开了橙色云朵（CDN 代理），TXT 记录会被 Cloudflare 吃掉，验证永远通不过。
• SPF 记录一个域名（含子域名）只能有一条。如果你已经有一条 SPF（比如给 Google Workspace 用的），不要再加一条，而是合并成一条：v=spf1 include:_spf.google.com include:amazonses.com ~all。两条 SPF 并存会导致验证直接失败——这是"我明明配了 SPF 为什么还不过"的头号原因。
• SPF 结尾用 ~all（软失败）而不是 -all（硬失败），至少在初期。硬失败配错一个字符，你自己的邮件会全军覆没；软失败给收件方留了余地。
• DMARC 策略从 p=none 起步，意思是"只给我打报告，别拦截"。跑两周，确认 rua 邮箱收到的报告里都是你自己的合法发送，再收紧到 p=quarantine，最后才是 p=reject。第一天就上 reject，等于给自己埋雷。

SPF/DKIM/DMARC 邮件安全认证流程图

第 3 步：回 Resend 点 Verify，等变绿。DNS 生效一般几分钟，Cloudflare 通常很快。变绿后发一封测试邮件到 Gmail，打开邮件 → 点右上角"..."→"显示原文"，看到 SPF: PASS、DKIM: PASS、DMARC: PASS 三个 PASS，这一关才算真正过了。别信控制台的绿勾，信 Gmail 原文里的三个 PASS。

代码：发一封"及格"的事务邮件

DNS 配好了，代码层面还有两条铁律：发件人用子域名，每封 HTML 邮件必须带纯文本版（只有 HTML 没有 text 的邮件是垃圾邮件过滤器的重点怀疑对象）。以 Resend 的 Node.js SDK 为例：

import { Resend } from 'resend';

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

await resend.emails.send({
  from: 'YourApp <noreply@send.yourapp.com>',  // 子域名 + 固定发件人
  to: user.email,
  subject: '请验证你的邮箱地址',
  html: '<p>点击下面的链接完成验证：</p><p><a href="https://yourapp.com/verify?token=xxx">验证邮箱</a></p>',
  text: '请访问以下链接完成验证：https://yourapp.com/verify?token=xxx',
});

如果你用 AWS SES（Python）：

import boto3
ses = boto3.client('ses', region_name='us-east-1')
ses.send_email(
    Source='YourApp <noreply@send.yourapp.com>',
    Destination={'ToAddresses': [user.email]},
    Message={
        'Subject': {'Data': '请验证你的邮箱地址'},
        'Body': {
            'Text': {'Data': '验证链接：https://yourapp.com/verify?token=xxx'},
            'Html': {'Data': '<p>验证链接：<a href="https://yourapp.com/verify?token=xxx">点击验证</a></p>'},
        },
    },
)

注意 from 的写法：YourApp <noreply@send.yourapp.com>——显示名是你的产品名，地址是子域名下的固定地址。发件人地址一旦确定就不要换。频繁更换发件人是声誉杀手；用户把 noreply@send.yourapp.com 加进通讯录，是最便宜的"加分"动作。

配错的典型症状对照表：出问题先查这里

症状	大概率原因	去哪里确认
Gmail 直接拒收，退信里有 550-5.7.26	SPF 或 DKIM 没通过，Gmail 判定身份不明	Gmail 原文看 Authentication-Results；检查 DNS 记录是否生效：dig TXT send.yourapp.com
能收到，但全进垃圾箱，Gmail 显示"via amazonses.com"	DKIM 没对齐或没配，Gmail 不认这个 From 是你的	Resend/Postmark 控制台重新 Verify 域名；确认 DKIM 记录的代理状态是灰色云朵
Outlook/Hotmail 全进垃圾箱，Gmail 正常	微软用自己的 SNDS 声誉系统；新域名/IP 在它那里初始分低	去 Microsoft SNDS 注册你的 IP/域名看声誉；Outlook 的问题通常靠"养"（小量、稳定、高打开率）解决，没有开关可拨
DMARC 报告里出现陌生的 SPF/DKIM 来源	有人在冒充你的域名发邮件，或者你忘了某个还在用的发送渠道	把合法渠道补进 SPF/DKIM；确认无冒充后把 DMARC 从 none 收紧到 quarantine
配了 DMARC p=reject 后自己的邮件被拒收	SPF/DKIM 对齐没做好就上了最严策略	立刻降回 p=none，用两周报告确认对齐无误再收紧
偶尔能收到、偶尔进垃圾箱，毫无规律	共享 IP 池里有"邻居"在发垃圾邮件，连累了你	联系服务商确认 IP 池健康度；量大后考虑独立 IP；Postmaster Tools 看域名声誉趋势是看"邻居问题"还是"自己问题"的分水岭

记住这个排查顺序：先看 DNS（三件套 PASS 了吗）→ 再看内容（标题、正文、链接）→ 最后看声誉（Postmaster/SNDS）。九成的问题死在第一步，别一上来就怀疑人生调模板。

四、进垃圾箱排查手册：一份二分排查清单

DNS 全 PASS，邮件还是进垃圾箱？别慌，也别乱改——乱改会把声誉越调越糟。按下面这份清单二分排查，一次只动一个变量，改完观察 48 小时再动下一个。清单按"从最常见到最隐蔽"排序：

第一组：发件身份（最高频）

• 发件人名称是真实产品名吗？不要用 no-reply、admin、notification123 这类"机器人味"名称。用户认的是产品名，过滤器也一样。
• 发件地址固定吗？验证邮件、密码重置、订单通知是否用的同一个地址？多个地址来回换，等于每封都在重新建立信任。
• 回复地址（Reply-To）有效吗？noreply@ 本身没问题，但最好配一个能收信的 Reply-To。用户回复验证邮件的比例不高，但"可回复"本身是信任信号。
• 检查邮件原文里的 Authentication-Results：SPF、DKIM、DMARC 三个 PASS 缺一不可，少一个就回第三章重配。

第二组：内容与结构

• HTML 和纯文本版本都有吗？只有 HTML 版是减分项；两者内容要一致，别 HTML 里一套、文本里另一套。
• HTML 里图片和文字的比例失衡吗？整封邮件只有一张大图、几乎没文字，是最经典的垃圾邮件特征。验证邮件这种功能型邮件，纯文本为主、少图甚至无图，到达率反而最高。
• 标题里有触发词吗？"免费"、"赚钱"、"限时"、全大写、连续感叹号——这些在事务邮件里出现就是自杀。验证邮件的标题就老老实实写"请验证你的邮箱地址"，别玩花样。
• 正文里的链接域名和发件域名一致吗？发件人是 send.yourapp.com，链接却指向某个短链或完全不相关的域名，过滤器会直接判定为钓鱼嫌疑。用自己的域名做跳转，哪怕多一次 301。
• 链接是 HTTPS 吗？HTTP 链接在 2026 年的邮件里出现，约等于举着"我很可疑"的牌子。
• 退订链接：事务邮件不要放营销式退订（用户没订阅过什么，退订谁？），但要在页脚写清楚"这是一封由你的账户操作触发的邮件"，并给出联系方式。画蛇添足的退订按钮反而会让过滤器困惑。

第三组：发送行为

• 退信率超过 2% 了吗？硬退（地址不存在）必须立刻从列表移除，同一个无效地址反复发是声誉自杀。服务商一般有自动 suppression list，确认它是开着的。
• 投诉率（点了"这是垃圾邮件"的比例）超过 0.1% 了吗？超过 0.3% Gmail 会直接限流。事务邮件投诉率高的唯一合理解释：有人在用你的注册接口轰炸别人的邮箱——去加验证码和频率限制。
• 发送量是平稳的还是脉冲式的？平时每天 50 封，某天突然 5000 封，这种脉冲在过滤器眼里和被盗号群发没有区别。大批量通知要排队错峰发。
• 新域名/IP 在"养声誉"吗？新域名前两周每天只发几十封、且收件人都是真实活跃用户，让打开率把初始分抬起来。别在新域名第一天就导 1 万个地址群发。

第四组：用 Google Postmaster Tools 看上帝视角

• 注册 Postmaster Tools（免费），把你的发信域名加进去。这是 Gmail 官方给你的"体检报告"，没有它你就是在盲飞。
• 看域名声誉（Domain Reputation）：High / Medium / Low / Bad 四档。从 High 掉到 Medium 是黄色警报，掉到 Low 就要停掉一切非必要发送、只保留事务邮件养回来。
• 看垃圾邮件率（Spam Rate）：用户点了"举报垃圾邮件"的比例。盯着 0.1% 这条线。
• 看身份验证通过率：SPF、DKIM、DMARC 的通过率曲线。如果某天突然下跌，说明 DNS 或发送配置被动过——先查这个，再查内容。
• 看送达错误（Delivery Errors）：区分是被拒收（rejected）、限流（rate limited）还是临时失败（temporary failure），三种错误的解法完全不同，别混在一起治。

这份清单的底层逻辑是：过滤器的问题永远先从"身份"查起，再查"内容"，最后查"行为"。顺序反了，你会在模板措辞上浪费一下午，而真正的病根是 DNS 里少了个字符。

五、合规底线：别在法务问题上翻车

vibe coder 最容易有的错觉是"事务邮件不用管合规"。错。合规管的不是你"想不想营销"，而是"你发了什么、怎么发的"。

CAN-SPAM（美国）对事务邮件的要求

好消息：纯粹的事务邮件（订单确认、密码重置这类"完成交易必需"的内容）不受 CAN-SPAM 退订条款的约束。但红线在于别在事务邮件里夹带营销内容：密码重置邮件里顺手推一波"新功能 8 折"，这封邮件在法律上就变成了商业邮件，必须提供物理地址和退订机制。判断标准很简单：删掉营销部分，邮件还成立吗？不成立，就是事务邮件；成立但你想"顺便"营销，那就老老实实按商业邮件的规矩来。

GDPR（欧盟）对事务邮件的要求

事务邮件在 GDPR 下通常依据"合同履行"（比如用户注册了账号，你发验证邮件是履行合同的必要步骤），不需要单独的营销式同意。但这不意味着可以裸奔：

• 隐私政策里必须写清楚你会发哪些事务邮件、通过哪个服务商发送（数据处理者披露）。
• 邮件里尽量少放个人数据。验证链接用 token，别在 URL 里裸奔邮箱地址。
• 服务商选欧盟区数据中心或确认有标准合同条款（SCC）。Resend、Postmark、SES 都有相应的合规文档，选型时顺手确认一下，别等用户问起来再翻。
• 用户注销账号后，事务邮件必须停——"合同履行"的依据随着账号注销而消失。

AI 生成邮件模板时的措辞红线

vibe coder 写邮件模板，十有八九是让 AI 生成的。AI 写的模板有两类高危倾向，发布前必须人工过一遍：

• 反垃圾关键词：AI 特别爱用"免费"、"独家优惠"、"立即行动"、"保证"、"零风险"这类营销腔。出现在事务邮件里，每多一个词，进垃圾箱的概率就涨一分。给 AI 的 prompt 里就要写死："语气中性、功能性，禁用营销词汇"。
• 过度热情的格式：全大写标题、连续三个感叹号、"亲爱的用户！！！"——AI 觉得这样很亲切，过滤器觉得这是 2008 年的垃圾邮件。标题句首字母大写即可，正文陈述句为主。
• hallucinated 的链接和落款：AI 会编造根本不存在的"帮助中心链接"或把公司名写错。模板里的每一个链接、每一个落款，发布前人工点一遍——这是 vibe 流程里最不能省的一步。
• 别让 AI 写法律文本：隐私政策、服务条款、退订说明，用标准模板或找律师，别让 AI 现编。一封措辞错误的退订说明，比没有更糟。

收尾：上线前 10 分钟检查清单

如果你只能记住一张清单，记住这张。每次上线新项目，发第一封事务邮件之前，对着它打勾：

1. 事务邮件和营销邮件用了不同的子域名/通道。
2. SPF、DKIM、DMARC 三条记录已配，发测试邮件到 Gmail，原文里三个 PASS。
3. DMARC 策略是 p=none 起步，rua 邮箱能收到报告。
4. 发件人名称是产品名，地址固定，用子域名。
5. 每封 HTML 邮件都有对应的纯文本版本。
6. 服务商的退信 webhook / suppression list 已开启。
7. Google Postmaster Tools 已添加域名。
8. 免费版额度够上线当天用（不够就提前升级）。
9. 模板里的链接全是自己域名的 HTTPS，AI 生成的措辞人工过了一遍。
10. 隐私政策里写了事务邮件的发送说明。

最后说一句判断，可能有点逆直觉：邮件基础设施是你整个 vibe 项目里"最不 vibe"的部分，也是最值得"不 vibe"的部分。vibe coding 的精髓是把精力花在刀刃上——而邮件到达率，恰恰是那种"你感觉不到它存在，但它一出问题你第一个知道"的刀刃。花一个下午把这篇指南落地，换的是上线后每一天的安稳。这笔账，怎么算都值。