专题 · SMTP 中继服务

产品团队在选择 SMTP 中继服务时应评估哪些方面？

应把 SMTP 中继服务当作一个受控的邮件提交与运营系统来评估，而不仅仅是一个主机名和端口。核实强制 TLS、支持的提交端口、SMTP AUTH 控制、凭据隔离、发件域名验证、队列持久性、有文档说明的 4xx 和 5xx 行为、配额、邮件大小上限、投递状态事件、退信和投诉处理、抑制范围、租户隔离、可观测性以及可导出性。用将要实际连接的客户端和网络进行测试。中继返回 250 响应，只表示后续处理的责任已经转移；它并不能证明已投递到收件服务器或进入收件箱。

将邮件提交与服务器之间的中继区分开来

产品团队常用“SMTP 中继”来指代这样一种带身份验证的服务：它从应用接收外发邮件，并将其传送给收件人的邮件服务器。标准将这种提交角色与邮件服务器之间的中继区分开来。RFC 6409 将 587 端口保留用于邮件提交，并允许提交服务器应用不同于 25 端口中继的身份验证、策略和邮件修正规则。请向每家服务商确认您购买的是哪种接口：面向应用的带身份验证提交、服务器之间的入站中继，还是两者兼有。记录主机名、端口、加密模式、身份验证机制、发件人规则以及支持的 SMTP 扩展。适用于桌面客户端的服务未必适合大发送量的队列，而服务器中继也可能拒绝应用的身份验证。请测试确切的角色，而不要假定所有 SMTP 端点的行为都一样。

要求受保护的提交和安全的身份验证

不要通过未受保护的连接发送凭据或邮件内容。RFC 8314 将明文提交视为过时做法，建议提交流量使用 TLS 1.2 或更高版本，并在支持时优先使用隐式 TLS。RFC 4954 定义了 SMTP AUTH，并要求服务器提供一种配置，在没有 TLS 或同等保护的情况下不允许使用明文密码机制。在评估期间，确认证书校验、支持的 TLS 版本、隐式 TLS 和 STARTTLS 端口、降级行为，以及在加密之前是否会拒绝身份验证。将中继凭据保存在服务端的机密存储中，为不同环境和应用创建独立的主体，并在不停机的情况下轮换凭据。确定权限能否限制发件域名或邮件类别。在多个生产租户之间共用一个凭据，会让吊销、责任归属和事故控制的范围不必要地扩大。

检查客户端和网络的兼容性

在选择中继之前，盘点每一个发件方：应用程序库、队列后台任务、监控设备、业务软件、多功能一体机以及遗留系统。有些支持带 STARTTLS 的 587 端口，有些需要隐式 TLS，还有些无法校验现代证书或无法安全地进行身份验证。这种局限是隔离或替换该客户端的理由，而不是在全局范围内降低中继账户安全性的理由。测试 DNS 解析、IPv4 和 IPv6、出站防火墙规则、连接超时、代理行为、TLS 协商、AUTH、EHLO 扩展、邮件大小上限，以及在需要时测试国际化地址。云环境可能会限制 25 端口，因此服务商提供的备用提交端口在运维上很重要。请从每一个生产网络运行兼容性测试，而不是在开发者的笔记本上。记录受支持的配置，并阻止回退到明文或未经批准的主机名。

理解受理、队列和重试

SMTP 回复是应用约定的一部分。2xx 完成码表示该命令成功；在邮件最终被受理之后，中继会按照 SMTP 规则承担投递责任，或在之后发送失败通知。4xx 响应是暂时性的，可以作为重试的理由；而 5xx 响应对所尝试的命令是永久性的，通常需要修正而不是重复。请询问服务会将邮件排队多久、会重试哪些失败、其退避计划、何时生成投递状态通知，以及排队中的邮件能否在区域故障后保留下来。您的应用仍然需要稳定的任务标识符、有上限的连接重试，以及针对不明确结果的保护。如果连接在 DATA 之后断开，盲目创建新任务可能会导致邮件重复。在可用时持久化保存中继的消息标识符，并在重新提交之前进行核对。

