SMTP使用独立的TCP协议，不能把EHLO、MAIL FROM和DATA当作HTTP请求交给普通网页代理。需要跨网络发信时，应优先使用组织批准的SMTP Relay或邮件服务API；若采用CONNECT或SOCKS隧道，则客户端必须明确支持，并符合出口端口策略。
常见发信路径
| 方式 | 特点 | 适用范围 |
|---|---|---|
| SMTP Relay | 由受控中继完成投递 | 企业应用与服务器发信 |
| HTTP邮件API | 通过HTTPS调用服务商 | 易于经过HTTP代理和审计 |
| SOCKS/TCP隧道 | 转发SMTP TCP连接 | 客户端支持且策略允许 |
| HTTP CONNECT | 代理允许目标端口时建隧道 | 需客户端支持与出口审批 |
465、587和25端口怎么理解
587常用于客户端或应用向邮件服务提交，并使用STARTTLS；465通常使用隐式TLS；25主要用于服务器间传输，也可能被云平台或ISP限制。不要为了端口被封就随意切换到未授权服务，应按邮件服务商文档选择提交端口。
STARTTLS失败发生在哪一步
- 客户端建立明文TCP连接；
- 发送EHLO并读取服务器能力；
- 确认服务器公布STARTTLS；
- 发送STARTTLS并开始TLS握手；
- 验证证书后重新EHLO；
- 执行SMTP认证与邮件提交。
代理或网关若在升级前后错误处理字节流，会表现为握手失败或连接重置。应保留阶段信息，不要记录邮件密码和正文。
代理认证与SMTP认证不是同一套
HTTP代理407或SOCKS凭据属于网络出口；SMTP AUTH用户名、密码或OAuth令牌属于邮件服务身份。不要混用。SMTP的535等错误通常指发信账号认证失败，而不是代理。
TLS证书应该验证谁
若代理只透传TCP，客户端应验证SMTP服务器证书。使用域名连接，并确认SAN、证书链和系统时间。不要关闭证书校验，也不要因为使用本地隧道就把证书主机名改成localhost。
连接成功为什么仍无法投递
SMTP服务器接受邮件后，仍可能因为收件地址、域名信誉、内容策略、配额或远端临时错误延迟和退信。应用应保存服务端队列ID，处理异步退信，不要只把一次250响应当作最终送达。
SPF、DKIM和DMARC有什么作用
它们用于声明授权发信来源、验证签名和制定域名对齐策略。代理不能替代这些域名认证。若通过第三方Relay发信，应按服务商要求配置DNS，并在上线前用测试域名验证，避免直接影响主域名信誉。
重试怎样避免重复邮件
连接中断时，客户端可能不知道服务器是否已接受DATA。邮件系统可利用稳定Message-ID、发送任务ID和队列状态去重。不要对所有错误立即重发；4xx通常可退避，5xx往往需要修正地址、权限或内容。
通用重试边界见超时、重试与幂等恢复。
日志应记录什么
- 邮件任务ID和Message-ID；
- SMTP主机、端口和TLS模式；
- 连接、握手、认证与提交阶段；
- SMTP响应码和队列ID；
- 退信类型与重试时间。
不要记录密码、OAuth令牌、完整收件人列表和正文。
排查顺序
- 确认使用SMTP Relay还是邮件API；
- 记录端口、TLS模式和客户端库；
- 验证代理是否支持目标TCP端口；
- 区分代理认证、TLS和SMTP AUTH；
- 用测试收件箱发送最小邮件；
- 追踪队列ID与退信；
- 复核SPF、DKIM与DMARC。
结论
SMTP代理故障要从协议、端口和TLS升级过程排查。网络连通只是邮件提交的第一步，最终可靠性还取决于队列、退信、域名认证和安全重试。
