MTA-STS explicado: qué es, qué aporta TLS-RPT y si lo necesita

MTA-STS (RFC 8461) permite que un dominio diga a los servidores de correo que le envían mensajes: "entregue mi correo solo por TLS, solo con un certificado válido y solo a estos hosts MX". Sin él, el cifrado entre servidores de correo es oportunista y cualquiera situado en el camino puede eliminarlo. MTA-STS consta de un registro TXT, un pequeño archivo de texto servido por HTTPS y, a ser posible, un segundo registro TXT (TLS-RPT, RFC 8460) que le hace llegar informes diarios sobre lo que experimentaron los remitentes. Si su correo está alojado en un gran proveedor, el coste es una tarde de trabajo; si recibe algo sensible por correo, merece la pena.

El problema: STARTTLS es oportunista

El SMTP entre servidores empieza en texto claro. El servidor receptor anuncia STARTTLS, el remitente eleva la conexión a TLS y el resto va cifrado. Este diseño trae dos debilidades de serie:

• Degradación. Un atacante situado en el camino puede borrar la línea STARTTLS de la respuesta del servidor. El remitente concluye que no se ofrece TLS y entrega en texto claro.
• Sin autenticación. Los remitentes normalmente no validan el certificado que se les presenta, porque durante décadas muchos servidores de correo tenían certificados autofirmados o con un nombre que no coincidía. Un atacante capaz de falsificar la respuesta a su consulta MX, o de interceptar la conexión, puede presentar cualquier certificado.

Las tres piezas

1. El registro TXT _mta-sts

$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260921000000"

id es cualquier cadena de hasta 32 letras y dígitos. Su única función es cambiar cada vez que cambia la política, para que los remitentes sepan que deben volver a descargar el archivo.

2. El archivo de política

Se sirve en una URL fija, en el nombre de host fijo mta-sts:

$ curl https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mx1.mail.example.net
mx: mx2.mail.example.net
max_age: 86400

Campo	Significado
version	Siempre STSv1
mode	enforce, testing o none
mx	Una línea por cada host MX permitido. Se admite un comodín como *.mail.example.net, que coincide exactamente con una etiqueta situada más a la izquierda
max_age	Cuánto tiempo pueden guardar en caché la política los remitentes, en segundos. Máximo 31557600 (alrededor de un año)

El servidor HTTPS debe presentar un certificado de confianza pública válido para mta-sts.example.com. Los remitentes no siguen redirecciones HTTP al descargar la política, así que el archivo tiene que servirse exactamente en esa URL.

3. Hosts MX que superan la prueba

Cada host de la lista debe ofrecer STARTTLS con un certificado no caducado, que encadene hasta una autoridad de certificación en la que confíe el remitente y que coincida con el nombre de host del MX.

$ openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -enddate -ext subjectAltName

Si el certificado de su propio MX ha caducado, resuelva eso primero: certificado SSL caducado: qué hacer cubre la parte de la renovación.

Cómo usa la política un remitente

1. Antes de entregar a example.com, el remitente consulta _mta-sts.example.com.
2. Si no tiene una política en caché, o el id difiere del que guardó, descarga el archivo de política por HTTPS.
3. Guarda la política en caché durante max_age segundos.
4. Resuelve los registros MX como siempre, descarta cualquier host MX que no coincida con una línea mx: y exige TLS válido en los restantes.

Lo que ocurre ante un fallo depende del modo:

Modo	Ante un fallo de TLS o un MX que no coincide
testing	El mensaje se entrega de todos modos; el fallo se comunica mediante TLS-RPT
enforce	El remitente no entrega al host que falla. Si ningún host supera la prueba, el mensaje se pone en cola, se reintenta y finalmente rebota
none	El dominio declara que no tiene ninguna política activa. Se usa para retirarla

La caché es lo que da fuerza a MTA-STS. Un atacante que bloquee hoy la consulta TXT o la descarga por HTTPS no puede hacer que un remitente olvide la política que guardó la semana pasada. El momento débil es la primera descarga, antes de que haya nada en caché.

TLS-RPT: saber qué ven los remitentes

$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

rua admite una dirección mailto: o un URI https:. Los remitentes que participan envían un informe JSON agregado por día: cuántas sesiones hacia su dominio tuvieron éxito, cuántas fallaron y por qué (certificado caducado, nombre de host que no coincide, STARTTLS no ofrecido, MX ausente de la política). Los informes cubren tanto MTA-STS como DANE. Sin ellos, el modo testing no prueba nada, porque nadie le comunica el resultado.

Orden de despliegue

• Confirme que cada host MX tiene un certificado válido, coincidente y de confianza pública (comando anterior).
• Publique primero el registro TLS-RPT y deje que empiecen a llegar los informes.
• Aloje el archivo de política con mode: testing y un max_age corto, por ejemplo 86400.
• Publique el registro TXT _mta-sts.
• Lea los informes durante unas semanas. Busque fallos procedentes de remitentes legítimos y hosts MX que falten en la política.
• Pase a mode: enforce, cambie el id y mantenga un max_age corto durante los primeros días.
• Suba max_age a unas semanas cuando todo esté tranquilo.
• Ponga el certificado del host mta-sts y los certificados de los MX bajo vigilancia de caducidad.

