注册邮件进了垃圾箱，等于没有注册：vibe 项目的交易邮件送达实战

最贵的 bug，是用户根本没看到的那封邮件

你的 vibe 项目上线了，用户注册了，注册验证邮件发出去了——然后就没有然后了。用户没收到邮件，无法完成验证，无法登录，无法付费。你查日志，邮件服务商显示“已发送”，状态是 delivered。你以为是用户邮箱的问题，用户以为是你的产品坏了，最后用户走了。真相往往是：邮件确实发出去了，但被收件方判定为垃圾邮件，躺在垃圾箱里，或者被直接拒收了。更糟的是，你永远不会收到用户的报错，因为“没收到邮件”的用户通常不会再回来告诉你，他们只会默默流失。交易邮件（注册验证、密码重置、订单确认、登录提醒）不是产品的附属功能，它是产品本身：验证邮件不到，用户就等于没有注册；密码重置邮件不到，用户就等于被锁在门外。

先划清边界，因为站内已经有几篇容易混淆的邻近指南。通知系统实战讲的是产品内的通知与推送——应用内消息、推送提醒、通知偏好设置，解决的是“用户在产品里怎么收到提醒”。本篇讲的是电子邮件的送达本身——邮件从你的服务器出发，经过发件方认证、经过收件方过滤、最终出现在收件箱里（而不是垃圾箱里）的全过程。两者交界在“用户偏好”上，但核心问题完全不同：通知系统解决的是“提醒什么、什么时候提醒”，送达解决的是“邮件能不能被看见”。另外，本篇也不讲营销邮件——群发、订阅、退订、打开率优化是另一套打法；交易邮件的特点是“一对一、由用户行为触发、必须到达”，它的送达标准比营销邮件严得多，也重要得多。

邮件送达的三道关：认证、声誉、内容

第一道关是认证，收件方用它判断“这封邮件真的是你发的吗”。三个协议必须配齐，缺一个都会扣分。SPF（Sender Policy Framework）是在你的域名 DNS 里声明“哪些服务器可以替我发邮件”；如果你用 Resend、SendGrid、Amazon SES 这类服务发邮件，却没有把它们的服务器写进 SPF，收件方就会怀疑这封邮件是冒充的。DKIM（DomainKeys Identified Mail）是发件服务用私钥给每封邮件签名，收件方用你 DNS 里的公钥验证签名——签名对不上，邮件就不可信。DMARC 是在前两者基础上的策略声明：告诉收件方“如果 SPF 或 DKIM 都没通过，你应该怎么处理这封邮件（仅报告、隔离到垃圾箱、直接拒收），以及把报告发到哪里”。很多 vibe 项目的现状是：SPF 配了、DKIM 没配、DMARC 根本没听说过——这种“配了一半”的状态比完全没配更危险，因为它会让你误以为自己已经安全了。

配齐认证之后，要验证而不是假设。三个免费工具应该成为你上线检查清单的一部分：用邮件服务商提供的 DNS 检查功能确认三条记录都已生效（注意 DNS 传播需要时间，刚改完就测可能会误判）；给自己发一封测试邮件，到 Gmail、Outlook、QQ 邮箱各看一次——它进了收件箱还是垃圾箱；查看 DMARC 汇总报告（发到你指定的报告邮箱），报告里会告诉你哪些服务器在用你的域名发邮件、有没有没通过认证的来源。DMARC 策略要分阶段收紧：先从 p=none（只报告、不采取行动）开始，观察一到两周报告、确认没有合法的发件来源被漏掉，再收紧到 p=quarantine（隔离），最后才是 p=reject（拒收）。一上来就设 p=reject，等于在还没确认发件来源清单完整的情况下，就让收件方帮你拒收可能合法的邮件。

第二道关是声誉，收件方用它判断“这个发件方过去表现怎么样”。声誉的核心是发件域名和发件 IP 的历史：退信率高、被用户标记为垃圾邮件的次数多、短时间内突然大量发信，都会拉低声誉。这里有一个 vibe 项目特别容易踩的坑：交易邮件和营销邮件共用同一个域名、甚至同一个发件子域名。一旦某次营销群发被大量用户标记为垃圾邮件，交易邮件的声誉也会跟着受损——验证邮件进垃圾箱，就是从这里开始的。正确做法是分离：交易邮件用一个专门的子域名（比如 mail.yourapp.com 或 notify.yourapp.com），营销邮件用另一个；两个子域名的 SPF、DKIM、DMARC 各自独立配置，互不牵连。分离的成本只是一次 DNS 配置，收益是“营销活动出问题时，注册和密码重置不受影响”。

