Ir al contenido principal

STARTTLS, SSL/TLS y SMTP: ¿qué cifrado para tus emails?

Por CaptainDNS
Publicado el 17 de febrero de 2026

Cifrado SMTP: STARTTLS, TLS 1.2, TLS 1.3, DANE y MTA-STS
TL;DR
  • SSL está obsoleto desde 2015 (RFC 7568): el término correcto es TLS. STARTTLS no es un protocolo de cifrado, es un comando que activa TLS en una conexión existente
  • STARTTLS es vulnerable a ataques downgrade: un atacante en la red puede eliminar el anuncio STARTTLS y forzar la comunicación en texto plano. MTA-STS y DANE corrigen esta vulnerabilidad
  • TLS 1.3 es el estándar recomendado para SMTP en 2026: handshake más rápido (1-RTT), cipher suites más seguras, forward secrecy obligatorio
  • Configura tu MTA con TLS obligatorio en salida (smtp_tls_security_level = encrypt en Postfix) y despliega MTA-STS para proteger los emails entrantes

¿Tus emails se transmiten realmente cifrados? En 2024, Google informa que más del 95 % de los emails recibidos por Gmail usan TLS. Pero esta cifra oculta una realidad más matizada: STARTTLS es oportunista por defecto, los ataques downgrade están documentados y muchos servidores aún aceptan TLS 1.0 o cipher suites débiles.

Esta guía va más allá de la simple comparación STARTTLS vs Implicit TLS. Explica cómo funciona el cifrado TLS a nivel de handshake, por qué TLS 1.3 cambia las reglas del juego para SMTP, qué vulnerabilidades explotan los atacantes y cómo configurar un cifrado robusto en los MTA más utilizados (Postfix, Exim, Exchange). Ya sea que administres un servidor de correo o que estés auditando una infraestructura email, saldrás con acciones concretas.

SSL, TLS, STARTTLS: aclarar la terminología

Los términos SSL, TLS y STARTTLS se usan de forma intercambiable en la industria del email. Es una fuente de confusión importante, ya que designan cosas fundamentalmente diferentes.

SSL está muerto, TLS lo reemplazó

SSL (Secure Sockets Layer) es el predecesor de TLS. La última versión, SSL 3.0, se publicó en 1996 y fue oficialmente abandonada por la RFC 7568 en 2015 debido a vulnerabilidades críticas (POODLE, BEAST). Cuando un proveedor de correo menciona "SSL" en 2026, en realidad se refiere a TLS.

ProtocoloAñoEstado en 2026
SSL 2.01995Prohibido (RFC 6176)
SSL 3.01996Prohibido (RFC 7568)
TLS 1.01999Obsoleto (RFC 8996)
TLS 1.12006Obsoleto (RFC 8996)
TLS 1.22008Aceptable
TLS 1.32018Recomendado

En la práctica: si tu servidor SMTP aún acepta SSL 3.0 o TLS 1.0, es vulnerable a ataques conocidos. Desactiva estos protocolos.

STARTTLS no es un protocolo de cifrado

STARTTLS es un comando SMTP (definido en la RFC 3207) que solicita al servidor cambiar una conexión en texto plano a una conexión cifrada TLS. No es SSL, ni TLS, ni un protocolo autónomo: es un mecanismo de actualización (upgrade) de una conexión existente.

La confusión proviene del nombre: "STARTTLS" contiene "TLS", pero no especifica qué versión de TLS se utilizará. La versión negociada depende de la configuración del cliente y del servidor.

Implicit TLS vs Explicit TLS (STARTTLS)

Existen dos formas de establecer TLS en una conexión SMTP:

MétodoPuerto típicoFuncionamientoAnalogía web
Explicit TLS (STARTTLS)25, 587Conexión en texto plano, luego upgrade mediante comando STARTTLSHTTP, luego redirección a HTTPS
Implicit TLS465Conexión TLS desde el primer byteHTTPS nativo en el puerto 443

Con Explicit TLS, siempre hay un momento en que la comunicación es en texto plano (la fase EHLO antes de STARTTLS). Con Implicit TLS, nunca hay comunicación en texto plano. Es esta diferencia la que tiene consecuencias importantes en términos de seguridad.

¿Cómo funciona el cifrado SMTP en la práctica?

