En 2015, investigadores demostraron algo que debería haber aterrorizado a cualquier empresa que maneje correo sensible: podían interceptar correos entre grandes corporaciones explotando una debilidad fundamental en cómo los servidores de correo negocian el cifrado. El ataque era elegante por su simplicidad. Cuando dos servidores de correo se conectan, intentan actualizar a una conexión cifrada usando STARTTLS. Pero si un atacante se coloca entre ellos, puede simplemente eliminar la oferta de cifrado, obligando a ambos servidores a comunicarse en texto plano.
Los servidores no se quejan. No alertan a nadie. Simplemente encogen los hombros y envían tus contratos confidenciales, historiales médicos y estados financieros por internet en texto plano, legible por cualquiera que esté mirando.
MTA-STS—Mail Transfer Agent Strict Transport Security—existe para evitar exactamente este escenario.
El problema de STARTTLS
Para entender por qué MTA-STS importa, necesitas entender cómo suele funcionar el cifrado del correo y por qué es sorprendentemente frágil.
Cuando tu servidor de correo quiere entregar un email a otro dominio, se conecta al servidor de correo del destinatario en el puerto 25. Esta conexión inicial no está cifrada. Luego los servidores negocian: "Oye, ¿soportas cifrado?" Si ambos lados están de acuerdo, actualizan a TLS y siguen de forma segura.
Esto se llama cifrado oportunista y tiene un fallo fatal. La negociación ocurre sobre un canal sin cifrar. Un atacante que realice un ataque de intermediario (man-in-the-middle) puede interceptar el mensaje de "yo soporto TLS" y reemplazarlo por "yo no soporto TLS". Ambos servidores creen que el otro no puede hacer cifrado, así que continúan en texto plano.
Esto no es teórico. Los investigadores de seguridad han documentado ISP y estados nación realizando activamente estos ataques de degradación. En algunos países, es rutina. Tu correo puede estar cifrado cuando sale de tu servidor y cifrado cuando llega al destino, pero en algún punto intermedio alguien leyó cada palabra.
Cómo MTA-STS soluciona esto
MTA-STS adopta un enfoque sencillo: permite a los propietarios de dominios publicar una política que diga "siempre exige TLS al entregar correo hacia nosotros, y aquí están exactamente los servidores a los que debes conectarte".
La política se publica en dos lugares. Primero, un registro DNS anuncia que el dominio usa MTA-STS. Segundo, un archivo de política alojado sobre HTTPS especifica los requisitos exactos. La parte de HTTPS es crucial: significa que la política en sí se entrega a través de un canal cifrado y autenticado que no puede ser manipulado.
Cuando un servidor de correo remitente quiere entregar a un dominio con MTA-STS habilitado, primero busca el registro DNS. Si está presente, obtiene el archivo de política por HTTPS. La política le indica: exige TLS versión 1.2 o superior, verifica que el certificado coincida con estos patrones y conéctate solo a estos servidores de correo específicos.
Si no se puede cumplir alguno de estos requisitos—si la conexión no puede cifrarse, si el certificado no es válido, si el nombre del servidor no coincide—el servidor remitente se niega a entregar el correo. No vuelve a texto plano. Falla de forma evidente.
Configurar MTA-STS
Implementar MTA-STS requiere tres componentes: un registro DNS, un archivo de política y un servidor web para alojar esa política.
El registro DNS es un registro TXT en _mta-sts.yourdomain.com. Se ve así: "v=STSv1; id=20240115". El campo 'id' es un identificador de versión: lo cambias cada vez que actualizas tu política, lo que indica a los servidores remitentes que obtengan la nueva versión.
El archivo de política vive en https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Ten en cuenta el subdominio—necesitas un certificado HTTPS válido para mta-sts.yourdomain.com. El archivo contiene tu política en un formato de texto simple.
Una política típica especifica la versión, el modo (testing o enforce), la edad máxima en segundos que los remitentes deben almacenar en caché la política, y los nombres de host MX que son válidos para tu dominio. El max_age es importante—valores más largos significan mejor protección contra ataques pero una recuperación más lenta si necesitas cambiar algo.
Testing vs enforcing
MTA-STS admite dos modos, y la diferencia importa enormemente.
En modo testing, los servidores remitentes obtienen y evalúan tu política, pero en realidad no la aplican. Si una conexión incumpliera la política, de todos modos entregan el correo, pero te envían un informe contándote lo que pasó. Esto te permite identificar problemas antes de que causen fallos de entrega.
En modo enforce, la política es obligatoria. Las conexiones que no cumplan los requisitos fallan y el correo no se entrega. Esta es protección real, pero también un riesgo real si tu política es incorrecta.
El enfoque inteligente es empezar en modo testing con un max_age corto. Supervisa los informes durante unas semanas. Busca servidores de correo legítimos que no puedan cumplir tus requisitos—quizá un sistema de un socio antiguo con una implementación de TLS desactualizada, o un MX de respaldo mal configurado. Corrige esos problemas y luego cambia a modo enforce con un max_age más largo.
La parte de informes: TLSRPT
MTA-STS funciona de la mano con TLSRPT—TLS Reporting. Este es un registro DNS aparte que indica a los servidores remitentes dónde enviar informes sobre intentos de conexión TLS.
Los informes incluyen éxitos y fallos: qué servidores se conectaron, qué versión de TLS usaron, si la validación del certificado pasó y, si algo falló, por qué. Esta visibilidad es invaluable. Sin ella, vuelas a ciegas: no sabrás si los atacantes están intentando degradaciones, o si remitentes legítimos están teniendo problemas.
Configurar TLSRPT es simple: añade un registro TXT en _smtp._tls.yourdomain.com especificando dónde enviar los informes. Puedes recibirlos por email o vía HTTPS POST. Varios servicios agregarán y visualizarán estos informes por ti, facilitando mucho detectar patrones.
Errores comunes de implementación
El error más frecuente con MTA-STS son los problemas de certificados. Tu subdominio mta-sts necesita un certificado válido, y tus servidores de correo necesitan certificados válidos con nombres de host que coincidan con tu política. Let's Encrypt lo facilita, pero debes recordar incluir el subdominio mta-sts en tu proceso de renovación de certificados.
Otro problema común son los desajustes de registros MX. Tu política de MTA-STS enumera nombres de host específicos, y tus registros MX deben coincidir exactamente. Si tu MX apunta a mail.example.com pero tu política enumera mx1.example.com, las conexiones fallarán en modo enforce.
Olvidar actualizar el ID de la política también hace tropezar a la gente. Cuando cambias tu archivo de política, también debes actualizar el ID en tu registro DNS. Los servidores remitentes almacenan políticas en caché basándose en el ID: si no lo cambias, no obtendrán tus actualizaciones.
Por último, establecer un max_age demasiado alto demasiado pronto es arriesgado. Si publicas una política con un max_age de un año y luego descubres un problema, los servidores remitentes harán cumplir la política defectuosa durante hasta un año. Empieza con horas o días, no con meses.
MTA-STS vs DANE
Puede que hayas oído hablar de DANE (DNS-based Authentication of Named Entities) como otra solución al mismo problema. Ambos evitan ataques de degradación de TLS, pero funcionan de manera diferente.
DANE usa DNSSEC para autenticar certificados TLS. Es, si se quiere, más elegante: todo vive en DNS, sin necesidad de un servidor web. Pero la adopción de DNSSEC sigue siendo limitada, y muchos proveedores de DNS no lo soportan bien. MTA-STS se diseñó como una alternativa más fácil de desplegar que funciona con la infraestructura existente.
En la práctica, MTA-STS ha visto una adopción mucho más amplia. Google, Microsoft y la mayoría de los principales proveedores de correo lo soportan. Si estás eligiendo entre ambos, MTA-STS es la opción pragmática. Si te enfocas en seguridad y ya tienes DNSSEC, implementar ambos proporciona defensa en profundidad.
¿Vale la pena el esfuerzo?
MTA-STS requiere más configuración que un simple registro DNS. Necesitas alojar un archivo de política, mantener certificados, monitorizar informes. ¿Vale la pena?
Si manejas correo sensible—servicios financieros, salud, legal, o cualquier negocio donde la interceptación de correo sería catastrófica—sí, absolutamente. El ataque que previene es real y se explota activamente. El coste de configuración son unas horas; la protección es continua.
Para organizaciones más pequeñas con correo menos sensible, es una decisión de criterio. La buena noticia es que a medida que más dominios adoptan MTA-STS, el ecosistema se vuelve más seguro para todos. Los atacantes no pueden degradar conexiones selectivamente cuando la mayor parte de internet se niega a aceptar degradaciones.
Frequently asked questions
¿MTA-STS protege el contenido del correo de extremo a extremo?
No. MTA-STS protege el correo en tránsito entre servidores de correo, pero el correo se descifra en cada servidor. Para un cifrado verdaderamente de extremo a extremo, necesitas S/MIME o PGP. MTA-STS y el cifrado de extremo a extremo resuelven problemas distintos y pueden usarse juntos.
¿Qué ocurre si mi archivo de política de MTA-STS no está disponible?
Si los remitentes no pueden obtener tu política por HTTPS, volverán al cifrado oportunista—lo mismo que si no tuvieras MTA-STS. Por eso la fiabilidad del hosting importa. Considera usar un CDN o alojamiento redundante para el archivo de política.
¿Todos los proveedores de correo admiten MTA-STS?
La mayoría de los principales proveedores sí, incluidos Gmail, Outlook, Yahoo y otros. Sin embargo, algunos servidores de correo más pequeños o antiguos no. Revisa los informes de TLSRPT para ver qué remitentes están evaluando tu política.
¿Puede MTA-STS provocar fallos en la entrega de correo?
En modo enforce, sí—ese es el objetivo. Si un servidor remitente no puede establecer una conexión segura que cumpla los requisitos de tu política, el correo no se entregará. Por eso son esenciales el modo de testing y la monitorización antes de hacer cumplir.