第三道关是内容，收件方用它判断“这封邮件看起来像不像垃圾邮件”。交易邮件的内容原则是“越简单越好”：发件人名字用产品名而不是个人名或 noreply 这种冷冰冰的地址（noreply 本身就会让一些过滤器加分扣分，而且用户真的回复时没人处理）；主题写清楚这封邮件是干什么的——“请验证你的邮箱”比“欢迎来到某某”更容易被正确分类；正文只放一件事、一个链接、一个按钮，不要在验证邮件里顺带塞产品推荐、社交链接、 unsubscribe 之外的营销内容；链接的域名要和发件域名一致，不要出现短链接、跳转链接——过滤器对“邮件里藏着一个不认识的短链接”非常敏感。图片能少则少：纯图片邮件、图片里嵌文字、图片链接指向第三方图床，都是垃圾邮件的典型特征；交易邮件最好以文字为主，链接用完整的、可读的 URL。

从“已发送”到“已送达”：你必须监控的四个指标

邮件服务商后台的“已发送”不等于送达，你需要盯四个指标。第一个是退信率（bounce rate）：硬退（地址不存在、域名不存在）超过 2% 就要警惕，说明你的注册流程可能在收集无效地址——注册时做一次邮箱格式校验、发送验证邮件前先确认地址不是一次性邮箱，能挡掉大部分硬退。第二个是垃圾邮件投诉率（spam complaint rate）：用户点“这是垃圾邮件”的比例，超过 0.1% 就已经是危险信号——对交易邮件来说，投诉往往不是因为内容，而是因为用户“没印象注册过”或者“收到了重复的邮件”，这两种情况都要从产品流程上修，而不是从邮件内容上修。第三个是打开率与点击率：交易邮件的打开率应该显著高于营销邮件，如果验证邮件的打开率突然下滑，先查是不是进了垃圾箱，而不是怀疑用户不感兴趣。第四个是送达延迟：从“用户点击注册”到“邮件出现在收件箱”的时间，超过一分钟用户就会开始怀疑、重复点击、甚至重新注册——重复发送又会进一步拉低声誉，形成恶性循环。

监控之外，还要处理两类“沉默的失败”。第一类是被收件方静默丢弃的邮件：有些收件方对可疑邮件不是退回、也不是放进垃圾箱，而是直接丢弃——你的服务商后台显示 delivered，用户却什么都没收到。对付这种情况的唯一办法是“闭环验证”：在产品里给用户一个“我没收到邮件，重新发送”的入口，并且记录重新发送的频率——如果某个邮箱服务商的用户频繁点重新发送，说明你的邮件在那个服务商那里有系统性问题，要单独排查。第二类是退信处理：硬退的地址要自动从发送列表里移除（对交易邮件来说，是标记该用户“邮箱无效”，下次不再重复发送验证邮件），软退（邮箱满了、服务器临时故障）可以重试几次，但重试要有上限和退避间隔，无限制重试只会进一步损害声誉。

一份可以直接抄的上线检查清单

上线前，按这个顺序逐项打勾。第一，域名与认证：交易邮件专用子域名已创建；SPF 已包含你实际使用的发件服务；DKIM 已启用且签名验证通过；DMARC 已设为 p=none 并指定了报告邮箱。第二，发件身份：发件人名字是产品名，发件地址是交易子域名下的地址，回复地址有人处理（至少是能收到、能转交的邮箱，而不是 noreply 黑洞）。第三，内容检查：每类交易邮件（验证、密码重置、订单确认、登录提醒）各发一封测试邮件到 Gmail、Outlook、QQ 邮箱，确认全部进收件箱；正文只放一件事、一个主链接；没有短链接、没有第三方图床图片、没有营销内容夹带。第四，流程检查：注册后验证邮件在 60 秒内到达；“重新发送”入口存在且有频率限制（比如 60 秒内只能点一次）；密码重置链接有有效期（比如 1 小时）且用过一次即失效；用户修改邮箱后，旧邮箱会收到提醒、新邮箱需要重新验证。

上线后，每周看一次四个指标（退信率、投诉率、打开率、延迟），每月看一次 DMARC 汇总报告。DMARC 策略按 p=none → p=quarantine → p=reject 的节奏收紧，每次收紧前先确认报告里没有合法来源被漏掉。营销邮件上线时，单独走一遍同样的检查清单，用营销专用子域名，不要复用交易子域名的配置。最后记住一条原则：交易邮件的送达不是“发出去就完事”，而是“用户能看见、能点开、能完成操作”才算完事。验证邮件的送达率每提高一个百分点，注册转化率就实实在在地提高一个百分点——这可能是你的 vibe 项目里投入产出比最高的优化，因为它修的不是某个功能，而是所有功能共同的入口。

常见故障排查：邮件没到时，先查这五处