Ya sea que uses STARTTLS o Implicit TLS, el cifrado se basa en un handshake TLS. Este proceso de negociación determina la versión del protocolo, el cipher suite utilizado y el intercambio de claves.

El handshake TLS paso a paso

Esto es lo que ocurre cuando un servidor SMTP negocia TLS (después del comando STARTTLS o desde el inicio de la conexión en el puerto 465):

Con TLS 1.2 (4 intercambios, 2-RTT):

  1. ClientHello: el cliente envía las versiones TLS y cipher suites que soporta
  2. ServerHello: el servidor elige la versión TLS y el cipher suite, envía su certificado
  3. Intercambio de claves: el cliente genera un secreto pre-master, lo cifra con la clave pública del servidor
  4. Finished: ambas partes confirman que el canal está cifrado

Con TLS 1.3 (2 intercambios, 1-RTT):

  1. ClientHello: el cliente envía las versiones TLS, cipher suites y sus claves Diffie-Hellman
  2. ServerHello + Finished: el servidor elige los parámetros, envía su certificado y confirma el cifrado

TLS 1.3 fusiona etapas: el handshake pasa de 2-RTT a 1-RTT, lo que reduce la latencia de establecimiento de conexión. Para un servidor MX que procesa miles de conexiones por hora, esta optimización es significativa.

Comparación del handshake TLS 1.2 vs TLS 1.3 en una conexión SMTP

TLS 1.2 vs TLS 1.3: ¿qué diferencias para SMTP?

CriterioTLS 1.2TLS 1.3
Handshake2-RTT1-RTT
Forward secrecyOpcional (depende del cipher)Obligatorio
Cipher suites37 suites (incluyendo débiles)5 suites (todas robustas)
CompresiónSoportada (vulnerable a CRIME)Eliminada
RenegociaciónSoportada (vector de ataque)Eliminada
0-RTT resumptionNoSí (con precauciones)
RFCRFC 5246RFC 8446

El punto clave para SMTP: TLS 1.3 elimina las cipher suites débiles y hace la forward secrecy obligatoria. Con TLS 1.2, un servidor puede negociar RSA sin intercambio Diffie-Hellman, lo que significa que un atacante que obtenga la clave privada del servidor puede descifrar todas las comunicaciones pasadas. Con TLS 1.3, cada sesión usa claves efímeras: aunque la clave privada se filtre, las sesiones pasadas siguen protegidas.

Cipher suites recomendadas en 2026

Para SMTP, configura tu servidor con estas cipher suites, en este orden de preferencia:

TLS 1.3 (no se necesita configuración, las 5 suites son todas seguras):

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256

TLS 1.2 (restringir a suites con forward secrecy):

  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-CHACHA20-POLY1305
  • ECDHE-RSA-CHACHA20-POLY1305
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256

Cipher suites a prohibir: todo lo que contenga RC4, DES, 3DES, MD5, NULL, EXPORT, o RSA sin ECDHE/DHE (sin forward secrecy).

Las vulnerabilidades de STARTTLS y cómo protegerse

STARTTLS es el mecanismo de cifrado más extendido para las conexiones SMTP entre servidores (puerto 25). Pero su diseño oportunista introduce vulnerabilidades explotables.

El ataque downgrade STARTTLS

Cuando un cliente SMTP se conecta a un servidor en el puerto 25, envía EHLO y espera la lista de extensiones. Si el servidor anuncia 250-STARTTLS, el cliente sabe que puede cambiar a TLS. El problema: este intercambio se hace en texto plano.

Un atacante posicionado entre el cliente y el servidor (man-in-the-middle) puede modificar la respuesta EHLO para eliminar la línea 250-STARTTLS. El cliente, al no ver la extensión STARTTLS, continúa en texto plano. El atacante puede entonces leer y modificar todos los emails en tránsito.

# Respuesta legítima del servidor
250-mx1.captaindns.com
250-STARTTLS        <-- el atacante elimina esta línea
250 OK

# Lo que ve el cliente tras el ataque
250-mx1.captaindns.com
250 OK              <-- sin STARTTLS, conexión en texto plano

El ataque STRIPTLS

STRIPTLS es una variante más sofisticada. En lugar de eliminar el anuncio STARTTLS del servidor, el atacante intercepta el comando STARTTLS enviado por el cliente y devuelve un falso error (por ejemplo 454 TLS not available). El cliente abandona TLS y continúa en texto plano, creyendo que se trata de un problema temporal.

