MTA-STS explicado: haz que el correo hacia tu dominio use TLS verificado

Los servidores de correo intentan cifrar la conexión con el siguiente servidor mediante STARTTLS y, si falla, vuelven en silencio al texto sin cifrar. Alguien en la ruta de red puede forzar ese retroceso. MTA-STS (RFC 8461) es una política que tu dominio publica para que los remitentes te entreguen correo solo por TLS que hayan verificado.

Las dos partes

Un registro TXT en _mta-sts.example.com indica que existe una política y lleva un id que cambia cada vez que cambia la política. La política en sí es un archivo de texto pequeño servido por HTTPS en https://mta-sts.example.com/.well-known/mta-sts.txt.

El archivo de política de un dominio con dos servidores de correo se ve así:

version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400

Testing, enforce y none

mode: testing pide a los remitentes aplicar la política pero solo informar de los fallos; el correo se entrega igual. mode: enforce indica a los remitentes retener o rebotar el correo que no pueda entregarse por TLS verificado a uno de los hosts mx listados. mode: none desactiva la política de forma limpia. Empieza en testing y pasa a enforce solo cuando los informes lleven un tiempo limpios.

max_age

max_age es cuántos segundos pueden recordar los remitentes tu política. Empieza con un día (86400) en testing, usa una semana (604800) cuando apliques enforce por primera vez y pasa a 30 días (2592000) o más después. Un max_age largo es la protección: un remitente que tiene tu política en caché sigue aplicándola aunque un atacante bloquee el archivo. También es el riesgo: si rompes el certificado de un servidor de correo, los remitentes siguen rechazando durante todo ese tiempo.

Lo que necesitan tus servidores de correo

Cada host de una línea mx debe presentar un certificado válido para su propio nombre, emitido por una CA en la que confíen los remitentes y sin vencer. Un certificado autofirmado, uno para otro nombre o uno vencido falla en modo enforce. Las líneas mx también deben cubrir cada host al que apuntan tus registros MX: un MX que no figure en la lista no puede recibir correo de los remitentes que usan MTA-STS.

La herramienta MTA-STS obtiene la política, la compara con tus registros MX y prueba el certificado de cada servidor de correo.

Alojar tú mismo el archivo de política

El archivo debe servirse desde el host mta-sts.example.com por HTTPS, con un certificado válido para ese nombre, estado 200 y sin redirecciones. Cualquier servidor web puede hacerlo: agrega un registro A o CNAME para mta-sts, obtén un certificado y sirve un archivo estático como text/plain. Un bloque corto de sitio en Caddy o nginx basta, y un alojamiento estático también. ProbeKit no aloja el archivo por ti.

Cambiar la política

Los remitentes vuelven a leer el archivo solo cuando cambia el id del registro TXT. Edita el archivo y luego cambia el id; si lo olvidas, los remitentes conservan la política anterior hasta que venza max_age. El monitor de ProbeKit comprueba que cambiaste el id cuando cambiaste el archivo.

TLS-RPT: el ciclo de retroalimentación

MTA-STS sin informes es volar a ciegas. Un registro TLS-RPT pide a los remitentes un informe diario de cuántas conexiones funcionaron y por qué fallaron las demás, así ves un certificado roto antes de que te cueste correo. Quédate en testing hasta que los informes lleven 14 días sin fallos.

El generador de ProbeKit escribe el archivo de política exacto y ambos registros, prueba cada servidor de correo primero y bloquea enforce mientras alguno falle, porque aplicar una configuración rota hace rebotar el correo.