注册验证码、订单通知、密码重置这类事务邮件，对到达速度和能否进收件箱都有很高要求。周报、活动通知这类营销邮件则更看重内容和发送节奏。阿里云邮件推送（DirectMail）提供 SMTP 和 API 两种接入方式，两类邮件都能承接。这篇文章按实际落地的顺序来讲：先配置，再看两个案例，最后梳理影响送达率的几个控制点。
一、为什么不直接用企业邮箱发信
不少团队起步时会用企业邮箱或个人邮箱群发通知，量小的时候确实能跑。业务涨上来后，问题会陆续出现：发信量有上限，退订和投诉没有统一入口，发信地址和业务域名对不上，邮件也更容易被当成垃圾邮件。专用的邮件推送服务把发信域名、发信地址、退信处理和数据统计放在一处管理，规模变大后会省心很多。
二、开通与域名配置
正式发信前要做三件事。先在控制台开通邮件推送，创建发信域名；再到域名的 DNS 里添加 SPF 和 DKIM 记录，DMARC 策略也建议一并配上；最后创建发信地址，把事务类和营销类分开。
这几条认证记录各管一件事。SPF 声明哪些服务器有权代表本域名发信，DKIM 用数字签名证明邮件内容没有被改动，DMARC 告诉收件方认证失败的邮件该怎么处理。缺任何一条，入箱率都会受影响。还有一个常见的坑：DNS 记录改完不会立刻生效。有的团队配完就开始群发，前几批邮件被拒收，排查半天才发现是记录还没传播开。
配置检查清单
- 发信域名在控制台显示验证通过，状态正常
- SPF 只保留一条记录，并确认其中包含阿里云的发送服务器。多条 SPF 记录会导致校验失败，需要合并成一条
- DKIM 选择器已添加，并在控制台点击校验通过
- DMARC 先设为 p=none，观察一两周的报告，确认合法发信都能通过认证后，再逐步收紧到 quarantine 或 reject
- 发信地址尽量使用能收回复的邮箱。全部使用 noreply 地址时，用户遇到问题无处反馈，只能直接点举报
三、案例一：电商订单通知
某中型电商平台每天有数万笔订单，原先由自建邮件服务器发送付款成功、发货、物流更新等通知。高峰期经常延迟，部分邮件掉进垃圾箱，客服收到大量“没收到通知”的咨询。
迁移到阿里云邮件推送后，团队做了三处调整。事务邮件和营销邮件拆到不同的发信域名下，营销邮件的投诉就不会拖累订单通知的信誉。订单系统通过 API 接入，发送失败的请求按指数退避重试，每封邮件的 MessageId 都记录下来，出了问题可以顺着查。模板里加上订单号和清晰的品牌标识，用户更容易认出这是正常通知，不会当成钓鱼邮件。
运行一个月后，事务邮件的送达情况明显改善，“没收到通知”的咨询也少了。不过送达效果还要看收件方策略、内容质量和发信历史，单靠换服务不能保证结果。域名分层和认证配置齐全，是把这件事做稳的前提。
四、案例二：SaaS 产品的注册验证与营销分离
一家 B 端 SaaS 公司在增长期遇到另一个问题：市场部的产品周报和用户注册验证码共用同一个发信地址。某期周报里链接较多，不少用户把它标成了垃圾邮件，验证码的送达率跟着下降，新用户注册转化受到影响。
之后，团队把发信拆成三层。验证码和密码重置走独立的事务域名，通过 API 实时发送；产品通知和周报走营销域名，严格按用户的订阅偏好发送；系统公告用第三个地址。三个域名各自监控退信率和投诉率。营销发送前，团队还定了两条规则：退订链接必须随时可用，长期不打开邮件的地址定期清出名单。
这个案例的价值在于拆分本身。哪类邮件出了问题，只影响那一类，排查范围也清楚。
五、影响送达率的关键点
两个案例里反复出现的是名单质量。只向明确同意接收的用户发送，硬退信和投诉及时处理，名单干净，其他问题也好查。其次是发送节奏。短时间内集中发出大量邮件容易触发限制，新域名尤其要慢慢加量，别一上来就群发。内容方面，少放短链接和整张图片的大段排版，标题别写得夸张，正文最好同时提供纯文本版本。最后是看数据：退信率、投诉率、打开率定期查看，哪个指标突然变化，就先停下来找原因。
六、常见问题
邮件被退回怎么办？
先分清硬退信和软退信。硬退信一般是地址不存在或域名无效，应直接从名单里删除，否则只会继续拉低发信信誉。软退信多是邮箱已满或对方服务暂时不可用，按重试策略再发即可。退信日志里的原因码是排查的主要依据，别只看到“失败”两个字就下结论。
要不要为每个业务单独建域名？
没必要拆得太细。事务和营销分开，两个主域名就能覆盖大部分场景。域名越多，DNS 和监控要维护的东西越多，漏配一条记录的概率也越高。
配置本身不复杂，难的是前期把域名规划好、认证记录一次配全、名单保持干净。正式群发前，可以先拿一小批邮件分别发到几个常用邮箱，看看收件箱、垃圾箱和促销标签各占多少，再决定放量的节奏。
