业务邮箱与发信送达

先分清两件经常被混在一起的事：

• 业务邮箱：你用来收发工作邮件的地址，比如回复用户咨询、注册平台账号。
• 发信服务：你的产品自动发出的邮件，比如登录验证码、订单通知。

它们用的是不同的服务、不同的配置、不同的验收方式。一个配好了不代表另一个能用。

快速版

1. Demo 阶段个人邮箱够用，不要因为邮箱卡住产品验证。
2. 开始注册支付、云服务、合作平台时，就该用自己域名的邮箱。
3. 至少规划 support@、billing@、security@，加一个不公开的管理员地址。
4. 系统邮件用专门的发信服务，不要用业务邮箱账号发。
5. SPF、DKIM、DMARC 三个都要配，缺一个就容易进垃圾箱。
6. "发送成功"不等于送达，必须用真实的目标邮箱实测。
7. 国内用户为主的话，发信服务的选择要按国内主流邮箱的送达率来定。

什么时候需要业务邮箱

出现下面任一情况就该配：

• 准备正式对外发布
• 要联系用户、合作方、媒体
• 注册支付、云服务这类正式平台账号
• 产品要发验证、订单、通知邮件
• 想用品牌地址做对外入口

只做 Demo 拿反馈的话，个人邮箱先用完全可以。

但注册关键平台账号这件事要早点处理。用个人邮箱注册了支付商户、云服务、域名，后面想转成团队管理会很麻烦，而且个人邮箱一旦出问题，账号恢复路径也跟着断了。

地址怎么规划

最后一条是重点。管理关键平台的那个地址不要出现在网站上、不要用来对外通信。 它是你所有账号的恢复入口，暴露它等于给攻击者一个明确目标。

security@ 值得单独设一个。安全研究者发现问题时会先找这个地址，找不到就可能直接公开。

两类服务分别怎么选

业务邮箱（收发工作邮件）

判断维度：

• 是否和你已有的协作工具打通
• 能建几个地址、几个别名
• 是否支持标准协议（方便以后迁走）
• 域名放在哪个 DNS 服务商，配置是否顺畅

域名服务商自带的邮箱转发功能，对"只想有个品牌地址收信"的需求通常够用。要正式收发和多人协作，再上完整的邮箱服务。

发信服务（产品自动发的邮件）

判断维度只有一个真正重要：目标用户的邮箱能不能收到。

这里有一条国内特有的坑：面向国内用户时，不要默认使用面向海外市场的发信服务。 国内用户大量使用 QQ、163、126 这类邮箱，部分海外发信服务对这些邮箱的送达率明显偏低——邮件不是被退回，而是直接进垃圾箱或被静默丢弃，你在服务商后台只能看到"已发送"。

国内为主的场景，优先选国内云服务商的邮件推送服务。但无论选哪家，都必须自己实测，不要相信任何人的结论包括这一页。

SPF、DKIM、DMARC

这三个是发信认证。缺了就容易被判垃圾邮件。

配置流程通常是服务商给你具体的记录值，你加到 DNS 里，然后在服务商后台点验证。具体记录值以你的服务商控制台为准，别抄网上的示例值。

DMARC 有一个实践顺序值得注意：先用最宽松的策略上线，观察一段时间再收紧。 一上来就设成严格拒绝，如果有某个发信来源你忘了加进 SPF，那部分邮件会直接被拒收，而且你可能几周都发现不了。

送达实测

这是这一页最重要的部分。服务商后台显示"发送成功"，只说明它把邮件交出去了，不说明用户看到了。

配置完成后做这个测试：

测试日期：____________
发信服务：____________

收件方              收到？   在收件箱还是垃圾箱？   延迟
QQ 邮箱             ___      ___                  ___
163 / 126           ___      ___                  ___
Gmail               ___      ___                  ___
Outlook / Hotmail   ___      ___                  ___
企业邮箱（对方公司） ___      ___                  ___
iCloud              ___      ___                  ___

"在垃圾箱"要算作失败。 用户不会去垃圾箱找验证码。

如果某个邮箱收不到或进垃圾箱，检查顺序：

1. SPF、DKIM、DMARC 是否都通过验证
2. 发件域名是否是新域名（新域名信誉低，需要时间积累）
3. 邮件内容是否触发了垃圾特征（大量链接、纯图片、敏感词）
4. 发件地址的显示名和实际地址是否一致

验证码邮件的额外要求

验证码类邮件对延迟敏感。超过一分钟到达，用户已经走了。

测试时把延迟记下来，不只记"是否收到"。如果某个邮箱经常延迟几分钟，考虑给用户提供备用登录方式。

一个我们自己的教训

我们的邮件模块在没有配置发信服务时不报错，而是把验证码打印到服务端控制台，方便本地开发。

生产服务器上也没配发信服务——结果是登录页完全正常，用户点"发送验证码"看到成功提示，验证码只出现在容器日志里。 没有任何报错，也没有任何页面提示。

这个问题的性质不是"邮件没配好"，是"配置缺失被降级掩盖了"。处理方式见环境变量与密钥管理里的降级章节：生产环境缺少必填配置时应该拒绝启动，而不是悄悄降级。

渐进路线

不要一开始就配一整套。

1. 验证阶段：个人邮箱收反馈，够用。
2. 买了域名：先配一个品牌联系地址（域名商的转发功能就行）。
3. 要发系统邮件：接发信服务，配齐三个认证记录，做送达实测。
4. 开始收费或多人协作：上完整的业务邮箱服务，规划好地址分工。

不要因为邮箱没配好就卡住产品验证。 但也别等到用户登录不了才想起来这件事。

常见卡点

验收标准

• 关键平台账号用的是自己控制的、不公开的管理员地址
• support@、billing@、security@ 已规划并能收信
• SPF、DKIM、DMARC 三项都在服务商后台验证通过
• DMARC 从宽松策略开始，并列全了所有发信来源
• 送达实测表填完，六类收件方都在收件箱而不是垃圾箱
• 记录了验证码邮件的实际延迟
• 生产环境缺少发信配置时会拒绝启动，不会静默降级
• 如果登录依赖邮件，有备用登录方式

本章动作

填完上面那张送达实测表。

至少覆盖 QQ、163、Gmail 三个，并且把邮件是进了收件箱还是垃圾箱记下来。只写"收到了"没有用，进垃圾箱的验证码等于没发。

下一步

1. 域名、DNS 与 HTTPS——MX 和 TXT 记录加在哪
2. 环境变量与密钥管理——为什么缺配置不该静默降级
3. 生产环境验收——上线前的完整检查
4. 用户支持怎么做——support@ 收到信之后

来源

• SPF / DKIM / DMARC 的具体记录值以你的邮件服务商控制台为准，本页不提供示例值
• 各发信服务对国内邮箱的送达率请自行实测（核查日期 2026-08-31）