2026-08-11 · RESEARCH · El equipo de Offensive Technology

SMTP TLS Downgrade: la brecha del 92% detrás de DMARC

Un ataque de SMTP TLS downgrade elimina el cifrado del correo mientras está en tránsito, y la mayoría de los dominios no puede impedirlo. El cifrado clásico de SMTP es oportunista: los servidores ofrecen STARTTLS, pero si un atacante en la ruta elimina esa oferta, el servidor emisor cae en silencio al texto plano en lugar de rechazar el envío. Los únicos registros que hacen obligatorio el TLS son MTA-STS y DANE. Resolvimos el DNS público de los 25.000 sitios principales de Tranco y leímos esos registros para los 18.012 dominios que reciben correo. El resultado es una división marcada. La autenticación es común: 79.3% publica DMARC y 55.2% lo aplica. La aplicación del cifrado en tránsito es rara: solo 3.3% publica una política MTA-STS, 3.6% publica un registro DANE, y apenas 6.5% publica alguno de los dos. Si juntamos ambos datos, la brecha es marcada: de los dominios que aplican DMARC, 92% no publica ni MTA-STS ni DANE, así que su correo está autenticado contra la suplantación pero sigue siendo vulnerable a un downgrade en tránsito.

Qué es en realidad un ataque de SMTP TLS downgrade

El SMTP entre servidores de correo empieza en texto plano. El servidor receptor anuncia sus capacidades, y si admite cifrado, incluye STARTTLS entre ellas. El servidor emisor emite entonces STARTTLS y ambos negocian una sesión TLS. La debilidad está en la palabra oportunista. Si la capacidad STARTTLS no se anuncia, o el handshake TLS falla, o el certificado no valida, el comportamiento histórico por defecto no es abortar. Es enviar el correo en texto plano de todos modos, bajo la premisa de que entregar el mensaje importa más que cifrarlo.

Ese comportamiento por defecto es lo que explota un atacante. Un adversario con posición en la ruta de red, un operador en un proveedor de tránsito, alguien que ha comprometido un router, un actor estatal en una frontera, observa el intercambio inicial en texto plano y elimina la línea STARTTLS de la lista de capacidades del receptor antes de que llegue al emisor. El emisor, al no ver oferta de cifrado, entrega en texto plano. Esto es STARTTLS stripping, y es un downgrade, no una ruptura: no se rompe nada, simplemente se redirige el protocolo a su respaldo sin cifrar. El mensaje, sus adjuntos y cualquier contenido de restablecimiento de contraseña o factura viajan por el cable en claro. La comunidad de operaciones de APNIC tiene un resumen claro del mecanismo (SMTP downgrade attacks and MTA-STS) si quieres la vista a nivel de paquete.

Dos estándares cierran ese respaldo. MTA-STS (RFC 8461) permite que un dominio publique una política que dice, en efecto, "para mi correo entrante, se requiere TLS con un certificado válido, no hagas fallback". Un emisor que haya obtenido y cacheado esa política rechazará una conexión despojada en lugar de degradarla. DANE para SMTP (RFC 7672) cumple la misma función publicando un registro TLSA en el DNS, autenticado por DNSSEC, que fija qué certificado debe presentar el servidor de correo. Cualquiera de los dos convierte un downgrade silencioso en una entrega rechazada. Ninguno está activado por defecto, y esa es toda la historia detrás de las cifras que siguen.

Por qué DMARC no ayuda aquí

Vale la pena ser precisos en esto, porque los dos problemas se confunden constantemente. DMARC, SPF y DKIM son autenticación. Permiten que un receptor decida si la dirección visible de From es legítima, y DMARC le indica al receptor qué hacer cuando no lo es. Así es como se impide que alguien falsifique tu dominio. Medimos esa capa en un post anterior sobre la brecha entre publicar y aplicar DMARC, y es relevante. Pero autenticación y cifrado son ortogonales. DMARC opera sobre quién dice ser el remitente del mensaje. Un ataque de downgrade opera sobre el transporte que lleva el mensaje. Puedes pasar todas las verificaciones de autenticación con nota máxima y aun así tener la conexión despojada a texto plano, porque DMARC nunca tuvo opinión sobre el transporte, para empezar.

Así que un dominio en p=reject con SPF y DKIM perfectamente alineados ha resuelto la suplantación y no ha hecho nada respecto a la interceptación. El correo que llega es demostrablemente del remitente correcto y fue legible por cualquiera en la ruta. Esa es la confusión que esta medición existe para corregir: un check de DMARC en verde no es un candado en el sobre.

Los datos: autenticado, no cifrado

Aquí está el panorama de adopción en los 18.012 dominios receptores de correo de la muestra. La barra de autenticación es alta. Las dos barras que realmente detienen un downgrade son casi inexistentes.

Los mecanismos de seguridad de transporte, desglosados, con lo que aporta cada uno, están abajo. Lee juntas las dos últimas filas: sumando MTA-STS y DANE, solo una pequeña minoría de dominios de correo tiene alguna aplicación contra un downgrade, y casi ninguno ejecuta ambos.

