Configurar MTA-STS y TLS-RPT: cifrado obligatorio entre servidores de correo
Guía para publicar MTA-STS y TLS-RPT, forzar TLS entre servidores SMTP, evitar downgrade attacks y recibir reportes de fallos de cifrado por email.
SMTP nació sin cifrado obligatorio. Hoy la mayoría de servidores ofrecen STARTTLS, pero un atacante con acceso al camino de red puede provocar un downgrade y forzar texto plano. MTA-STS (RFC 8461) y TLS-RPT (RFC 8460) cierran ese hueco: declaran públicamente que tu dominio exige TLS para recibir email y abren un canal de reporte cuando algún emisor falla. Configurarlos requiere un poco más que un TXT, pero es perfectamente abordable y eleva el nivel de seguridad sin afectar a la entrega legítima.
Qué es MTA-STS
MTA-STS (SMTP MTA Strict Transport Security) es un mecanismo equivalente conceptualmente a HSTS para HTTP. Permite a un dominio publicar una política que dice:
- “Mi MX usa estos hostnames concretos.”
- “Mi MX exige TLS válido.”
- “Si alguien intenta entregar email sin TLS o con un certificado inválido, abórtelo en lugar de degradar.”
La política se sirve por HTTPS desde un subdominio especial, lo que aprovecha la PKI ya existente para firmar la declaración. Un TXT en DNS apunta al servicio.
Qué es TLS-RPT
TLS-RPT (SMTP TLS Reporting) es el canal de retroalimentación. Otros emisores envían reportes JSON al endpoint que indiques cada vez que detectan problemas de TLS al entregar email a tu dominio. Sin TLS-RPT, MTA-STS funciona en silencio: si algo falla, no te enteras hasta que un usuario reclama. Con TLS-RPT, recibes los detalles diarios y puedes corregir.
Ambos estándares son complementarios y se publican en paralelo.
Prerrequisitos
Antes de tocar MTA-STS necesitas dos condiciones operativas:
- Tus registros MX, A y rDNS deben estar limpios y estables.
- Todos los servidores listados como MX deben aceptar STARTTLS con un certificado público válido (no autofirmado, no expirado, con SAN que incluya el hostname MX).
Si aún no tienes esto, MTA-STS bloqueará entregas legítimas. La solución es subir primero el nivel de TLS de tus MX y, solo entonces, declarar la política.
Estructura del registro DNS de MTA-STS
El TXT vive en _mta-sts.tudominio.com:
_mta-sts.tudominio.com. IN TXT "v=STSv1; id=20260509T120000"
v=STSv1(obligatorio).id=un identificador arbitrario que cambia cada vez que actualizas la política. Suele ser un timestamp.
Cada vez que cambies la política servida por HTTPS, debes cambiar el id para que los emisores invaliden la caché y vuelvan a buscar.
Estructura del archivo de política
La política se aloja en https://mta-sts.tudominio.com/.well-known/mta-sts.txt. Es un archivo de texto plano:
version: STSv1
mode: testing
mx: mail.tudominio.com
mx: *.mail.tudominio.com
max_age: 86400
Campos:
version: STSv1.mode:none,testingoenforce.mx: una o varias líneas con los hostnames autorizados (acepta wildcards en el primer label).max_age: tiempo de cacheo en segundos. Lo razonable son 86400 (1 día) durante la fase inicial; más alto cuando esté estable (hasta varias semanas).
Modos disponibles
none: declara que no hay política. Equivale a no tener MTA-STS, pero se publica formalmente. Útil para retirar la política sin romper.testing: la política se evalúa y los fallos generan reportes (si TLS-RPT está activo), pero no se bloquea la entrega.enforce: los fallos abortan la entrega con error de TLS.
Configuración paso a paso
1. Audita tus MX
dig +short MX tudominio.com
Para cada hostname devuelto, verifica STARTTLS y certificado:
openssl s_client -starttls smtp -connect mail.tudominio.com:25 -servername mail.tudominio.com
Confirma:
- TLS 1.2 o superior negociado.
- Certificado válido y no caducado.
- El SAN incluye el hostname.
- Cadena de confianza completa.
Si algo falla, corrige antes de avanzar.
2. Crea el subdominio mta-sts
Necesitas que mta-sts.tudominio.com resuelva por HTTPS válido. Las opciones habituales:
- Un host específico con un servidor web (puede ser estático).
- Un alias CNAME a un servicio gestionado (Cloudflare Workers, S3 con CloudFront, GitHub Pages…).
Lo único imprescindible: HTTPS con certificado correcto y servir el archivo en /.well-known/mta-sts.txt con Content-Type: text/plain.
3. Publica la política inicial en mode: testing
Sirve el archivo de política en modo testing. Esto te permite validar antes de aplicar enforcement real:
version: STSv1
mode: testing
mx: mail.tudominio.com
max_age: 86400
4. Publica el TXT _mta-sts
_mta-sts TXT "v=STSv1; id=20260509T120000"
5. Activa TLS-RPT en paralelo
En _smtp._tls.tudominio.com:
_smtp._tls.tudominio.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Puedes apuntar el rua a un buzón propio o a un endpoint HTTPS:
v=TLSRPTv1; rua=https://reports.tudominio.com/tls
6. Espera y revisa reportes
Tras 24-72 horas, los reportes empiezan a llegar (si hay actividad y los grandes proveedores entregan a tu dominio). Cada reporte agrega métricas de éxitos y fallos por sesión TLS.
7. Pasa a enforce
Cuando los reportes muestren cero fallos persistentes durante varios días, cambia el archivo a mode: enforce y actualiza el id= en el TXT:
version: STSv1
mode: enforce
mx: mail.tudominio.com
max_age: 604800
A partir de ese momento, los emisores que respeten MTA-STS rechazarán activamente entregas sin TLS válido.
Cómo se ve un reporte TLS-RPT
Los reportes son JSON con esta estructura general:
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2026-05-08T00:00:00Z",
"end-datetime": "2026-05-08T23:59:59Z"
},
"policies": [{
"policy": {
"policy-type": "sts",
"policy-domain": "tudominio.com",
"mx-host": ["mail.tudominio.com"]
},
"summary": {
"total-successful-session-count": 1240,
"total-failure-session-count": 0
}
}]
}
Si aparece total-failure-session-count mayor que cero, expande los detalles: indicará si fue certificate-not-trusted, validation-failure, sts-policy-fetch-error u otro motivo.
Cómo afecta a la deliverability
MTA-STS no mejora directamente tu inbox placement, pero:
- Reduce el riesgo de interceptación de datos sensibles.
- Es un requisito creciente en sectores regulados (sanidad, banca, sector público).
- Aporta una señal de “dominio bien gestionado” que algunos sistemas internos puntúan.
Por tanto, no esperes ver una subida en Gmail por publicar MTA-STS, pero sí cubres una capa que las herramientas de auditoría de seguridad y deliverability comprueban.
Diferencia con DANE
DANE es otro estándar para forzar TLS basado en DNSSEC: publica el hash del certificado en TLSA records firmados. Es más estricto y, técnicamente, más limpio que MTA-STS, pero exige DNSSEC en toda la cadena, lo que en la práctica limita su adopción. La mayoría de organizaciones implementan MTA-STS antes que DANE, y solo añaden DANE cuando ya tienen DNSSEC operativo.
No son excluyentes: puedes tener ambos. Si publicas DANE, los receptores que lo soporten lo prefieren; los que no, caen en MTA-STS.
Errores frecuentes
Modo enforce sin testing previo
Aplicar enforce sin haber visto reportes en testing es una receta segura para perder mensajes legítimos. La fase intermedia existe por algo.
No actualizar el id al cambiar la política
Si cambias mta-sts.txt pero no id=, los emisores siguen sirviendo la versión cacheada hasta que expire. Cambia siempre el id.
Listar MX que no están en el archivo de política
Si tu DNS expone tres MX y la política solo declara dos, los emisores rechazarán entregas al tercero en enforce. Sincroniza ambos lados.
mta-sts.tudominio.com sin HTTPS válido
El archivo se sirve solo por HTTPS. Un certificado autofirmado o expirado invalida toda la política.
Buzón de TLS-RPT que no se procesa
Igual que con DMARC, recibirlos sin parsear no aporta nada. Hay parsers open source y SaaS que normalizan los JSON.
Recursos relacionados
Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.
¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing especializada en ecommerce de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.