TLS-RPT 中常见的 failure type 分别怎么处理？

TLS-RPT 报告中的 result-type 是识别 SMTP TLS 连接故障的关键。RFC 8460 定义了多种失败类型，每种需要不同的修复策略。

一、starttls-not-supported

接收方服务器在 SMTP 协商阶段未通告 STARTTLS 支持。处理：确认接收方的邮件服务器支持 STARTTLS；如果接收方是外部服务商且不支持，可联系其升级；对于 MTA-STS enforce 模式下的此类失败，邮件会被暂缓投递。

二、certificate-expired

接收方服务器的 TLS 证书已过期。处理：接收方需要续期证书；发送方可暂时使用 TLS-RPT testing 模式观察，待修复后恢复 enforce。

三、hostname-mismatch

接收方证书中的 CN/SAN 与 MX 主机名不匹配。处理：接收方重新签发证书，确保证书中的 CN 或 SAN 包含 MX 完整域名（如 mx1.example.com）；修复后使用 SSL Labs 测试确认。

四、tlsa-invalid

DANE 部署中 TLSA 记录无效。处理：检查 TLSA 记录的 certificate usage、selector、matching type 参数是否正确；确保证书指纹与 TLSA 记录完全匹配；验证 DNSSEC 签名链未损坏。

五、validation-failure

TLS 证书链验证失败（如中间 CA 不被信任、自签名证书）。处理：接收方确保使用公共 CA 签发的证书或无信任链问题的证书；如果使用自签名证书需要 DANE EE 模式支持。

六、其他类型

• certificate-not-yet-valid：服务器系统时间不正确或证书开始时间在未来
• connection-timeout：TLS 连接超时，可能因防火墙或网络问题
• tlsa-not-found：DANE 模式下找不到 TLSA 记录