在企业运营里，订单确认、密码重置、账单通知这类邮件一旦发不出去或进了垃圾箱，用户找不到，客服就会接到电话。阿里云邮件推送（Direct Mail）就是为这类发信需求准备的云端服务。
它主要有两种用法。触发类邮件由系统事件驱动，比如注册验证码、订单通知，对时效和稳定性要求高。批量邮件适合促销、行业资讯等群发场景，更看重退订管理和发送节奏。
和自己搭邮件服务器相比，云端服务省下的主要是三类工作：
- 送达率：服务商长期维护发信 IP 的信誉，并对接主流邮箱的反垃圾机制。自建服务器的新 IP 要从零积累信誉，这件事并不快。
- 运维：SMTP 服务部署、IP 预热、黑名单排查由服务商处理，团队不必每次出问题都从头查。
- 数据：投递、打开、点击、退订都有统计，能看出哪类邮件出了问题。
二、接入前的准备工作
正式发信前有几项基础配置，它们直接决定邮件能不能进收件箱。
1. 配置发信域名
建议用独立子域名作为发信域名，比如 mail.example.com，不要直接用企业主域名。原因很实际：如果某个发信域名因为投诉率高受到影响，主域名下的业务邮箱仍能正常收发。
域名配置完成后，还要在 DNS 里添加 SPF、DKIM 和 DMARC 记录。SPF 声明哪些服务器有权代表这个域名发信，DKIM 给邮件加上数字签名，DMARC 规定验证失败时怎么处理。三条记录配齐，邮件被判为伪造的可能性会低很多。漏掉其中一条，常见结果是邮件被放进垃圾箱，而发送端通常不会直接报错，排查起来很费时间。
2. 创建发信地址
在控制台创建发信地址时，按用途分开。noreply@ 用于系统通知，service@ 用于客服回复。用途分开后，哪类邮件出了问题、该查哪个地址，一眼就能看出来。
3. 获取访问凭证
调用 API 或 SMTP 时需要 AccessKey 做身份验证。建议为邮件服务单独建一个 RAM 子账号，只授予必要权限。主账号密钥一旦泄露，影响面会很大。AccessKey 不要写进代码仓库，通过环境变量或密钥管理服务读取。
三、发送方式与代码示例
阿里云邮件推送支持 SMTP 和 API 两种接入方式。SMTP 上手快，适合已有邮件客户端或老系统改造。API 更适合和业务系统深度集成，能拿到更细的发送结果和错误码，出问题时定位更快。
下面是用 Python 通过 SMTP 发送一封通知邮件的例子，账号和密码从环境变量读取：
import os
import smtplib
from email.mime.text import MIMEText
from email.header import Header
SMTP_HOST = "smtpdm.aliyun.com"
SMTP_PORT = 465
SMTP_USER = os.environ["ALI_DM_SMTP_USER"]
SMTP_PASS = os.environ["ALI_DM_SMTP_PASS"]
def send_notice(to_addr: str, subject: str, body: str) -> None:
msg = MIMEText(body, "html", "utf-8")
msg["Subject"] = Header(subject, "utf-8")
msg["From"] = SMTP_USER
msg["To"] = to_addr
with smtplib.SMTP_SSL(SMTP_HOST, SMTP_PORT, timeout=10) as server:
server.login(SMTP_USER, SMTP_PASS)
server.sendmail(SMTP_USER, [to_addr], msg.as_string())
if __name__ == "__main__":
send_notice(
to_addr="user@example.com",
subject="您的订单已确认",
body="<p>您好，您的订单 <strong>A20240501</strong> 已确认，预计 3 个工作日内发货。</p>",
)
代码使用了 SSL 连接并设置超时，避免网络异常时进程长时间卡住。放到生产环境，还需要补上失败重试、日志记录，并对发送频率做限流。
四、案例：某跨境电商的邮件通知改造
某中型跨境电商此前用自建邮件服务器发订单通知，日常发送量约 20 万封。业务增长后，问题陆续出现：部分 Gmail 用户的邮件进了垃圾箱，服务器偶尔被拉进黑名单，运维同事还要花大量时间处理退信。
团队评估后决定迁移到阿里云邮件推送，改造分四步：
- 新建子域名 notice.example-shop.com 作为发信域名，完成 SPF、DKIM、DMARC 配置。
- 订单确认、发货提醒、退款通知三类触发邮件切换到 API 接口，原有模板保留。
- 按业务线拆分发信地址，客服回复和系统通知分开。
- 接入投递数据看板，每周复盘退信和投诉情况。
上线三个月后，送达率从约 91% 提升到 98% 以上，因服务器问题引发的用户投诉明显减少。运维同事也不必再定期处理 IP 信誉问题，精力可以回到业务本身。这个结果有两个前提：DNS 配置完整，邮件内容质量过关。换一家服务商本身并不能保证同样的效果。
五、使用中的注意事项
- 内容合规：营销邮件要提供明确的退订入口，并遵守目标市场的相关规定。
- 名单管理：长期不互动的地址要定期清理，否则会拖低整体送达率。
- 发送频率：同一用户短时间内收到多封相似邮件，容易被标记为骚扰。
- 监控告警：给退信率、投诉率设置阈值，超过时及时暂停发送。
六、选型与上线建议
如果团队想先试水，可以从验证码或订单通知这类小场景开始。域名认证、模板和监控都跑通之后，再考虑扩展到营销邮件。发信域名、凭证管理、数据监控这三件事做扎实，多数问题在早期就能避开。