用户说“没收到验证邮件”，不要先怀疑用户，先按这个顺序排查。第一处，查你的发件记录：这封邮件到底有没有发出、发件服务商返回的状态是什么、是不是被你的应用逻辑拦住了（比如“同一邮箱 24 小时内只能发一次验证邮件”这种限流规则把正常用户也拦住了）。第二处，查收件方的垃圾箱和“推广”“社交”这类分类标签：很多邮件不是没到，而是被分类到了用户不常看的标签页里——让用户在垃圾箱和所有标签页里搜一下你的产品名，往往就能找到。第三处，查域名认证状态：SPF、DKIM、DMARC 有没有过期、有没有被误删——域名续费、DNS 迁移、换发件服务商都可能悄悄破坏认证，而你的应用不会因此报错，只会默默开始进垃圾箱。第四处，查该邮箱服务商的整体情况：是不是只有 Gmail 用户出问题、还是所有服务商都出问题——前者指向某个服务商的过滤策略变化，后者指向你自己的认证或声誉出了问题。第五处，查内容变化：最近有没有改过验证邮件的模板、加过图片、换过链接域名——内容变化是送达率突然下滑最常见的原因之一，而它最容易被忽略，因为“只是改了个模板”听起来不像会出问题。

选发件服务商时，问五个问题再决定。第一，它支不支持你需要的认证配置（SPF、DKIM、DMARC 的设置是不是图形界面就能完成，还是要手动拼 DNS 记录）？第二，它有没有专门的交易邮件通道，还是交易邮件和营销邮件走同一个队列（走同一个队列意味着营销高峰会拖慢交易邮件的送达速度）？第三，它的退信、投诉、打开数据是不是按邮件类型分开统计，还是混在一起只能看总数（混在一起的数据对交易邮件毫无指导意义）？第四，它有没有 Webhook 或 API 能让你实时知道“这封邮件被退回了、被标记为垃圾邮件了”，而不是等你每周去后台翻报表？第五，它的免费额度够不够你跑到有收入的时候——交易邮件的量是跟着用户量走的，免费额度用完就断供，等于在用户增长最关键的时候掐断注册入口。五个问题问完，答案最好的那个，不一定是最便宜的那个，但一定是让你在半夜少接一次告警的那个。

分离清单：交易邮件与营销邮件为什么必须分开走

分离不只是换个子域名，而是一整套配置的分离。发件子域名分开：交易邮件用 notify 开头的子域名，营销邮件用 news 或 marketing 开头的子域名，两个子域名的 DNS 记录各自独立，改一个不会影响另一个。发件服务配置分开：如果用同一个服务商，也要在服务商后台建两个独立的发送域名、两个独立的 API 密钥——密钥分开的好处是，营销系统的密钥万一泄露、被滥用，交易邮件的发送不会跟着停。监控报表分开：退信率、投诉率、打开率要按邮件类型分别统计，混在一起的总数对交易邮件毫无意义——营销邮件的打开率天然偏低，混在一起会把交易邮件的真实送达率拉低，让你误以为交易邮件出了问题，或者反过来掩盖交易邮件的真实问题。退信处理分开：营销邮件的硬退地址可以直接移出订阅列表，交易邮件的硬退地址则要标记用户状态、触发产品内的提醒（比如用户下次登录时提示“你的邮箱似乎无效，请更新”），而不是悄悄删掉。

分离之后，还要定期做一次“交叉污染检查”：看看有没有营销邮件误用了交易子域名、有没有交易邮件误用了营销模板、有没有某个新上线的功能（比如“每周精选”这种半营销半通知的邮件）不知道该走哪条通道。判断标准很简单：这封邮件是不是由用户的一个具体行为触发的、用户是不是在等它、收不到会不会导致用户无法使用产品——三个答案都是“是”，走交易通道；只要有一个是“否”，就走营销通道，接受更宽松的送达标准。这个判断做一次，写进团队的邮件发送规范里，以后每个新邮件类型上线时先过一遍这个判断，而不是每次都临时决定。临时决定最容易犯的错误，就是把一封“看起来像通知、其实是营销”的邮件塞进交易通道，然后在某次群发后发现验证邮件的声誉被拖垮了。

最后再强调一次：交易邮件送达的优化没有终点，只有节奏。上线前按清单配齐认证、分离域名、测遍主流邮箱；上线后每周看指标、每月看报告、按节奏收紧策略；每次新增邮件类型先过“交易还是营销”的判断，再进对应的通道。这套节奏跑起来之后，送达问题会从“半夜被告警惊醒的事故”变成“报表里每周看一眼的数字”——而这正是独立开发者最需要的状态：把精力留在产品本身，而不是花在追一封不知道去哪了的邮件上。