Para ver el registro _mta-sts y la política publicados de un dominio, use el comprobador de MTA-STS; para el registro de informes, el comprobador de TLS-RPT.

Correo alojado en un proveedor

Si sus registros MX apuntan a un proveedor de correo, los certificados son responsabilidad del proveedor y los grandes proveedores los tienen en orden. Su parte:

• Incluya los nombres MX del proveedor en la política exactamente como aparecen en sus registros MX, o con la forma de comodín que documente el proveedor.
• Aloje el archivo de política usted mismo en mta-sts.example.com. Basta con un alojamiento de páginas estáticas.

Cambiar de proveedor de correo

Una vez en enforce, el orden importa. Los remitentes conservan una política en caché que solo lista los hosts MX antiguos. Si cambia primero los registros MX, esos remitentes ven hosts nuevos que la política no permite y se niegan a entregar.

1. Añada los nombres MX del nuevo proveedor al archivo de política (conserve los antiguos) y cambie el id.
2. Dé tiempo a los remitentes para que detecten el nuevo id y vuelvan a descargar la política; unos días es un margen prudente.
3. Cambie los registros MX.
4. Más adelante, retire los nombres antiguos de la política y cambie el id otra vez.

Esta es también la razón para no saltar pronto a un max_age de un año.

Retirar una política

Borrar el registro TXT y el archivo no es una retirada. Los remitentes con una política enforce en caché siguen aplicándola hasta que su caché expira. La forma limpia: publique mode: none con un id nuevo, mantenga el registro y el archivo en su sitio hasta que haya transcurrido por completo el max_age anterior y solo entonces elimínelos.

MTA-STS y DANE

DANE para SMTP (RFC 7672) resuelve el mismo problema de otra manera: el certificado o la clave del host MX se fija en un registro TLSA, y ese registro es de confianza porque la zona está firmada con DNSSEC.

	MTA-STS	DANE para SMTP
Ancla de confianza	PKI web (CA públicas) más HTTPS	Cadena DNSSEC
Necesita DNSSEC	No	Sí: los registros TLSA de los hosts MX deben estar en una zona firmada
Debilidad en el primer contacto	Sí, hasta que la política está en caché	No

Pueden coexistir, y TLS-RPT informa sobre ambos. Con correo alojado, DANE depende de que su proveedor firme la zona de sus MX; MTA-STS está en sus propias manos. Consulte DNSSEC explicado.

Lo que MTA-STS no hace

• Protege solo el correo entrante a su dominio. Su correo saliente lo protegen las políticas de los destinatarios, siempre que su servidor de envío respete MTA-STS.
• Solo funciona con los remitentes que lo implementan. Los demás siguen entregando de forma oportunista.
• Es cifrado de transporte salto a salto, no de extremo a extremo. El correo es legible en cada servidor por el que pasa.
• No dice nada sobre spam, suplantación ni autenticación del remitente. Eso es tarea de SPF, DKIM y DMARC: consulte MX, SPF, DKIM y DMARC explicados.

¿Lo necesita?

• Dominio con correo alojado en un gran proveedor: coste bajo, riesgo bajo. Los certificados del proveedor están mantenidos; usted añade dos registros TXT y un archivo estático.
• Dominio que recibe correo sensible (contratos, salud, finanzas, restablecimientos de cuentas): merece la pena incluso si opera su propio MX, siempre que vigile los certificados.
• Sin decidirse todavía: el modo testing más TLS-RPT no conlleva ningún riesgo de entrega y le dice si enforce causaría daño.

Errores frecuentes

• Pasar directamente a enforce sin TLS-RPT y enterarse de los fallos por las personas cuyo correo rebotó.
• Editar el archivo de política y dejar el id sin cambiar. Los remitentes conservan la política antigua hasta que se agota max_age.
• Escribir el dominio (example.com) en la línea mx: en lugar de los nombres de host de los MX.
• Un archivo de política accesible solo a través de una redirección, o bajo un certificado que no cubre mta-sts.example.com.
• Dejar caducar el certificado del host mta-sts: los remitentes nuevos ya no pueden descargar la política.
• Cambiar los registros MX antes de actualizar la política, o borrarlo todo de golpe para "desactivarlo".

Compruébelo con OrbitProbe

Empiece por la consulta MX de OrbitProbe: lista los hosts MX de un dominio con sus preferencias, junto con los registros SPF y DMARC. Los nombres de host que muestra son los que deben coincidir con sus líneas mx:, carácter por carácter, así que ejecútela antes de escribir la política y otra vez después de cualquier cambio de proveedor de correo. Una consulta DNS muestra lo que está publicado ahora; si los remitentes pudieron negociar TLS de verdad es lo que cuentan los informes TLS-RPT, así que siga leyéndolos después de pasar a enforce.