网络连接和初始SMTP命令已生效后，可能会发生SMTP TLS故障。发送方可能无法协商协议版本、拒绝证书或在握手期间收到中断。将这些视为传输层观察，而不是发送者的直接证据 SPF 或者 DKIM 记录有误。
识别运输方式
在SMTP中 STARTTLS，客户端首先建立SMTP ，接收能力通告，请求STARTTLS ，然后在服务器准备就绪回复后开始TLS协商。隐式TLS在连接时立即启动TLS ，通常用于受支持的提交服务。混合这些期望可能会导致连接在发生有用的邮件交换之前失败。 RFC 3207第 4 节和第 5 节.
记录目的地、端口、模式、发送软件、远程SMTP问候语和通告的功能。保留故障是否发生在提供STARTTLS之前、 STARTTLS命令之后、证书处理期间或握手之后。避免将私钥、密码或会话机密复制到诊断数据包中。证书元数据和经过编辑的协议错误通常比模糊的“安全连接失败”更有用。
根据实际政策评估证书
过期的证书、不受支持的协议、不完整的链或身份不匹配在不同的发送策略下可能会产生不同的影响。普通的机会主义SMTP TLS与受控制的连接不是同一保证模型 MTA-STS 或已验证 DANE。在解释发件人推迟投递的原因之前，请列出正在执行的策略。不要假设每个SMTP实现都会以相同的方式验证每个证书。
RFC 8461指定MTA-STS策略发现、验证和执行行为。 RFC 7672使用经过 DNSSEC 验证的DANE SMTP传输安全性进行定义 TLSA 信息。这些机制有自己的要求和故障处理。它们的存在必须根据实际的发件人配置和相关发现证据进行验证，而不是仅仅因为日志中出现TLS错误而推断。
解决假设的身份失败问题
假设授权提交客户端在submit.example处配置为隐式TLS ，但其证书错误显示预期身份old-submit.example 。首先确认服务当前记录的端点以及客户端是否正在到达它。不要仅仅为了使任何证书看起来通过而更改预期名称。
如果服务所有者确认submit.example正确，并且证书和链满足该端点的适用要求，则批准的客户端配置更正可能会解决不匹配问题。如果端点正确但证书错误，请修复服务证书。在两个路径中保持启用验证，并在更正后重新检查相同的服务。
这是一个假设的决策树，而不是执行的握手、证书颁发或声明的TLS版本。对于MX传送，请使用实际的MTA-STS或DANE身份规则，而不是导入提交客户端假设。 HTTPS 主页证书不会建立SMTP端点的证书或策略。
纠正原因而不删除保护
将证书更新和链部署分配给服务所有者，将协议兼容性分配给邮件平台所有者，并将拦截或路径中断分配给网络团队。在替换证书之前，请检查预期的MX身份和适用的策略。一次进行一项经批准的更正并保留回滚计划。
不要仅仅为了测试通过而绕过证书警告、禁用强制执行或允许纯文本。发送者是否可以回退取决于协议和管理策略；严格的政策可以有意地推迟，而不是不安全地交付。成功的不安全重试并不能证明TLS问题已得到解决。
验证重新启动的SMTP会话
RFC 3207要求在成功STARTTLS后丢弃 pre-TLS SMTP知识；客户应该发送 EHLO 首先发现受保护会话的功能，这些功能可能与之前的列表不同。确认实际情况 MTA 完成此转换，然后传输授权消息。记录任何持续的队列延迟和最终结果，与握手成功分开。 TLS保护传输跃点；它本身并不能确定可见作者的合法性、端到端内容的机密性或收件箱的放置位置。
修复TLS时保持安全要求
- 捕获端点、端口、 STARTTLS或隐式模式以及确切的失败阶段。
- 在更改证书之前确定活动策略和预期身份。
- 单独的名称、有效性、信任链和协议错误；从日志中排除秘密。
- 在不禁用验证的情况下应用经批准的特定原因修复。
- 独立确认符合策略的TLS 、STARTTLS 后状态重置和消息结果。