MTA-STS y TLS-RPT: cifrado del correo en tránsito

Si envías correos masivos o transaccionales, ya sabes que SPF, DKIM y DMARC son imprescindibles. Pero hay dos capas de seguridad que muchas empresas aún ignoran: MTA-STS y TLS-RPT. Mientras que los primeros autentican al remitente, estos últimos protegen el tránsito del correo y te avisan si algo falla. En un mercado cada vez más exigente —especialmente desde que Gmail y Yahoo endurecieron sus requisitos en 2024—, implementarlos es un paso adelante que diferencia a los serios de los aficionados.

¿Qué es MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) es un estándar publicado en RFC 8461 que le dice al servidor receptor de correo: «Para este dominio, solo acepto conexiones cifradas con TLS». Sin MTA-STS, un servidor puede caer en «downgrade»: si TLS falla, sigue intentando sin cifrar, lo que expone el mensaje en tránsito.

La idea es simple pero poderosa. Un atacante en la red (man-in-the-middle) puede interceptar el handshake TLS y decir al servidor remitente: «No, no hay TLS disponible, envía en plano». Sin MTA-STS, el servidor remitente lo haría. Con MTA-STS activado, rechaza la entrega si no hay cifrado.

Funciona en dos partes: una política publicada en DNS (registro TXT) y un archivo de política hosteado en tu dominio (en .well-known/mta-sts.txt). Los servidores receptores la descargan en caché y la consultan antes de conectar.

TLS-RPT: monitoreo y reportes de cifrado

TLS-RPT (TLS Reporting) es el complemento de MTA-STS. Es un estándar (RFC 8460) que le pide a otros servidores que te notifiquen si un correo tuyo no pudo entregarse por fallos de TLS.

Imagina que tienes MTA-STS activado. Un servidor intenta conectar a tu servidor de correo saliente mediante TLS, pero hay un error de certificado (certificado expirado, no coincide el nombre, etc.). Con TLS-RPT, ese servidor te envía un reporte automático diciendo: «No pude conectar a mail.tudominio.es porque el certificado venció». Sin TLS-RPT, nunca te enteras de que los mensajes se están perdiendo silenciosamente.

Se configura mediante un registro _smtp._tls.tudominio.com en DNS, apuntando a una dirección de email donde quieres recibir reportes o un endpoint HTTPS si usas una herramienta de agregación.

MTA-STS vs STARTTLS: diferencias clave

Aquí hay confusión común. STARTTLS es un comando SMTP que intenta cifrar la conexión, pero es opcional: si falla, sigue sin cifrar. Es como pisar el acelerador pero el freno siempre funciona.

MTA-STS es más estricto: requiere TLS. Si no hay cifrado, la conexión se rechaza. Es como quitar el freno y obligar a frenar solo con airbags.

En la práctica, STARTTLS sigue siendo el estándar de facto de SMTP. Pero MTA-STS lo complementa: dice «STARTTLS es bueno, pero en mi dominio es obligatorio». Google, Microsoft (Outlook) y otros grandes proveedores ahora publican políticas MTA-STS, y algunos ESP (como Brevo o Mailjet) comienzan a verificarla antes de enviar.

Cómo implementar MTA-STS en tu dominio

MTA-STS tiene cuatro pasos. Toma 30 minutos si todo sale bien.

Crear el archivo de política. Debes hostear un archivo en https://mta-sts.tudominio.com/.well-known/mta-sts.txt con contenido como:

version: STSv1
mode: enforce
max_age: 604800
mx: mail.tudominio.com
mx: mail2.tudominio.com

mode: enforce significa rechazo de conexiones sin TLS (recomendado tras varias semanas de mode: testing). max_age es en segundos (7 días = 604800).

Publicar el registro DNS. Añade un TXT en _mta-sts.tudominio.com:

v=STSv1; id=2026071301

El ID debe cambiar cada vez que actualizas la política (para que los caches se invaliden). Muchos usan timestamp (YYYYMMDDHH).