Un detalle de esa tabla merece una pausa. DANE (3.6%) es marginalmente más común que MTA-STS (3.3%), lo que va en contra del supuesto habitual de que MTA-STS ganaba porque no necesita DNSSEC. Los dos apenas se solapan: solo el 0.3% de los dominios de correo publica ambos. En la práctica son dos bandos. Proveedores y zonas de código de país que ya firman con DNSSEC se inclinan por DANE, todos los demás que se molestan en hacer algo se inclinan por MTA-STS, y la unión de ambos esfuerzos aún deja al 93.5% de los dominios de correo sin ninguna aplicación.

La brecha del 92%

El número que vale la pena recordar es el cruce de datos. De los 9.945 dominios que aplican DMARC en quarantine o reject, 9.192, es decir el 92%, no publica ni una política MTA-STS ni un registro DANE. Estos no son rezagados que ignoraron la seguridad del correo. Son los dominios que hicieron el trabajo más difícil y visible de llevar DMARC a la aplicación, y luego se detuvieron a una capa de distancia. Han decidido que un remitente falsificado es inaceptable, lo cual es correcto, mientras dejan el mensaje real legible en tránsito para cualquiera con posición para despojar la sesión.

Enmárcalo desde la silla del atacante, porque esa silla decide si un control importa. Supón que quieres leer o alterar correo que fluye hacia un objetivo, no falsificarlo. Buscas una posición en la ruta y un dominio que haga downgrade. Revisas el DNS del objetivo igual que hicimos nosotros. Si el dominio publica una política MTA-STS en modo enforce, o un registro DANE en una zona firmada, un servidor emisor que la respete se negará a entregarte una sesión en texto plano, y tu downgrade falla en el emisor. Si el dominio no publica ninguno de los dos, lo cual describe al 92% del conjunto que aplica y al 93.5% de todos los dominios de correo, el STARTTLS oportunista es la norma y un strip devuelve texto plano. La postura de DMARC que también ves en esa consulta DNS no cambia nada de este resultado. Nunca ibas a falsificar al remitente. Ibas a leer el correo.

Lo que hace que este número valga la pena citar es cómo se produjo. Esta es una medición pasiva independiente, no telemetría de proveedor. No reportamos sobre correo filtrado por un producto propio, ni extrapolamos a partir del flujo entrante de un solo proveedor. Leímos los registros de política pública que lee cada servidor emisor en internet, para una muestra fija en una fecha fija. Encuestas de adopción previas llegan a la misma conclusión desde puntos de vista distintos: rastreadores independientes como la encuesta MTA-STS de URIports sitúan la adopción en dígitos individuales bajos y en lento aumento, lo cual coincide con lo que vemos en el DNS crudo.

Cómo revisar y corregir tu propio dominio

No necesitas una herramienta ni un registro. Una consulta DNS es una lectura pasiva de registros ya públicos, así que puedes ejecutar esto contra tu propio dominio ahora mismo.

• Revisa MTA-STS. Ejecuta dig TXT _mta-sts.yourdomain.com +short. Un registro que empiece con v=STSv1 significa que anuncias una política. Si está vacío, no tienes MTA-STS. Ten en cuenta que el registro solo apunta a una política; el archivo de política en https://mta-sts.yourdomain.com/.well-known/mta-sts.txt debe decir mode: enforce para bloquear de verdad, no mode: testing.
• Revisa DANE. Primero encuentra tus servidores de correo con dig MX yourdomain.com +short, luego para cada host MX ejecuta dig TLSA _25._tcp.that-mx-host +short. Un registro TLSA significa que DANE está en juego. DANE solo valida en una zona firmada con DNSSEC, así que confirma la firma con dig DS yourdomain.com +short.
• Activa el reporte. Publica un registro TLS-RPT (RFC 8460) en _smtp._tls.yourdomain.com para que los handshakes fallidos y los downgrades se te reporten en lugar de permanecer invisibles. No bloquea nada, pero es cómo descubres que está ocurriendo un downgrade.

Si tanto la consulta de MTA-STS como la de TLSA vuelven vacías, tu correo entrante está protegido contra la suplantación y expuesto a la interceptación. La solución es publicar una política MTA-STS en modo enforce, o un registro DANE TLSA en una zona firmada, o ambos. Hacer cualquiera de los dos te sitúa en la pequeña minoría. El criterio para desplegar uno sin romper la entrega legítima es el mismo criterio detrás de saber cuáles de tus otros controles expuestos importan de verdad, que es el objetivo de leer una superficie como lo hace un atacante en lugar de confiar en los checks en verde.

Lo que esto no demuestra

Límites honestos, porque un número sin sus salvedades es marketing.

