1. El Problema de STARTTLS Opportunistic (RFC 3207)
Por defecto, las conexiones SMTP entre servidores de correo (MTA a MTA) utilizan Opportunistic TLS. Cuando un servidor emite la orden STARTTLS en el puerto 25, si un atacante en la ruta de red (Man-in-the-Middle) intercepta el paquete y elimina el banner STARTTLS o inyecta una falla de negociación, los MTAs degradan silenciosamente la transmisión a texto claro (cleartext), permitiendo la escucha no autorizada.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) soluciona esto permitiendo a los dominios declarar explícitamente que el canal SMTP debe utilizar TLS v1.2+ con certificados válidos alineados con los servidores MX.
2. Estructura de la Política HTTPS .well-known/mta-sts.txt
La política MTA-STS debe servirse obligatoriamente mediante HTTPS en el subdominio mta-sts.tudominio.com bajo la ruta estricta /.well-known/mta-sts.txt.
mode: enforce— Exige conexión TLS y certificado X.509 válido. Si la negociación falla, el correo es rechazado.mode: testing— Monitorea fallos sin bloquear el correo. Recomendado durante el despliegue inicial.max_age— Tiempo en segundos que los receptores almacenan en caché la política (ej. 604800s = 7 días).
3. Publicación de Registros DNS TXT y TLS-RPT (RFC 8460)
Para señalar la disponibilidad de la política y recibir reportes de fallos en negociaciones TLS: