注册验证码、订单通知、密码找回这些邮件，很多团队一开始都直接用企业邮箱或自建服务器发送。量小的时候看不出问题，用户多了以后，邮件进垃圾箱、退信变多、发得稍快就被限流，这些问题会陆续冒出来。阿里云邮件推送就是为这类场景准备的，发信链路、域名认证和投递数据由平台提供，业务团队可以把精力放在邮件内容和触发逻辑上。
业务邮件为什么不能和办公邮箱混用
收件方判断一封邮件靠不靠谱，很大程度上看发信方的历史表现。办公邮箱平时的收发节奏是零散的人对人沟通，批量发送通知的模式完全不同。如果同一个域名既发员工往来邮件，又发大批量通知，一旦某类邮件被标记为异常，整个域名的投递都会受影响。专门的发信服务会维护自己的发信信誉，并提供速率控制和退信处理，能把这类风险隔开。
开通服务后先配发信域名
开通后，在控制台添加发信域名。建议使用独立子域名，比如 notice.example.com，只用于通知类邮件，不要直接拿主域名发送。这样即便某类邮件出了问题，影响也主要停留在子域名上，主域名的信誉不会被连累。
三类 DNS 记录要一起配
添加域名后，需要在 DNS 里配置几条记录，让收件方能确认邮件确实是你授权的服务器发出的。具体记录值以控制台给出的为准，三类的作用分别是：
- SPF：声明哪些服务器有权代表这个域名发信。
- DKIM：对邮件内容加签，收件方用公钥校验邮件有没有被改动。
- DMARC：规定校验失败时怎么处理，并能回传校验报告。
实际操作中最容易漏的是只配了 SPF。部分邮箱服务商对没有 DKIM 的邮件仍会比较谨慎，所以三条最好都配齐。DMARC 第一次配置时可以先设为只观察、不拦截的策略，看报告运行一段时间，确认合法发信都能通过后再逐步收紧。直接上强制策略，很可能把自己的正常邮件也拦下来。
触发类和营销类邮件分开发
发信地址一般会是 noreply@notice.example.com 这样的形式。这里有个容易忽略的点：验证码、订单状态这类触发式邮件对时效和到达率要求最高，活动推广、周报这类营销邮件则更容易引起投诉。两者混在同一个地址或子域名下，营销邮件的投诉会拖累验证码的送达。条件允许的话，至少用不同的发信地址，更稳妥的做法是拆成不同子域名。
模板和变量：把文案从代码里拿出来
设想一个小型电商团队，最开始由后端直接拼接 HTML 发送订单通知。每次改一句文案都要发版，偶尔还会碰到变量为空、排版错位的情况，排查起来很麻烦。
后来他们把称呼、订单号、物流信息等内容在控制台做成模板变量，后端只负责传值。文案调整交给运营在模板里完成，不必再走发版流程，每次修改也能先预览测试。这类改造本身不复杂，关键是先想清楚哪些内容是固定的，哪些是每封邮件都会变的。
主题行也值得花点时间。主题写得太空泛，或者堆满感叹号和促销词，容易被当成营销邮件处理。订单号这类很长的纯数字串，最好放在正文里，不要占据主题行。
接入方式怎么选
阿里云邮件推送支持 API、SDK 和 SMTP 等接入方式。新系统建议直接用官方 SDK 或 HTTP API，拿到的错误码和发送结果回调更完整，排查问题也更快。如果现有系统本来就通过 SMTP 发信，只需改服务器地址和认证信息，改动最小，适合先跑通，再逐步重构。
不管用哪种方式，代码里都要处理发送失败。限流、临时故障这类错误可以用指数退避重试，间隔逐步拉长，不要短时间内连续重试。地址无效这类永久性错误应当记录下来并停止重发，既避免浪费配额，也避免反复投递无效地址损害发信信誉。
送达率日常要盯的几件事
域名认证配好之后，送达率更多靠日常维护。下面几件事做起来不难，但长期不做，效果会慢慢打折：
- 定期清理无效地址和长期不打开的地址，硬退信的地址要及时从列表中剔除。
- 营销邮件必须有明确的退订入口，用户退订后要真正停止发送，不能只是改个标记。
- 避免短时间内集中发出大批量邮件，大促或活动前可以提前分批、错峰发送。
- 每周至少看一次投递报表和退信原因。退信突然增多时，先排查名单和内容，再考虑调整发送策略。
- 正文以文字为主，图片作辅助。整封邮件只有一张大图的情况，很容易被判为低质量邮件。
小结
阿里云邮件推送适合把业务邮件从临时方案迁到可管理、可监控的链路上。配置顺序上，先把发信域名、DNS 认证，以及触发类和营销类的拆分规划清楚，再用模板和接口把业务代码与文案解耦。上线之后持续查看投递数据，比一次配完就不管更能保证效果。