• Tranco clasifica por popularidad agregada, no por tráfico. La lista Tranco combina varios rankings de proveedores para ser estable y difícil de manipular, pero no es un censo de tráfico. Lee estas cifras como una rebanada honesta de la web popular, no de todo internet.
• MTA-STS se mide en la señal DNS. Contamos un dominio como con MTA-STS si publica el registro _mta-sts. Deliberadamente no obtuvimos el archivo de política, lo cual implicaría contactar al hosting web del dominio, así que no podemos separar mode: enforce de mode: testing. La proporción que realmente aplica es por tanto igual o inferior al 3.3%, lo que amplía la brecha, no la reduce.
• DANE se mide por la presencia de TLSA. Revisamos la presencia de un registro TLSA en los hosts MX, hasta cinco por dominio. Un registro publicado señala intención y configuración; no verificamos la cadena DNSSEC ni que cada emisor la valide, así que trata el 3.6% como el techo del DANE que funciona correctamente.
• Es una fotografía. El DNS cambia a diario. Estas cifras describen el 11 de agosto de 2026, no una tendencia, aunque coinciden con encuestas independientes que muestran una adopción baja y en lento ascenso.
• La aplicación en tránsito aún depende del emisor. MTA-STS y DANE solo ayudan cuando el servidor emisor los respeta. Un publicador hace lo correcto anunciando la política; un emisor que la ignora aún puede hacer downgrade. Los registros son necesarios, no suficientes por sí solos.

Preguntas frecuentes

¿Qué es un ataque de downgrade de STARTTLS?

Es cuando un atacante en la ruta de red entre dos servidores de correo elimina la oferta del servidor de cambiar a TLS desde el inicio en texto plano de la sesión SMTP. Como el STARTTLS oportunista cae en texto plano cuando no se ofrece TLS, el emisor entonces entrega el correo sin cifrar y el atacante puede leerlo o alterarlo. MTA-STS y DANE cierran ese respaldo indicando al emisor que se requiere TLS.

¿Está el SMTP cifrado en tránsito por defecto?

No de forma fiable. La mayoría de los servidores ofrece STARTTLS, pero el TLS clásico de SMTP es oportunista: si falta la oferta o el certificado no valida, el emisor cae en silencio al texto plano. El cifrado ocurre cuando nada interfiere, pero un atacante activo puede despojarlo. Solo el 6.5% de los dominios de correo que medimos hace obligatorio el TLS con MTA-STS o DANE.

¿Cifra DMARC el correo en tránsito?

No. DMARC, junto con SPF y DKIM, autentica al remitente para que un receptor pueda detectar una dirección From falsificada. No dice nada sobre si la conexión está cifrada. Un dominio puede aplicar DMARC en p=reject y aun así tener su correo entregado en texto plano tras un downgrade. En nuestra muestra, el 92% de los dominios que aplican DMARC no publicó ni MTA-STS ni DANE.

¿Previene MTA-STS los ataques de downgrade de TLS?

Sí, esa es su función. MTA-STS publica una política que indica a los servidores emisores que tu dominio requiere TLS con un certificado válido, así que un emisor que haya cacheado la política rechaza una conexión despojada en lugar de caer en el respaldo. Su único límite es trust-on-first-use: un emisor que nunca haya obtenido tu política aún no está cubierto, que es donde DANE, anclado en DNSSEC, es más sólido.

¿Cuál es la diferencia entre MTA-STS y DANE?

Ambos fuerzan TLS en el SMTP entrante pero anclan la confianza de forma distinta. MTA-STS se apoya en el sistema de certificados web más trust-on-first-use y no necesita DNSSEC. DANE publica un registro TLSA autenticado por DNSSEC, lo que elimina la brecha del primer uso pero requiere una zona firmada. En nuestro censo se adoptaron a un ritmo casi igual de bajo, 3.3% y 3.6%, y solo el 0.3% de los dominios de correo publicó ambos.

¿Qué porcentaje de dominios ha desplegado MTA-STS?

En nuestro censo de agosto de 2026 del top 25.000 de Tranco, de los 18.012 dominios que reciben correo, el 3.3% publicó un registro MTA-STS. DANE estaba en 3.6% y TLS-RPT en 3.9%. Contando cualquier control de aplicación, el 6.5% requiere TLS en tránsito, frente al 79.3% que publica DMARC.

¿Cómo compruebo si mi propio dominio resiste un downgrade de SMTP?

Ejecuta dig TXT _mta-sts.yourdomain.com +short y busca v=STSv1, y dig TLSA _25._tcp.your-mx-host +short para cada host MX. Si ambos están vacíos, tu correo entrante depende del STARTTLS oportunista y puede sufrir un downgrade. Publicar una política MTA-STS en modo enforce, o un registro DANE en una zona firmada, cierra la brecha.

Lecturas relacionadas

• ¿Basta con p=none? Publicar DMARC no es lo mismo que aplicarlo. La capa de autenticación junto a la que se sitúa este post.
• ¿Qué tan expuestos están los dominios más concurridos del mundo a la suplantación de correo? La pregunta de presencia para el lado antisuplantación.
• ¿Cuántos dominios principales restringen quién puede emitir sus certificados? El mismo método de DNS pasivo, aplicado a los registros CAA.