2026 Cloudflare Email Service SMTP 与 Workers binding 怎么选？

先按运行位置筛选接入候选

Cloudflare Email Service 提供 SMTP、Workers binding 和 REST API；选择时先问邮件代码在哪里运行、现有代码使用什么协议，而不是先比较接口名。

Workers binding 并不是把 SMTP 凭据换个地方存放：它要求应用通过 Worker 的 send() 接口调用。REST API 则通过 HTTP 请求接入，适合既不运行在 Workers、也不想继续维护 SMTP 客户端的后端。官方文档分别说明了 binding 和 REST API 的调用边界。（Workers API 文档）

对照 SMTP 限制，估算现有代码要改多少

不运行在 Workers 上的项目可以用 Cloudflare Email Service SMTP。官方 SMTP 文档面向支持 SMTP 的应用与客户端，包括 Nodemailer；但能否少改代码，取决于现有程序能否使用指定的 TLS、认证方式及发件域名配置。（Cloudflare SMTP 文档）

当前官方列出的 SMTP 端点是 smtp.mx.cloudflare.net:465，使用隐式 TLS；认证支持 PLAIN 或 LOGIN，用户名须为字面值 api_token，密码为具备 Email Sending: Edit 权限的 Cloudflare API token。出站 SMTP 不支持明文连接或 587 端口的 STARTTLS。

如果项目用 Nodemailer SMTP，连接参数可按官方客户端选项这样设置：

const transporter = nodemailer.createTransport({
  host: "smtp.mx.cloudflare.net",
  port: 465,
  secure: true,
  auth: {
    user: "api_token",
    pass: process.env.CF_API_TOKEN,
  },
});

Nodemailer 的 secure: true 表示连接一开始就使用 TLS，适用于 465 端口；这只是传输配置示例，仍需在实际发信中确认发件域名、凭据和消息内容均符合服务要求。（Nodemailer SMTP 配置说明）

实际迁移时至少检查三处：应用运行环境能否连到指定端点；凭据配置是否支持将用户名固定为 api_token、并安全注入 token；发件地址所属域名是否已在 Email Sending 中配置。官方文档还要求使用 Cloudflare DNS；这些前置条件不满足时，单换 SMTP 主机名并不能完成接入。（Cloudflare 发信前置条件）

反过来，如果发信逻辑本就在 Worker 中，改成 SMTP 往往意味着额外维护一套 SMTP 客户端配置，而不是天然减少改造。此时先试 binding；若原有邮件模块与 Worker API 难以衔接，再比较 REST API 或调整邮件模块边界。binding 的发送结果会提供 messageId，但仍需按业务需要处理调用错误。

收紧凭据与收件范围，避免测试发到真实用户

SMTP 的 token 是真实发信凭据。Cloudflare 文档提醒，持有该 token 的人可以从对应账户已接入的发件域发送邮件。因此，不要把 token 写进仓库、客户端代码或测试报告；应通过后端密钥配置注入，并为测试与生产分别管理凭据和发件配置。

Workers binding 可在配置中限制允许的收件地址、发件地址，或固定单一目标。为测试环境配置固定收件目标或收件白名单，能降低测试代码误向客户地址发信的风险；测试配置也不要直接复用生产目标名单。（Workers binding 配置说明）

分清调用结果、服务日志和收件端实收

邮件验收不能只看代码有没有报错。Cloudflare 活动日志中的 Sent 表示邮件已被接受并排入发送队列；Delivered 表示已成功交付到收件方邮件服务器。后者仍不等于邮件一定显示在主收件箱：接收方服务可能将其放入垃圾邮件或其他文件夹。（活动日志状态说明）

因此，SMTP 返回成功不能单独证明测试邮件进入收件箱。Cloudflare 对 Delivered 的定义是收件方邮件服务器接受邮件；要验证注册邮件是否真正可读，还要检查测试收件端的邮件正文、目标地址和关键链接。

按里程碑验收自家产品邮件

把每次测试绑定到一个明确的运行记录，避免把旧邮件误判为本次发送结果：

1. 准备环境：确认测试发件域名和服务配置完成，测试地址不是生产用户地址。
2. 加关联标识：在本次运行记录中保存测试用账户、目标收件地址和触发操作；可在主题或业务日志中加入不含个人信息的运行标识。
3. 触发业务流程：从自家产品执行注册、密码重置或通知流程，不用第三方平台批量注册来代替测试。
4. 确认应用提交：记录 SMTP 客户端结果、API 响应或 binding 返回值；若得到 message ID，保留它以便查日志。
5. 查服务记录：在活动日志按时间与目标地址定位邮件，区分 Sent、Delivered、失败或拒绝状态。
6. 检查测试收件端：确认本次运行对应的邮件确实到达，核对收件地址、主题、正文、验证码或链接是否可读。
7. 留下失败证据：若日志显示已交付但收件端找不到，检查垃圾邮件及收件服务端状态；不要把日志状态直接写成“收件箱验收通过”。

Cloudflare 活动日志还可查看收件方邮件服务器响应、投递尝试时间、退信原因及最终状态；面板时间范围可筛选最近 30 分钟至 30 天，也可使用自定义范围。对回归测试而言，运行标识与目标地址能帮助缩小检索范围，但实际实收仍须由测试收件端确认。

按团队现有架构做最终选择

• 已有 SMTP 代码，应用不在 Workers：先试 SMTP，核对隐式 TLS、端口、认证凭据及发件域前置条件。只有遇到运行环境无法连接、客户端无法配置或安全策略不接受该凭据方式时，再评估迁移。
• 邮件逻辑原生运行在 Workers：优先评估 Workers binding；如果 QA 需要限制测试收件目标，可先用 binding 配置收件约束。
• 其他应用后端：SMTP 客户端已成熟时，先衡量复用价值；如果团队更习惯 HTTP 接口和结构化响应，则把 Cloudflare Email Service REST API 作为候选。
• 无论哪种路径：若验收标准是“测试收件端能读到正确邮件”，就必须把收件箱实际检查纳入测试，而不是只断言接口调用成功。

确定发信接入方式后，如果测试目标只是临时收取自家产品的注册邮件或验证码，可以用 Inboxswap 临时收件地址观察测试消息是否实际可读；这只能补充收件端验收，不能保证所有邮件都会送达。使用前也应了解临时收件箱的有效期边界。银行、支付、政务及其他需要长期找回或持续收信的重要账户，不适合用临时邮箱。