Ataques de downgrade SMTP: cómo funcionan y cómo protegerse

Por CaptainDNS
Publicado el 9 de marzo de 2026

Esquema de un ataque de downgrade SMTP que muestra a un atacante interceptando la conexión STARTTLS entre dos servidores de correo

TL;DR

SMTP transmite los correos en texto claro por defecto. STARTTLS agrega cifrado, pero sigue siendo vulnerable a ataques de downgrade (STARTTLS stripping)
Un atacante posicionado en la red puede eliminar la opción STARTTLS de la respuesta del servidor, forzando el envío en texto claro sin que el remitente lo detecte
MTA-STS (RFC 8461) y DANE/TLSA (RFC 7672) imponen el cifrado TLS obligatorio y bloquean estos ataques
Aloje su política MTA-STS de forma gratuita con CaptainDNS: dos registros DNS son suficientes para proteger sus dominios en menos de 5 minutos

Cada día, miles de millones de correos circulan entre servidores SMTP. La mayoría utilizan STARTTLS para cifrar la conexión. Pero este cifrado es oportunista: si el servidor remoto no responde al cifrado, el mensaje se envía en texto claro. Un atacante posicionado en la red puede forzar este comportamiento con un simple paquete de red.

Los ataques de downgrade SMTP, también llamados STARTTLS stripping, explotan esta debilidad. Permiten interceptar correos en texto claro, incluso cuando ambos servidores soportan el cifrado TLS. El problema: ni el remitente ni el destinatario son informados del ataque.

Este artículo detalla el mecanismo técnico de estos ataques, sus variantes, su impacto real según los datos de Google, y las soluciones concretas para proteger sus dominios. Si usted gestiona servidores de correo o la seguridad de un dominio, esta guía es para usted.

Cómo SMTP transmite sus correos

SMTP (Simple Mail Transfer Protocol, RFC 5321) es el protocolo utilizado para enrutar los correos entre servidores. Diseñado en 1982, no prevé ningún cifrado nativo. Cada mensaje transita en texto claro entre el servidor emisor y el servidor receptor.

STARTTLS: un cifrado oportunista

En 2002, la RFC 3207 introduce STARTTLS. Este mecanismo permite a dos servidores SMTP negociar una conexión TLS después del establecimiento de la conexión inicial en texto claro.

El proceso se desarrolla así:

El servidor emisor abre una conexión TCP en el puerto 25
El servidor receptor responde con sus capacidades, incluyendo 250 STARTTLS
El servidor emisor envía el comando STARTTLS
Ambos servidores negocian una conexión TLS
El correo se transmite de forma cifrada

S: 220 mx.captaindns.com ESMTP
C: EHLO mail.captaindns.com
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← el servidor anuncia soporte TLS
S: 250 OK
C: STARTTLS            ← el cliente solicita el cifrado
S: 220 Ready to start TLS
[Negociación TLS]
C: EHLO mail.captaindns.com
[Transmisión cifrada del correo]

Por qué "oportunista" es un problema

La palabra clave es oportunista. Si el comando STARTTLS falla o no es propuesto, el servidor emisor envía el correo en texto claro sin avisar a nadie. Es una decisión de diseño: la RFC 3207 prioriza la entrega del mensaje sobre su confidencialidad.

Esta decisión crea la vulnerabilidad explotada por los ataques de downgrade.

Esquema del flujo SMTP normal vs atacado: comparación de una conexión STARTTLS exitosa y una conexión degradada por un atacante

Anatomía de un ataque de downgrade SMTP

Un ataque de downgrade SMTP, o STARTTLS stripping, consiste en impedir la negociación TLS entre dos servidores de correo. El atacante fuerza el regreso a una conexión en texto claro.

¿Cómo funciona el STARTTLS stripping?

El atacante debe posicionarse en la ruta de red entre los dos servidores (man-in-the-middle). Intercepta los paquetes TCP y modifica la respuesta del servidor receptor:

El servidor emisor envía EHLO al servidor receptor
El servidor receptor responde con 250 STARTTLS en sus capacidades
El atacante intercepta esta respuesta y elimina la línea 250 STARTTLS
El servidor emisor recibe una respuesta sin mención de STARTTLS
El servidor emisor concluye que el receptor no soporta el cifrado
El correo se envía en texto claro
El atacante lee el contenido del mensaje

[Respuesta original del servidor receptor]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← presente
S: 250 OK

[Respuesta modificada por el atacante]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250 OK              ← STARTTLS eliminado

El ataque es invisible para ambos servidores. El servidor emisor cree que el receptor no soporta TLS. El servidor receptor no sabe que un correo le fue enviado en texto claro.

¿Quién puede lanzar este ataque?

Cualquier entidad posicionada en la ruta de red:

