TLS para SMTP — STARTTLS, TLS implícito, MTA-STS y por qué cifrar el transporte importa más cada año

El email sin cifrar fue la norma durante décadas. En 2026, sigue siendo común encontrar configuraciones SMTP que negocian TLS opcionalmente y aceptan downgrade a texto plano si el otro extremo no lo soporta. Esto es problema operativo, regulatorio y de marca: emails legítimos pasando por internet en claro, contenido leíble por cualquier punto intermedio. Este post cubre cómo pasar el cifrado de "está ahí cuando funciona" a "es requisito de la conexión": diferencia entre STARTTLS y TLS implícito, configuración correcta por MTA, y los mecanismos modernos para forzar cifrado entre servidores.

El problema histórico: SMTP nació sin cifrado

SMTP original (RFC 821, 1982) no contemplaba cifrado. Los emails viajaban en texto plano. Las extensiones de cifrado son adiciones posteriores: STARTTLS (RFC 3207, 2002), SMTPS sobre TLS implícito (deprecated en RFC 8314, 2018, reactivado como práctica), MTA-STS (RFC 8461, 2018), DANE/TLSA (RFC 7672, 2015). Cada capa resolvió un problema específico que las anteriores no cubrían.

El problema fundamental que persiste: el cifrado en SMTP entre MTAs es opportunistic por defecto. Si el receptor anuncia STARTTLS, el sender lo usa. Si no, el mensaje va en claro. Esto significa que un atacante con capacidad de manipular el tráfico de red (man-in-the-middle, BGP hijacking, DNS spoofing) puede hacer downgrade del cifrado: stripping de la respuesta STARTTLS del servidor, forzando comunicación en claro. MTA-STS y DANE son los mecanismos diseñados específicamente para prevenir este downgrade attack.

STARTTLS vs TLS implícito (SMTPS)

Hay dos formas de hacer SMTP cifrado en práctica:

STARTTLS (puerto 587 o 25): la conexión empieza en texto plano. El cliente envía EHLO, el servidor anuncia capacidades incluyendo 250-STARTTLS, el cliente envía STARTTLS, el servidor responde 220 Ready to start TLS, y la conexión negocia TLS. Después de TLS, el cliente envía EHLO de nuevo (las capacidades pueden cambiar tras autenticación cifrada) y continúa la conversación SMTP cifrada.

TLS implícito o SMTPS (puerto 465): la conexión empieza directamente en TLS, sin negociación previa en texto plano. El cliente abre socket TLS al puerto 465, completa el handshake TLS, y luego empieza la conversación SMTP. Es más simple operativamente y elimina ventana donde un downgrade attack podría inyectar comandos.

Recomendación práctica en 2026: para envío desde aplicación a relay (submission), usar puerto 587 con STARTTLS o puerto 465 con TLS implícito — ambos son aceptables, el 465 es ligeramente preferible por simplicidad y resistencia a downgrade. Para envío entre MTAs (puerto 25), STARTTLS sigue siendo el estándar de facto.

Versiones TLS — qué es aceptable en 2026

Las versiones de TLS que circulan tienen distinto perfil de seguridad. La práctica actual:

• TLS 1.3 (RFC 8446, 2018): preferida. Handshake más rápido, perfect forward secrecy obligatorio, criptografía moderna.
• TLS 1.2 (RFC 5246, 2008): aceptable. Sigue siendo segura con configuración correcta de cipher suites.
• TLS 1.1 y 1.0: deprecadas (RFC 8996, 2021). Deshabilitar en MTA. Cualquier receptor todavía requiriendo 1.1/1.0 está mal mantenido — reportarlo y dejar que el envío falle.
• SSL 3.0 y anteriores: críticamente inseguras. Vulnerables a POODLE y otros ataques. Deshabilitadas hace años en MTAs serios.

En Postfix, configurar versiones aceptables en main.cf:

smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_eecdh_grade = ultra

Esto deja TLS 1.2 y 1.3 como únicas versiones aceptables tanto para conexiones entrantes (smtpd_) como salientes (smtp_).

MTA-STS — forzar cifrado entre servidores

El problema con STARTTLS opportunistic: el sender no sabe si el receptor "siempre debería" soportar TLS. Si por algún motivo el receptor no anuncia STARTTLS hoy (mal mantenimiento, downgrade attack, configuración nueva mal hecha), el sender envía en claro porque no tiene política que diga "este dominio siempre cifra".

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) resuelve esto. Un dominio publica una política diciendo: "los servidores que envían correo a este dominio deben usar TLS válido. Si TLS falla o no está disponible, el envío debe fallar, no degradar a texto plano."

La política MTA-STS se publica en dos lugares:

1) Registro DNS TXT en _mta-sts.{dominio}:

_mta-sts.su-empresa.com.  TXT  "v=STSv1; id=20260101120000Z"