用正确的单位衡量容量

中继的限制可能针对滚动 24 小时内的收件人数、每秒邮件数、并发连接数、每个事务的收件人数、每封邮件的字节数、编码后的附件大小以及队列的存储深度。一个宣传每月总量很大的方案，仍可能在上线时的突发流量或故障切换时进行限流。请向服务商索取每个账户和每个区域的当前限制，然后按收件人（而不仅仅是 SMTP 会话）对正常、峰值、重试以及完整故障切换时的流量进行建模。确定中继在限流时是否返回暂时性回复，以及您的客户端是否会遵守它而不是打开过多的连接。在获准上限以内测试背压，并针对剩余配额、连接饱和、队列时长和限流响应设置告警。在服务商和收件方生态能够承受之前，不要提高并发。容量同时也是一道防滥用的边界，因此请评估按凭据和按租户的控制，而不仅仅是一个账户级的最大值。

核实发件人身份验证和域名接入流程

中继应当提供一个明确、可审查的域名接入流程。确认它如何验证所有权、如何生成 DKIM 选择器、如何配置信封 MAIL FROM 域名，以及如何报告身份验证状态。SPF 为 SMTP 身份授权，必须合并到现有的有效记录中，而不是再发布一条可被选中的 SPF 记录。DKIM 通过加密签名将签名域名与邮件关联起来。DMARC 评估通过验证的 SPF 或 DKIM 标识符是否与可见的 From 域名对齐，并允许域名所有者发布策略和接收报告。询问在迁移期间由谁控制签名密钥、选择器轮换、Return-Path 对齐和 DNS 变更。在投入生产之前，发送受控邮件并检查收到的邮件头。控制台显示“已验证”并不能证明每一条合法的发信流都已对齐，而身份验证也不能确保邮件进入收件箱。

要求提供可用的结果事件和关联信息

仅靠 SMTP 提交只能得到命令回复，而产品运营需要的是之后的结果。评估该服务是否通过经过身份验证的 Webhook、队列或 API 提供收件服务器投递、退信、投诉、拒绝、延迟和抑制事件。确定事件标识符、重试行为、顺序保证、保留期限、签名验证，以及收件人细节能否被隐去。RFC 3461 定义了一个 SMTP 扩展，用于在特定条件下请求投递状态通知，但服务商的事件系统可以提供结构化程度更高的运营数据。在受理时把您的应用任务 ID 映射到中继的消息 ID，然后以幂等方式接收事件。将受理、投递到收件人邮件服务器、投诉、退信和进入收件箱作为不同的概念。打开和点击的观察数据需要单独进行隐私审查，并且不应覆盖传输层的真实状态。

评估抑制列表和信誉的边界

生产级中继必须让退信和投诉的响应在运营上可行。询问它维护的是服务商级、账户级、子账户级、域名级还是租户级的抑制列表；哪些事件类型会添加条目；能否在提交之前查询某个地址；以及移除操作如何授权。永久性退信和投诉应当停止之后的常规尝试，而暂时性延迟需要单独的策略。在共享账户中，确定一个租户的投诉是否会抑制另一个租户的合法收件人，或者影响整个账户的信誉。只有结合实际发送量、隔离需求、预热责任归属和事故响应，才去考察独享 IP 与共享 IP 的选择。任何网络层面的选择都无法弥补不受欢迎的邮件、质量低劣的收件人数据或被忽视的投诉。要求提供针对退信和投诉变化的仪表盘和告警，但同时保留您自己的规范化事件，这样迁移时就不会抹去运营历史。

测试租户隔离、可观测性和故障恢复