Proveedores de acceso a internet (ISP): controlan el enrutamiento del tráfico
Operadores de redes intermedias: puntos de intercambio de internet (IXP)
Atacantes en la red local: Wi-Fi público, red empresarial comprometida
Actores estatales: vigilancia masiva documentada en ciertos países

Variantes de ataques al transporte de correo

El STARTTLS stripping es la variante más conocida, pero otros ataques apuntan al transporte de correo.

Spoofing DNS de registros MX

El atacante falsifica la respuesta DNS para los registros MX del dominio receptor. El servidor emisor envía entonces el correo hacia un servidor falso controlado por el atacante.

; Respuesta DNS legítima
captaindns.com. MX 10 mx.captaindns.com.

; Respuesta DNS falsificada por el atacante
captaindns.com. MX 10 mx.atacante.com.

DNSSEC protege contra este ataque firmando criptográficamente las respuestas DNS.

Ataque al certificado TLS

Incluso si STARTTLS es negociado, SMTP no valida el certificado del servidor receptor por defecto. Un atacante puede presentar un certificado autofirmado o inválido, y el servidor emisor aceptará la conexión sin verificación.

MTA-STS y DANE imponen la validación del certificado, bloqueando esta variante.

Secuestro BGP

Un atacante anuncia rutas BGP falsas para redirigir el tráfico de red hacia sus propios equipos. Este ataque apunta a la infraestructura de red y puede afectar todo el tráfico, no solo los correos.

Impacto real: ¿quién está afectado?

Las cifras de Google

El Transparency Report de Google sobre el cifrado de correos en tránsito revela datos concretos:

Más del 90 % de los correos entrantes hacia Gmail están cifrados con TLS
Más del 90 % de los correos salientes de Gmail utilizan TLS
Ciertas regiones y ciertos proveedores permanecen por debajo del 70 %

Estas cifras muestran que el cifrado SMTP ha progresado, pero que persisten lagunas. Cada correo no cifrado representa una oportunidad para un ataque de downgrade.

Sectores más expuestos

Sector	Riesgo	Razón
Salud	Elevado	Datos de pacientes, cumplimiento HIPAA/RGPD
Finanzas	Elevado	Información financiera sensible
Jurídico	Elevado	Secreto profesional, confidencialidad del cliente
Administración	Medio	Datos de ciudadanos, procesos internos
PYME	Medio	Infraestructura de correo a menudo mal configurada

Ataques documentados

Investigaciones publicadas por la EFF y la APNIC han documentado casos de STARTTLS stripping a gran escala por parte de operadores de red en varios países. Estos ataques no apuntan a un dominio específico: interceptan todo el tráfico SMTP que transita por la infraestructura comprometida.

Cómo protegerse contra los ataques de downgrade

Cuatro mecanismos complementarios permiten asegurar el transporte de correo.

Las cuatro capas de protección contra ataques de downgrade SMTP: MTA-STS, DANE, TLS-RPT y DNSSEC

MTA-STS (RFC 8461): el cifrado TLS obligatorio

MTA-STS permite a un dominio publicar una política que impone el cifrado TLS a los servidores emisores. La política se aloja en un servidor HTTPS, un canal separado y autenticado que el atacante no puede comprometer con STARTTLS stripping.

Funcionamiento:

El servidor emisor descubre el registro TXT _mta-sts.captaindns.com
Descarga la política desde https://mta-sts.captaindns.com/.well-known/mta-sts.txt
La política indica los servidores MX autorizados y el modo (testing/enforce)
En modo enforce, el servidor rechaza enviar en texto claro

Ventaja: no requiere DNSSEC. Funciona con cualquier registrador.

Limitación: la primera solicitud (antes del almacenamiento en caché) sigue siendo vulnerable (TOFU, Trust On First Use).

DANE/TLSA (RFC 7672): el certificado anclado en el DNS

DANE publica la huella del certificado TLS directamente en un registro TLSA del DNS. El servidor emisor verifica que el certificado presentado corresponda al declarado en el DNS.

Ventaja: sin TOFU. La verificación es inmediata desde la primera conexión.

Limitación: requiere DNSSEC en toda la cadena DNS, lo que limita la adopción.

TLS-RPT (RFC 8460): la visibilidad sobre los fallos

TLS-RPT no bloquea los ataques, pero los hace visibles. Los servidores emisores que soportan TLS-RPT envían informes diarios sobre los fallos de negociación TLS.

Estos informes permiten detectar:

Intentos de downgrade
Certificados caducados o inválidos
Problemas de configuración en sus servidores MX

Configure TLS-RPT con nuestro generador TLS-RPT para recibir estos informes.

DNSSEC: la protección del DNS