Estos dos ataques están documentados y se han observado a escala nacional. En 2014, investigadores demostraron que varios países practicaban el STRIPTLS en las conexiones SMTP internacionales.

MTA-STS: forzar TLS en los emails entrantes

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) es la respuesta del IETF a los ataques downgrade en SMTP. El principio: el dominio destinatario publica una política que dice "todos los servidores que me envían emails deben usar TLS con un certificado válido".

Cómo funciona:

  1. El dominio captaindns.com publica un registro DNS TXT _mta-sts.captaindns.com con un identificador de política
  2. El dominio aloja un archivo https://mta-sts.captaindns.com/.well-known/mta-sts.txt que contiene la política
  3. El servidor remitente consulta esta política antes de conectarse al MX
  4. Si la política está en modo enforce, el servidor remitente rechaza entregar en texto plano
# Registro DNS
_mta-sts.captaindns.com.  TXT  "v=STSv1; id=20260217"

# Archivo de política (HTTPS obligatorio)
version: STSv1
mode: enforce
mx: mx1.captaindns.com
mx: mx2.captaindns.com
max_age: 604800

Limitación: MTA-STS depende de HTTPS para distribuir la política. Si el atacante bloquea el acceso HTTPS al archivo de política, el servidor remitente no puede recuperar la política y puede volver al texto plano. Es un problema de TOFU (Trust On First Use): la política es segura solo después de la primera recuperación exitosa.

DANE (TLSA): autenticar el certificado vía DNS

DANE (DNS-based Authentication of Named Entities, RFC 7672 para SMTP) resuelve el problema de forma diferente. En lugar de publicar una política vía HTTPS, el dominio publica un registro TLSA en el DNS que contiene la huella del certificado TLS esperado.

# Registro TLSA para el MX (puerto 25)
_25._tcp.mx1.captaindns.com.  TLSA  3 1 1 a0b1c2d3e4f5...

Ventajas de DANE:

  • No depende de HTTPS (a diferencia de MTA-STS)
  • Autentica el certificado del servidor vía DNSSEC (no solo "TLS obligatorio", sino "TLS con este certificado")
  • Protege contra ataques downgrade y certificados falsos

Requisito previo: DANE necesita DNSSEC en el dominio. Sin DNSSEC, los registros TLSA no están autenticados y DANE es ineficaz. Es el principal freno a su adopción: solo ~5 % de los dominios usan DNSSEC en 2026.

MecanismoProtege contra downgradeAutentica el certificadoRequisitos
STARTTLS soloNoNoNinguno
MTA-STSSí (tras primera consulta)Sí (CA pública)HTTPS + DNS TXT
DANESíSí (huella exacta)DNSSEC + DNS TLSA
MTA-STS + DANESí (doble protección)Sí (CA + huella)DNSSEC + HTTPS

Mecanismos de protección contra ataques STARTTLS downgrade

Configurar el cifrado TLS en tu servidor SMTP

La teoría está clara. Pasemos a la configuración concreta en los tres MTA más utilizados.

Postfix: activar y reforzar TLS

Postfix es el MTA más desplegado en servidores Linux. La configuración TLS se realiza en main.cf.

TLS entrante (servidor, recepción de emails):

# Activar TLS para conexiones entrantes
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem
smtpd_tls_security_level = may

# Forzar TLS 1.2 como mínimo
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

# Cipher suites (TLS 1.2)
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, RC4

TLS saliente (cliente, envío de emails):

# Activar TLS para conexiones salientes
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Forzar TLS 1.2 como mínimo en salida
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2

# Registrar conexiones TLS (útil para auditoría)
smtp_tls_loglevel = 1

Reforzar aún más: reemplaza smtp_tls_security_level = may por encrypt para rechazar toda conexión en texto plano en salida. Atención: algunos servidores pequeños no tienen TLS, tus emails hacia esos servidores serán bloqueados. Usa dane si DNSSEC está disponible.

Valor security_levelComportamiento
noneSin TLS (no recomendado)
mayTLS oportunista (por defecto, acepta texto plano)
encryptTLS obligatorio (rechaza texto plano)
daneTLS + verificación DANE vía DNSSEC
verifyTLS + verificación del hostname del certificado

Exim: configuración TLS

Exim usa una configuración modular. Las directivas TLS se encuentran en el bloque principal.

# Certificado y clave
tls_certificate = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem

# Anunciar STARTTLS
tls_advertise_hosts = *

# Forzar TLS 1.2 como mínimo
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1

# Exigir TLS para conexiones salientes (opcional)
tls_require_ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:\
  ECDHE-RSA-AES256-GCM-SHA384:\
  ECDHE-ECDSA-AES128-GCM-SHA256:\
  ECDHE-RSA-AES128-GCM-SHA256

Para verificar la configuración: exim -bV muestra las capacidades TLS compiladas.

Microsoft Exchange: imponer TLS

En Exchange (2019+), la configuración TLS se realiza a través de los conectores de recepción y envío.

Conector de recepción (emails entrantes):

# Forzar TLS en el conector de recepción
Set-ReceiveConnector "Default Frontend" -RequireTLS $true

# Desactivar protocolos obsoletos (vía registro de Windows)
# HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
# Desactivar SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1

Conector de envío (emails salientes hacia un socio específico):

# Crear un conector de envío con TLS obligatorio
New-SendConnector -Name "Hacia captaindns.com (TLS)" `
  -AddressSpaces "captaindns.com" `
  -RequireTLS $true `
  -TlsAuthLevel DomainValidation

Nota: RequireTLS $true en un conector de envío significa que Exchange rechaza enviar en texto plano hacia ese destino. Úsalo para los dominios socios que soportan TLS, no para un conector catch-all (algunos mensajes se bloquearían).

Verificar el cifrado de tus emails

Configurar TLS no basta: hay que verificar que el cifrado funciona efectivamente.

Desde Gmail: indicador de cifrado

Gmail muestra un candado en el encabezado de los emails. Un candado gris significa que el email se transmitió por TLS (estándar). Un candado rojo con un signo de exclamación significa que el email no fue cifrado en tránsito.

Para los detalles técnicos, haz clic en "Mostrar original" en Gmail: el encabezado Received contiene la versión TLS y el cipher suite utilizados.

Received: from mx1.captaindns.com (mx1.captaindns.com [203.0.113.10])
  by mx.google.com with ESMTPS id abc123
  (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)

En línea de comandos: openssl s_client

Para probar el cifrado de un servidor MX desde una terminal:

# Prueba STARTTLS en el puerto 25
openssl s_client -connect mx1.captaindns.com:25 -starttls smtp \
  -servername mx1.captaindns.com 2>/dev/null | \
  grep -E "Protocol|Cipher|Verify"

# Resultado esperado
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

Si Protocol muestra TLSv1 o TLSv1.1, tu servidor usa un protocolo obsoleto. Si Verify return code es diferente de 0, el certificado tiene un problema.

Con la herramienta CaptainDNS

El SMTP/MX Connectivity Tester de CaptainDNS prueba automáticamente todos los MX de un dominio y verifica para cada uno: la versión TLS negociada, el cipher suite, la validez del certificado (expiración, SAN, cadena de confianza) y el soporte STARTTLS. El resultado incluye un scoring por servidor MX con códigos de diagnóstico explícitos.

🎯 Plan de acción recomendado

  1. Audita tu configuración actual: verifica la versión TLS y las cipher suites de cada MX con openssl s_client o el SMTP/MX Connectivity Tester
  2. Desactiva SSL 3.0, TLS 1.0 y TLS 1.1: estos protocolos son obsoletos (RFC 8996) y vulnerables. TLS 1.2 es el mínimo, TLS 1.3 es lo recomendado
  3. Restringe las cipher suites: elimina RC4, DES, 3DES, MD5 y las suites sin forward secrecy (ECDHE/DHE obligatorio)
  4. Despliega MTA-STS: publica una política enforce para proteger tus emails entrantes contra ataques downgrade
  5. Activa DANE si DNSSEC está disponible: publica registros TLSA para autenticar los certificados de tus MX vía DNS

FAQ

¿Cuál es la diferencia entre STARTTLS y SSL/TLS?

SSL y TLS son protocolos de cifrado (SSL es el antecesor obsoleto de TLS). STARTTLS no es ni SSL ni TLS: es un comando SMTP que activa el cifrado TLS en una conexión inicialmente en texto plano. Después de STARTTLS, la conexión usa TLS (1.2 o 1.3), pero la fase inicial antes del comando sigue siendo vulnerable a ataques downgrade.

¿Hay que seguir usando SSL para SMTP?

No. SSL 2.0 y 3.0 están prohibidos por las RFC 6176 y 7568. TLS 1.0 y 1.1 son obsoletos desde la RFC 8996. Todo servidor SMTP debe usar TLS 1.2 como mínimo, y TLS 1.3 preferiblemente. Si un proveedor menciona "SSL", en realidad se refiere a TLS.

¿Cómo forzar el cifrado TLS en los emails salientes?

En Postfix, configura smtp_tls_security_level = encrypt en main.cf para rechazar toda conexión en texto plano en salida. En Exchange, activa RequireTLS en el conector de envío. Atención: los emails hacia servidores sin TLS serán bloqueados. Usa el modo dane o may si necesitas entregar a todos los destinatarios.

¿Qué es DANE y cómo protege SMTP?

DANE (DNS-based Authentication of Named Entities) permite publicar la huella del certificado TLS de un servidor MX en un registro DNS TLSA. El servidor remitente verifica que el certificado presentado corresponde a la huella publicada, lo que impide los ataques de certificados falsos y los downgrades. DANE requiere DNSSEC para garantizar la autenticidad de los registros DNS.

¿Cómo verificar si mis emails se transmiten por TLS?

Tres métodos: (1) en Gmail, haz clic en "Mostrar original" y busca los encabezados Received con la versión TLS, (2) en línea de comandos, usa openssl s_client -connect mx:25 -starttls smtp para probar la negociación, (3) usa el SMTP/MX Connectivity Tester de CaptainDNS para un diagnóstico automatizado de todos tus MX.

¿Qué cipher suites usar para SMTP en 2026?

Para TLS 1.3: todas las suites son seguras (AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305). Para TLS 1.2: usa únicamente las suites ECDHE con AES-GCM (forward secrecy obligatorio). Prohíbe RC4, DES, 3DES, MD5, las suites NULL, EXPORT y los intercambios RSA sin ECDHE/DHE.

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

MTA-STS publica una política TLS vía HTTPS (archivo .well-known/mta-sts.txt) que indica que el dominio exige TLS. DANE publica la huella del certificado vía un registro DNS TLSA asegurado por DNSSEC. MTA-STS es más fácil de desplegar (no necesita DNSSEC) pero sufre el problema TOFU (Trust On First Use). DANE ofrece una autenticación más fuerte pero requiere DNSSEC. Ambos pueden desplegarse simultáneamente.

Descarga las tablas comparativas

Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.

📖 Glosario

  • TLS (Transport Layer Security): Protocolo de cifrado de comunicaciones de red. Sucesor de SSL, versiones actuales: TLS 1.2 y TLS 1.3 (RFC 8446).
  • STARTTLS: Comando SMTP (RFC 3207) que solicita la actualización de una conexión en texto plano a TLS. No es un protocolo de cifrado en sí.
  • Implicit TLS: Modo de conexión donde TLS se establece desde el primer byte, sin fase en texto plano. Usado en el puerto 465 (SMTP) y el puerto 443 (HTTPS).
  • Forward secrecy: Propiedad criptográfica que garantiza que el compromiso de una clave privada no permite descifrar las sesiones pasadas. Asegurada por los intercambios de claves ECDHE/DHE.
  • Cipher suite: Combinación de algoritmos utilizados para una sesión TLS: intercambio de claves (ECDHE), autenticación (RSA/ECDSA), cifrado (AES-GCM) y hash (SHA384).
  • DANE: DNS-based Authentication of Named Entities (RFC 7672 para SMTP). Permite autenticar el certificado TLS de un servidor mediante un registro DNS TLSA asegurado por DNSSEC.
  • MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política publicada vía HTTPS que obliga a los servidores remitentes a usar TLS con un certificado válido.
  • Ataque downgrade: Ataque de red que fuerza una conexión a utilizar un protocolo menos seguro, típicamente eliminando el anuncio STARTTLS o modificando la negociación TLS.
  • TOFU: Trust On First Use. Modelo de seguridad donde la confianza se establece durante la primera interacción. MTA-STS sufre este problema: la primera recuperación de la política es vulnerable.

Verifica el cifrado TLS de tus servidores MX: Usa nuestro SMTP/MX Connectivity Tester para probar la versión TLS, las cipher suites y la validez del certificado de cada MX, en pocos segundos.

📚 Guías de SMTP y conectividad email relacionadas

Fuentes

Artículos relacionados