Cómo solucionar "TLS negotiation failed" reportado contra tu política MTA-STS
TLS-RPT: failure — certificate.host.mismatch / starttls.not.supported
Después de pasar MTA-STS a mode: enforce, los remitentes que respetan tu política empiezan a negarse a entregar y tus informes TLS-RPT se llenan de fallos como:
"result-type": "certificate.host.mismatch"
"result-type": "starttls.not.supported"MTA-STS les dice a los remitentes que deben usar STARTTLS con un certificado válido que coincida con un host MX nombrado en tu política. Si algún MX no puede hacerlo, el remitente, con razón, se niega a entregar en lugar de recurrir al texto sin cifrar.
Por qué ocurre
El archivo de política lista un MX que no está en el DNS, un MX cuyo certificado no coincide con su nombre de host, un servidor que no ofrece STARTTLS, o un certificado vencido o autofirmado en uno de los hosts de correo. Un solo MX que no cumpla rompe el modo enforce.
Diagnostícalo
La verificación de MTA-STS de abajo obtiene tu registro TXT _mta-sts y la política en https://mta-sts.example.com/.well-known/mta-sts.txt, valida el modo y max_age, y confirma que cada patrón mx: listado coincide con tu conjunto real de MX.
Corrígelo
1. Haz que las líneas mx: de la política coincidan exactamente con los nombres de host MX que publicas (se permiten comodines).
2. Asegúrate de que todos los MX ofrezcan STARTTLS con un certificado válido y vigente cuyo nombre coincida con el host MX.
3. Prueba primero en mode: testing, que recopila los fallos de TLS-RPT sin bloquear el correo, y luego pasa a enforce.
4. Mantén una dirección rua de TLS-RPT para que los fallos futuros te lleguen como informe y no los descubras por correo rebotado.
Diagnostica tu propio dominio en segundos:
Valida tu política MTA-STS¿Sigues atascado? Pega el rebote completo y te indicaremos la falla exacta y cómo solucionarla.
Diagnosticar mi rebote