创建两个测试租户，证明每个凭据只能从其获准的域名发信、只能查看自己的邮件、只能消耗自己的限额。尝试未授权的 From 地址、已吊销的凭据、超大邮件、无效收件人、突破速率限制、TLS 失败、网络超时、重复提交、退信收件人、投诉、延迟投递以及重复的 Webhook。核实日志中包含稳定的消息 ID、租户、经过脱敏的响应类别、尝试次数和时间信息，同时不复制凭据或邮件正文。向服务商了解状态历史、事故通报、区域故障切换行为、数据驻留、数据保留、导出格式和支持升级流程。只有当应用能够检测到违约并从中恢复时，服务等级承诺才有意义。在有排队邮件的情况下进行一次故障切换演练，并证明备用配置具备已验证的域名、凭据、配额、事件和抑制状态。

比较 SMTP 中继与邮件 API

SMTP 提交在现有软件已使用 SMTP，或服务商中立的邮件传输接口很重要时很有价值。HTTPS 邮件 API 可提供结构化校验、资源标识符、批处理语义和直接事件资源，让新应用更易控制。需要兼容旧版 SMTP 的团队应选择文档中说明的中继，或构建严格受控的适配器。构建新产品工作流的团队可以从授权、队列、事件、租户边界、迁移成本和运营归属方面比较 API 层，而不是假设 SMTP 自动更具可移植性。

进行打分式的中继评估

在征求方案之前先建立需求矩阵。为提交安全、客户端兼容性、域名接入、身份验证对齐、队列持久性、重试语义、配额、事件完整性、Webhook 验证、抑制范围、租户隔离、可观测性、数据处理、区域设计、支持、可导出性和总运营成本设置权重。将硬性失败项与偏好项分开标注：回退到明文、没有退信或投诉处理路径、事件无法验证、共享凭据、缺少域名所有权检查，或限制低于峰值需求，这些都不应被低价“平均掉”。对每个入围者执行同一套受控测试，并保留去除了机密信息的会话记录。按当前有文档说明的行为打分，而不是路线图上的承诺。在迁移之前，演练小流量双发、DNS 变更、事件核对、抑制列表迁移、凭据轮换、回滚以及最终吊销旧中继。

常见问题

SMTP 提交和中继有什么区别？

提交是从经过身份验证的客户端接收外发邮件，通常使用 587 端口和专门针对提交的策略。中继指的是邮件服务器之间的传输，通常经由 25 端口，适用不同的信任和路由规则。

SMTP 中继应该要求 TLS 吗？

对于应用提交，应该要求。要求使用经过证书校验的 TLS，并在无法达到所配置的保密级别时拒绝使用凭据或提交邮件。同时测试所支持的端口和降级行为。

SMTP 250 是否意味着收件人已收到邮件？

不是。它表示服务器已对完成的 SMTP 命令或邮件承担了责任。之后的投递状态通知或服务商事件才会说明收件服务器投递、退信、投诉、延迟或拒绝等情况。

应用应如何重试 SMTP 失败？

对暂时性的 4xx 和网络故障，使用有上限的退避和稳定的任务身份进行重试。对于 5xx 失败，先修正问题再尝试；对于 DATA 之后结果不明确的失败，先核对，以避免邮件重复。

SMTP 中继会处理 DKIM、SPF 和 DMARC 吗？

能力因服务而异。确认由谁进行 DKIM 签名、使用哪个 MAIL FROM 域名、需要哪个 SPF 机制，以及 SPF 或 DKIM 是否与可见的 From 域名对齐以满足 DMARC。

什么情况下邮件 API 比 SMTP 中继更合适？

对于需要结构化校验、资源标识符、明确的租户授权、批量结果和事件资源的新应用，API 可能更合适。对于已经支持 SMTP 的现有软件，SMTP 仍然很有用。

参考来源

继续学习

SMTP 邮件协议：应用邮件是如何传递的了解 SMTP 提交、中继、信封、响应码、TLS、重试和邮件内容如何塑造应用的邮件工作流。面向产品团队的邮件 API 实施指南设计安全的邮件 API 集成：已验证域名、队列化发送、稳定标识符、受控重试、投递事件、抑制列表和租户隔离。