El id es un identificador que cambia cuando la política se actualiza, indicando a los senders que deben re-cachear.

2) Política HTTPS servida en https://mta-sts.{dominio}/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.su-empresa.com
mx: mx2.su-empresa.com
max_age: 604800

Modos disponibles: none (no aplicar política — útil para retirar MTA-STS de forma controlada), testing (los senders reportan errores pero no rechazan), enforce (requerir TLS válido).

Despliegue conservador: empezar en testing durante 4-8 semanas, revisar reportes (vía TLS-RPT, ver más abajo), confirmar que todo cifra correctamente, mover a enforce.

DANE/TLSA — alternativa basada en DNSSEC

DANE (DNS-based Authentication of Named Entities, RFC 6698) y su perfil para SMTP (RFC 7672) usan DNSSEC para publicar el certificado o clave del MX directamente en DNS. El sender consulta el registro TLSA del MX, verifica que el certificado presentado en el handshake TLS coincide, y solo entonces continúa el envío.

La ventaja sobre MTA-STS: no requiere HTTPS adicional, todo va por DNS. La desventaja: requiere DNSSEC en todo el chain, lo que tiene adopción menor que MTA-STS por la complejidad operativa de DNSSEC.

En la práctica, MTA-STS tiene más adopción en 2026 que DANE para email, principalmente porque no requiere DNSSEC. Para operaciones que ya tienen DNSSEC desplegado, DANE es opción técnica equivalente y a veces preferida en sectores específicos (sector público europeo donde DNSSEC es estándar).

TLS-RPT — reportes de fallos TLS

TLS-RPT (SMTP TLS Reporting, RFC 8460) complementa MTA-STS y DANE permitiendo que los senders reporten al receptor cuando el cifrado falla. El receptor publica un registro DNS:

_smtp._tls.su-empresa.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@su-empresa.com"

Senders compatibles (Gmail, Microsoft, Yahoo, Mailchimp, varios MTAs) generan reportes JSON diariamente con estadísticas de éxito/fallo TLS, razones de fallo (certificate expired, hostname mismatch, downgrade detected). Procesados en herramientas tipo Postmark TLS reporting o construidos custom, dan visibilidad operativa sobre la salud de TLS al recibir.

Para senders, el equivalente es procesar reportes que llegan al rua del propio dominio si se publica MTA-STS — saber qué receptores intentan enviarles email y qué versión TLS negocia.

Troubleshooting de problemas TLS frecuentes

"unable to verify certificate": el certificado del peer no es válido (expirado, hostname mismatch, autoridad no confiable, certificate chain incompleta). En envío opportunistic muchos MTAs degradan a unauthenticated TLS o texto plano. Con MTA-STS enforce, el envío falla. Verificar con openssl s_client -connect mx.peer-domain.com:25 -starttls smtp.

"protocol version too old": el receptor solo ofrece TLS 1.0/1.1 que el sender ya rechaza. Deberá actualizar el receptor o, si es interno, configurar excepciones temporales mientras se migra.

"no shared cipher": las cipher suites del sender no se solapan con las del receptor. Típicamente porque el receptor usa cipher suites legacy. Revisar configuración de cipher suites para incluir al menos las modernas estándar (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, etc. en TLS 1.3; ECDHE-RSA-AES256-GCM-SHA384 en TLS 1.2).

Certificados Let's Encrypt expirando: muy frecuente. Let's Encrypt emite certificados de 90 días. La renovación automática (vía certbot, acme.sh, lego) debe estar configurada y monitoreada. Un certificado expirado en MX rompe MTA-STS enforce y bloquea envío de senders compatibles.

Por qué TLS robusto importa más cada año

Tres tendencias hacen el cifrado SMTP más crítico en 2026 que en años anteriores. Primero, regulatorio: RGPD considera datos personales en email (incluyendo metadatos como destinatarios) sujetos a medidas técnicas adecuadas, y el cifrado en tránsito es interpretación estándar de "adecuado". Sin TLS, un incident regulatorio se documenta peor.

Segundo, expectativas de receptores: Gmail muestra advertencias visuales (candado abierto rojo) en emails recibidos sin TLS. Los usuarios finales perciben menor confianza en marcas cuyos emails llegan así. La marca paga el coste reputacional.

Tercero, herramientas de attack más accesibles: BGP hijacking, DNS spoofing y MITM en redes WiFi públicas son ataques cada vez más automatizables. Sin MTA-STS, una operación que envía datos sensibles vía email es vulnerable a downgrade attacks que hace una década requerían capacidades estatales y hoy son accesibles a actores menores.

El esfuerzo de pasar de "STARTTLS opportunistic está activo" a "TLS robusto con MTA-STS enforce + TLS 1.2/1.3 only" se mide en horas de ingeniería, no semanas. El beneficio operativo y reputacional compensa rápidamente.