DNSSEC firma criptográficamente las respuestas DNS, impidiendo el spoofing de los registros MX. Es la base de DANE, pero también refuerza la seguridad de MTA-STS al proteger la resolución del registro _mta-sts.

🎯 Plan de acción recomendado

Verifique su configuración actual: utilice el verificador MTA-STS para analizar el estado de su dominio
Active MTA-STS en modo testing: aloje su política de forma gratuita con CaptainDNS y supervise los informes TLS-RPT durante 1 a 2 semanas
Configure TLS-RPT: reciba los informes de fallos TLS para detectar problemas antes de que afecten a sus correos
Pase a modo enforce: cuando los informes confirmen que todo funciona, active el modo enforce para bloquear las conexiones no cifradas
Evalúe DANE: si su registrador y su proveedor DNS soportan DNSSEC, agregue registros TLSA para una protección sin TOFU

Proteja sus correos contra los ataques de downgrade ahora: aloje su política MTA-STS de forma gratuita con CaptainDNS. Dos registros DNS, cero servidores web que gestionar.

FAQ

¿Qué es un ataque de downgrade SMTP?

Un ataque de downgrade SMTP (o STARTTLS stripping) consiste en impedir la negociación del cifrado TLS entre dos servidores de correo. El atacante, posicionado en la red, elimina la opción STARTTLS de la respuesta del servidor receptor. El servidor emisor envía entonces el correo en texto claro, permitiendo al atacante leer el contenido del mensaje.

¿Cómo detectar un ataque de downgrade en mis correos?

Configure TLS-RPT (RFC 8460) para su dominio. Los servidores emisores compatibles enviarán informes diarios listando los fallos de negociación TLS. Un aumento repentino de los fallos puede indicar un intento de downgrade. Active también MTA-STS en modo testing para recibir informes sin bloquear la entrega.

¿MTA-STS protege contra todos los ataques de downgrade?

MTA-STS protege contra el STARTTLS stripping y los ataques a los certificados TLS. No protege contra el spoofing DNS de los registros MX (utilice DNSSEC para eso) ni contra el secuestro BGP. Para una protección completa, combine MTA-STS con DNSSEC y, si es posible, DANE/TLSA.

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

MTA-STS publica una política vía HTTPS y funciona sin DNSSEC. DANE ancla el certificado TLS en el DNS mediante registros TLSA y requiere DNSSEC. MTA-STS sufre del problema TOFU (la primera solicitud no está protegida). DANE ofrece una verificación inmediata. Ambos son complementarios.

¿STARTTLS es suficiente para asegurar mis correos?

No. STARTTLS cifra la conexión de manera oportunista, pero no protege contra los ataques de downgrade ni contra los certificados inválidos. Un atacante de red puede eliminar la opción STARTTLS o presentar un certificado falso. MTA-STS o DANE son necesarios para imponer el cifrado TLS.

¿Los grandes proveedores como Gmail y Outlook son vulnerables?

Gmail y Microsoft 365 soportan MTA-STS como servidores emisores: verifican y respetan las políticas MTA-STS de los dominios receptores. Si su dominio publica una política MTA-STS en modo enforce, Gmail y Outlook rechazarán enviar en texto claro hacia sus servidores, incluso en caso de intento de downgrade.

¿Es necesario activar MTA-STS y DANE al mismo tiempo?

No es obligatorio, pero se recomienda si su infraestructura lo permite. MTA-STS es más sencillo de implementar (no necesita DNSSEC) y cubre la mayoría de los servidores emisores. DANE ofrece una seguridad adicional (sin TOFU) para los servidores que lo soportan. Ambos mecanismos coexisten sin conflicto.

📖 Glosario

STARTTLS: extensión SMTP (RFC 3207) que permite negociar una conexión TLS después del establecimiento de una conexión en texto claro en el puerto 25.
STARTTLS stripping: ataque que consiste en eliminar el anuncio STARTTLS de la respuesta del servidor para impedir el cifrado.
MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política HTTPS que impone el cifrado TLS para la recepción de correos.
DANE: DNS-Based Authentication of Named Entities (RFC 7672). Mecanismo que ancla el certificado TLS en el DNS mediante registros TLSA.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de informes sobre los fallos de negociación TLS entre servidores de correo.
TOFU: Trust On First Use. Modelo de seguridad donde la primera conexión no se verifica, pero las conexiones siguientes se validan respecto a la primera.
DNSSEC: DNS Security Extensions. Sistema de firmas criptográficas que autentica las respuestas DNS e impide su falsificación.

📚 Guías de seguridad del transporte de correo relacionadas

MTA-STS vs DANE: ¿qué protocolo elegir para asegurar el transporte de correo? (próximamente)
De testing a enforce: estrategia de implementación progresiva de MTA-STS (próximamente)