Verificar que el MX está listo. Tu registro MX debe apuntar a un servidor con certificado TLS válido. Valida con openssl s_client -connect mail.tudominio.com:25 -starttls smtp. El certificado no debe estar expirado y su CN o SAN debe coincidir con el hostname.
Configurar TLS-RPT (opcional pero recomendado). Añade un registro TXT en _smtp._tls.tudominio.com:

v=TLSRPTv1; rua=mailto:tls-reports@tudominio.com

Los reportes llegarán diarios o semanales (según el servidor) a esa dirección.

Registro DNS TXT para MTA-STS: estructura básica

Verificar tu configuración MTA-STS

Una vez publicada, puedes probar con herramientas online:

mta-sts.io o mailhardener.com — analizan tu DNS y el archivo de política.
Comandos locales: dig _mta-sts.tudominio.com TXT (debe aparecer v=STSv1...), luego curl -I https://mta-sts.tudominio.com/.well-known/mta-sts.txt (debe devolver 200 OK).
Nuestro test gratuito de correo — aunque se enfoca principalmente en SPF/DKIM/DMARC, también valida registros de seguridad relacionados.

Comienza en mode: testing durante 1 o 2 semanas; así, si algo falla, los correos siguen llegando pero recibes reportes de TLS-RPT. Luego cambia a mode: enforce.

Adopción de MTA-STS: qué dicen los datos

Según el dataset de /email-stats/ (escaneo semanal de Tranco top-1M), la adopción de MTA-STS es aún menor que DMARC, pero crece. Dominios de gran reputación (Gmail, Microsoft, Cloudflare, Zoho, Brevo) ya lo implementan. En mercados hispanohablantes, la penetración en PYMES es baja, pero organizaciones grandes y agencias de email (que envían en masa) lo adoptan cada vez más.

Lo interesante es que MTA-STS no es «agradable»: si tu certificado TLS falla, los correos se rechazan. Por eso muchos dominios pequeños o domésticos aún dudan. Pero en el contexto de acuerdos con grandes receptores (bancos, empresas Fortune 500, proveedores críticos), MTA-STS se vuelve un check-list obligatorio.

TLS-RPT es tu aliado diagnóstico

No esperes a activar mode: enforce si no tienes TLS-RPT configurado. Primero, publica mode: testing + TLS-RPT, recibe reportes durante 1 o 2 semanas, identifica y soluciona problemas (certificados expirados, firewalls que bloquean TLS, etc.), y solo entonces cambia a enforce. Así evitas rechazos inesperados.

Otros estándares relacionados: BIMI y MTA-STS

Así como MTA-STS complementa a DMARC en seguridad de tránsito, BIMI (Brand Indicators for Message Identification) lo complementa en confianza visual. Requiere DMARC en p=quarantine o p=reject y un certificado VMC (Verified Mark Certificate). Juntos, MTA-STS + DMARC estricto + BIMI es la tríada de máxima reputación.

¿Necesito MTA-STS si ya tengo SPF y DKIM?

No son redundantes, sino capas diferentes. SPF/DKIM autentican quién eres. MTA-STS garantiza que el correo viaja cifrado. Un atacante podría interceptar el tránsito si no hay cifrado obligatorio, incluso si tu SPF/DKIM son robustos. La defensa completa es: SPF/DKIM + DMARC (autenticación) + MTA-STS (cifrado) + TLS-RPT (monitoreo).

¿Qué pasa si no puedo hostear un certificado TLS válido para mta-sts.tudominio.com?

Necesitas que exista un subdominio mta-sts con certificado válido (puede ser el mismo certificado wildcard que uses para otros subdominios). Si tu infraestructura no permite esto, MTA-STS no es viable por ahora. Algunos registros de hosting compartido no lo permiten sin costo extra. Consulta a tu proveedor.

¿Es obligatorio MTA-STS para enviar correos?

No (aún). Pero proveedores como Google, Microsoft y otros grandes están implantando verificaciones MTA-STS en sus sistemas internos, y algunos ESP comienzan a requerirla en contratos premium. Para empresas que envían en masa o transaccional, implementarla es un diferencial competitivo que mejora tu reputación de dominio.

Lecturas relacionadas