Comprobador de política MTA-STS
Obtiene el registro TXT _mta-sts y el archivo de política mta-sts.txt de un dominio para diagnosticar si el cifrado TLS obligatorio en el transporte de correo (MTA-STS) está bien configurado.
Diagnosticar el TLS obligatorio en la entrega de correo (MTA-STS)
El cifrado en SMTP es de origen un asunto optativo, que se intenta donde se puede, lo que significa que un atacante interpuesto que arranque el anuncio de STARTTLS puede forzar el intercambio hasta el texto plano. MTA-STS es el arreglo que cierra esa puerta, **instruyendo a los servidores remitentes de que el correo para el dominio ha de ir por TLS.** Esta herramienta recoge tanto el registro TXT `_mta-sts` como el archivo de política, y comunica si la configuración está completa.
**Lo que confunde de este arreglo es que la política misma no reside en el DNS.** Cuanto lleva el registro TXT es un `id` que marca la versión; **la sustancia se sirve por HTTPS desde `https://mta-sts.sudominio/.well-known/mta-sts.txt`.** La confianza de este mecanismo descansa, pues, en los certificados web y no en el DNS. **Y el punto donde más se atasca uno es dejar `mode` en `testing`.** En ese estado la entrega prosigue pese a un fallo de TLS, y **la obligatoriedad solo surte efecto una vez que el valor es `enforce`.** El orden asentado de adopción consiste en permanecer en `testing`, observar los informes de TLS-RPT hasta quedar satisfecho de que nada se rompe, y solo entonces pasar a `enforce`.
Cómo se usa
- Introduzca el dominio Indique únicamente el dominio, en la forma `example.com`.
- Compruebe el registro TXT **Busque `v=STSv1` y un `id=`.** El `id` se cambia cada vez que se actualiza la política.
- Lea el contenido del archivo de política Aparecen tres entradas: `mx`, `max_age` y `mode`.
- Confirme el mode **En `testing` no se está imponiendo nada.** Alcanzar `enforce` es lo que da efecto a la política.
Consejos para aprovecharla mejor
- MTA-STS lo verifica el servidor que envía el correo, no el que lo recibe. Al publicarlo, los servidores de terceros empezarán a exigir TLS al enviar correo a tu dominio.
- Despliega primero en modo testing durante varias semanas o un mes antes de pasar a enforce, para no llevarte una sorpresa con rechazos de entrega inesperados.
- max_age suele configurarse entre 604800 segundos (7 días) y 31557600 segundos (1 año). Un valor demasiado corto obliga a recuperar el archivo de política con más frecuencia.
- Puedes usar un comodín (*.example.com) en el campo mx, pero el SAN (Subject Alternative Name) del certificado TLS debe coincidir con ese comodín.
- Publicar solo el registro DNS o solo el archivo de política no sirve de nada: MTA-STS solo entra en vigor cuando ambos están presentes a la vez.
Cuándo resulta útil
Inspeccionar su propio dominio
**Como el mecanismo necesita a la vez DNS y HTTPS, puede hallar cuál de las dos mitades falta.**
Comprobar antes de pasar a enforce
Los errores de configuración pueden despejarse mientras se sigue en `testing`.
Revisar tras añadir un MX
**Olvidar añadir un nuevo host MX a la lista `mx` de la política hace que se rechace la entrega a ese host.**
Saber hasta dónde ha llegado un corresponsal
Puede ver si impone TLS en su propio correo.
Términos de MTA-STS
- _mta-sts TXT
- **El registro DNS que lleva el `id` marcador de la versión de la política.** La política misma no reside aquí.
- Archivo de política
- La sustancia, colocada en `https://mta-sts.sudominio/.well-known/mta-sts.txt`. **Al servirse por HTTPS, exige un certificado válido.**
- Mode
- Uno de `enforce`, `testing` o `none`. **Bajo `testing` el correo se entrega aun cuando la comprobación falle.**
- Max_age
- Cuántos segundos puede un remitente guardar la política en caché. Un valor mayor refuerza la protección pero retarda la difusión de cualquier cambio.
- Mx
- La lista de hosts MX en los que se ha de imponer TLS. **Se rechaza la entrega a un host ausente de esta lista.**
- Degradación de STARTTLS
- El ataque en que un interpuesto arranca el anuncio de STARTTLS para forzar el texto plano. **MTA-STS se ideó para impedirlo.**
Preguntas frecuentes
A propósito — Por qué STARTTLS no bastaba y cómo surgió MTA-STS
Durante décadas, el cifrado en tránsito de SMTP dependió de STARTTLS (estandarizado en 1999), que abre la conexión en texto plano y solo después la actualiza a TLS. En 2014 se confirmaron ataques reales de "STARTTLS stripping": como la propia negociación de STARTTLS ocurre antes de que el cifrado entre en juego, un atacante en la ruta podía reescribir la respuesta del servidor para ocultar su soporte de STARTTLS, engañando al otro extremo para que se degradara a texto plano.
La causa raíz era que STARTTLS estaba diseñado deliberadamente para degradarse a texto plano cuando el otro extremo no soportaba TLS, una característica de compatibilidad que los atacantes podían explotar simplemente fingiendo que no había soporte de TLS. Hacia 2015, las propias mediciones de Google mostraron que el STARTTLS stripping ocurría a gran escala en ciertos países y proveedores.
MTA-STS (RFC 8461, publicado en 2018) fue la respuesta de la industria, desarrollada conjuntamente por Google, Microsoft, Yahoo y otros. Un dominio declara su soporte de MTA-STS mediante un registro TXT en el DNS, y publica un archivo de política obtenido por HTTPS que enumera los hosts MX permitidos y los requisitos de TLS. Una vez obtenida, la política se almacena en caché durante max_age, de modo que un intento posterior de degradación puede detectarse y rechazarse en lugar de aceptarse silenciosamente.
MTA-STS suele combinarse con TLS-RPT (TLS Reporting, RFC 8460), que permite a los propietarios de dominios recibir informes cuando un servidor emisor no logra establecer TLS. MTA-STS aporta la capa de aplicación forzosa; TLS-RPT, la de observabilidad. Usar ambos juntos es la práctica recomendada hoy en día.