El problema: STARTTLS es oportunista
La mayoría del correo entre servidores se cifra con STARTTLS, una extensión SMTP que actualiza la conexión de texto plano a TLS. Sin embargo, STARTTLS tiene un defecto fundamental: es oportunista. Si la negociación TLS falla por cualquier motivo — un atacante que bloquea el comando STARTTLS, un certificado caducado, un error de configuración — la mayoría de los servidores remitentes continúan en texto plano, enviando los correos sin cifrado. Un atacante posicionado en la red (man-in-the-middle) puede simplemente interceptar el comando STARTTLS y forzar la conexión en texto plano, leyendo todos los correos en tránsito.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) resuelve este problema permitiendo al dominio destinatario declarar: "los correos para mi dominio deben entregarse únicamente a través de conexiones TLS válidas". Si el servidor remitente soporta MTA-STS y la negociación TLS falla, el correo no se envía en texto plano — se retiene y se notifica al remitente. Esto elimina la posibilidad de ataques de degradación.
Cómo funciona MTA-STS
MTA-STS requiere dos componentes: un registro DNS TXT en _mta-sts.dominio.com que señala la presencia de la política e incluye un ID único (típicamente una marca de tiempo) que se actualiza con cada cambio, y un archivo de política servido vía HTTPS en https://mta-sts.dominio.com/.well-known/mta-sts.txt. El hecho de que la política se sirva vía HTTPS (no DNS) añade una capa adicional de seguridad: un atacante también necesitaría comprometer el certificado HTTPS para falsificar la política.
La política especifica: la versión (STSv1), el modo (testing o enforce), los nombres de host de los servidores de correo autorizados (mx:), y la duración de la caché de la política (max_age en segundos). El modo testing notifica los problemas en los informes TLS-RPT sin bloquear la entrega, permitiendo identificar y resolver los problemas antes de pasar a enforce.
MTA-STS y TLS-RPT: la pareja perfecta
MTA-STS sin TLS-RPT Lookup es como un sistema de seguridad sin alarma: bloquea los problemas pero no te avisa. TLS-RPT (RFC 8460) proporciona informes detallados sobre los fallos TLS, permitiéndote monitorizar cuántas conexiones TLS tienen éxito, cuántas fallan y por qué. Configura siempre TLS-RPT junto con MTA-STS para tener visibilidad completa sobre la seguridad de las conexiones de correo entrante.
Nuestro MTA-STS Lookup verifica ambos componentes: el registro DNS y la política HTTPS. Comprueba que el registro exista y tenga un ID válido, que el archivo de política sea accesible vía HTTPS con un certificado válido, que los servidores MX en la política coincidan con los registros MX reales del dominio, y que el modo y el max_age estén configurados correctamente.
Implementación paso a paso
Implementar MTA-STS requiere un servidor web HTTPS para servir la política. Si ya tienes un sitio web para el dominio, puedes crear un subdominio mta-sts.tudominio.com con un certificado SSL válido. Alternativamente, servicios como Cloudflare Workers o GitHub Pages pueden alojar el archivo de política de forma gratuita. El certificado HTTPS debe ser válido y emitido por una CA pública — los certificados autofirmados no son aceptados.
Comienza con mode: testing para recopilar datos sin impactar en la entrega. Monitoriza los informes TLS-RPT durante al menos 2 semanas. Verifica que tu certificado SSL Check sea válido y que tus servidores MX soporten TLS 1.2+. Una vez confirmado que no hay problemas, pasa a mode: enforce. Actualiza el ID en el registro DNS con cada cambio de política para forzar la actualización de la caché en los servidores remitentes.