Tu DMARC está configurado en p=reject. Tu SPF está limpio. Cada mensaje saliente lleva una firma DKIM válida. Por todas las métricas que la industria ha definido, el stack de autenticación de tu dominio está completo.
Y, sin embargo, existe una clase de ataque que ninguno de esos registros puede detener – uno que no opera en la capa de políticas, sino en el cable mismo, mientras tu email está en movimiento entre servidores.
MTA-STS es el estándar diseñado para cerrar esa brecha. Según el Informe de Adopción de DMARC y MTA-STS en Estados Unidos 2026 de PowerDMARC, solo el 1,7% de los dominios estadounidenses lo han desplegado. A nivel global, la encuesta 2026 de URIports sobre el millón de dominios más importantes encontró menos del 1% con una política MTA-STS activa. El estándar ha sido publicado como RFC 8461 desde 2018 – ocho años disponible, ampliamente accesible, y casi en ningún lugar desplegado.
El Ataque Que DMARC Nunca Fue Diseñado para Detener
DMARC, SPF y DKIM abordan una amenaza específica: un atacante que suplanta tu dominio enviando emails que afirman provenir de tu dirección. Responden a la pregunta “¿Este email proviene realmente de quien dice ser?”
No abordan lo que ocurre después de que el email sale de tu servidor de correo y antes de que llegue al servidor del destinatario. Ese segmento del viaje – el tránsito SMTP de servidor a servidor – es donde opera una clase diferente de ataque.
SMTP usa un mecanismo llamado STARTTLS para negociar el transporte cifrado entre servidores de correo. El problema es que STARTTLS se anuncia en texto claro. Un atacante posicionado entre los dos servidores – ya sea en la red o a través de un nodo de enrutamiento comprometido – puede interceptar el comando STARTTLS, eliminarlo y reemplazarlo con un mensaje de rechazo. El servidor emisor, al no ver ninguna oferta de TLS del destino, recurre a enviar el email en texto claro.
En ese punto, el atacante puede leer cada palabra del mensaje, modificar el contenido antes de reenviarlo, o capturar credenciales y adjuntos. Tu registro DMARC, tu firma DKIM, tu alineación SPF – ninguno de ellos es visible para un atacante que observa el tráfico SMTP en texto claro. El stack de autenticación permanece intacto e irrelevante.
Esta clase de ataque – conocida como ataque de degradación STARTTLS – ha sido observada a escala nacional. Investigadores de la EFF y equipos universitarios documentaron su uso por parte de múltiples actores estatales para interceptar tráfico de email internacional en rutas SMTP principales.
Qué Hace MTA-STS
MTA-STS (Mail Transfer Agent Strict Transport Security) es la respuesta del IETF a los ataques de degradación STARTTLS.
El mecanismo funciona en dos partes. Un dominio publica un archivo de texto en una ruta HTTPS conocida (https://mta-sts.tudominio.com/.well-known/mta-sts.txt) declarando su política TLS: los nombres de host MX que espera, si el modo es enforce o testing, y una edad máxima de la política. Luego publica un registro DNS TXT en _mta-sts.tudominio.com que señala la versión de la política.
Cuando un servidor de correo emisor busca MTA-STS para tu dominio y encuentra una política enforce, solo entregará correo a través de una conexión TLS con un certificado válido que coincida con los nombres de host MX declarados. Si un atacante elimina la oferta STARTTLS o presenta un certificado no válido, el servidor emisor se niega a entregar – y tú recibes un informe TLS-RPT explicando el fallo.
La diferencia crítica con STARTTLS solo: MTA-STS se obtiene sobre HTTPS antes de que comience la conexión SMTP. Un atacante en la ruta SMTP no puede manipular una política obtenida por HTTPS sin romper la validación del certificado. La política crea un compromiso que la negociación STARTTLS sola no puede crear.
TLS-RPT: El Compañero de Visibilidad
La aplicación de MTA-STS sin informes es protección sin panel de control. TLS-RPT (RFC 8460) es el estándar complementario que cierra ese ciclo.
Publicando un registro DNS TXT _smtp._tls, instruyes a los servidores de correo emisores a informar sobre cada fallo de STARTTLS y MTA-STS que encuentren al entregar correo a tu dominio. Los informes llegan como resúmenes en formato JSON una vez al día – similares en estructura a los informes agregados de DMARC – mostrando qué servidores emisores intentaron la entrega, si la negociación TLS tuvo éxito, y el error específico cuando no lo hizo.
TLS-RPT te indica si alguien está intentando activamente degradar tus conexiones de correo entrante, y qué emisores legítimos están experimentando problemas TLS que pueden afectar silenciosamente la entregabilidad. Al igual que DMARC en p=none, MTA-STS en modo testing proporciona esta visibilidad sin bloquear ningún correo – un punto de partida seguro para cualquier dominio.
La Brecha de Adopción
Las cifras de adopción global para 2026 son llamativas por lo bajas que siguen siendo, a pesar de los ocho años de historia del estándar.
El análisis de PowerDMARC encontró que mientras el 95,7% de los dominios estadounidenses tienen SPF y el 95,8% tienen un registro DMARC, solo el 1,7% ha desplegado MTA-STS. Incluso entre el 49% de los dominios estadounidenses que aplican DMARC en p=quarantine o p=reject, la gran mayoría ha dejado abierta la brecha de seguridad en el tránsito.
Un punto positivo es el Reino Unido. El informe del Reino Unido de PowerDMARC encontró una adopción de MTA-STS del 20,6% – más de doce veces la tasa de EE.UU. – en gran parte atribuible a la orientación del NCSC (Centro Nacional de Seguridad Cibernética) que recomienda explícitamente MTA-STS como parte de la base de seguridad de email del gobierno del Reino Unido. Los dominios gubernamentales lideran con una adopción del 39,9%. Cuando los reguladores establecen expectativas claras, las organizaciones responden.
La encuesta global 2026 de URIports encontró que el despliegue de MTA-STS en el millón de dominios más importantes se ha más que duplicado en los últimos dos años. La dirección es correcta. El ritmo no es suficiente dado que el estándar lleva ocho años disponible.
Cómo Desplegar MTA-STS
Desplegar MTA-STS es un proceso de tres pasos que no requiere cambios en el software instalado localmente:
Paso 1 – Comenzar en modo de prueba. Antes de aplicar la política, publica tu política MTA-STS en mode: testing y habilita el reporte TLS-RPT. Esto te proporciona visibilidad inmediata sobre los fallos TLS sin bloquear ningún correo. Recopila informes durante al menos dos a cuatro semanas para establecer una línea base.
Paso 2 – Validar tu configuración MX. Tu política MTA-STS declara nombres de host MX específicos. Esos nombres de host deben resolver a servidores que presenten certificados TLS válidos y no caducados de una autoridad certificadora de confianza. Si algún host MX tiene un desajuste de certificado o problema de caducidad, cambiar al modo enforce causará fallos de entrega para los emisores que respetan MTA-STS. Soluciona esos problemas antes de aplicar la política.
Paso 3 – Cambiar al modo enforce. Una vez que los informes TLS-RPT confirmen una negociación TLS limpia en todo tu flujo de correo entrante, actualiza tu archivo de política a mode: enforce. Incrementa la cadena de versión de la política en tu registro DNS TXT para que los servidores emisores sepan que deben volver a obtener la política actualizada.
El tiempo transcurrido desde ningún MTA-STS hasta enforce es típicamente de dos a seis semanas para organizaciones que gestionan su propia infraestructura MX. Los proveedores de email alojados – Google Workspace, Microsoft 365 – gestionan automáticamente el lado del certificado MX, haciendo que el paso de publicación de la política sea directo.
DMARC y MTA-STS: Complementarios, No Competidores
DMARC y MTA-STS protegen diferentes superficies del mismo camino del email.
DMARC responde: “¿Este email proviene realmente de quien dice ser?” Opera sobre la identidad del emisor y la autenticación del mensaje. Protege contra la suplantación y la imitación de dominio – ataques que se originan fuera de tu infraestructura.
MTA-STS responde: “¿Este email se está entregando a través de una conexión segura y verificada?” Opera en la capa de transporte. Protege contra la interceptación y modificación mientras el email está en tránsito entre servidores que no controlas.
Un dominio con una fuerte aplicación de DMARC pero sin MTA-STS está asegurando la identidad del emisor mientras deja el canal abierto a la inspección. Ambos registros funcionan a nivel DNS, ambos no requieren hardware ni software local, y ambos son gratuitos de publicar.
La brecha entre el 95,8% de despliegue de DMARC y el 1,7% de MTA-STS es la brecha entre organizaciones que han abordado la suplantación y organizaciones que han abordado la seguridad del transporte. Abordar solo un lado no es una postura de seguridad de email completa – y la superficie de ataque de degradación STARTTLS sigue siendo exactamente igual de explotable contra un dominio con p=reject que contra uno con p=none.
¿Listo para construir una postura de seguridad de email completa más allá de DMARC? Excello Mail te ayuda a configurar y monitorear la capa de aplicación DMARC que sustenta un canal de email seguro. Regístrate gratis en Excello Mail y descubre exactamente dónde está tu dominio en autenticación y más allá.