Inicio / Guías / Cómo configurar MTA-STS y TLS-RPT para forzar cifrado en transporte

Configurar MTA-STS y TLS-RPT: cifrado obligatorio entre servidores de correo

4,4 · 80 valoraciones
· Actualizado el 8 de mayo de 2026

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.

Cómo configurar MTA-STS y TLS-RPT para forzar cifrado en transporte
Forma parte de DMARC

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, testing o enforce.
  • 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.

Preguntas frecuentes

¿Qué problema resuelve MTA-STS?
MTA-STS impide ataques de downgrade en SMTP forzando que los servidores remitentes solo entreguen al dominio si encuentran TLS válido y certificado de confianza, según la política publicada.
¿En qué se diferencia MTA-STS de DANE?
DANE depende de DNSSEC y publica el hash del certificado en TLSA. MTA-STS no requiere DNSSEC y publica la política vía HTTPS. MTA-STS es más sencillo de adoptar para la mayoría de dominios.
¿Qué modo MTA-STS debo usar al empezar?
Empieza con mode testing durante varias semanas para recibir reportes de fallos sin bloquear entregas. Cuando los reportes confirmen que todo va bien, cambia a mode enforce.
¿Es obligatorio publicar TLS-RPT?
No es obligatorio, pero sin TLS-RPT no recibes los reportes de fallos de cifrado y pierdes la visibilidad necesaria para diagnosticar errores de TLS, certificados o MTA-STS.
¿Cuánto tarda en propagarse MTA-STS?
El TXT _mta-sts y la política HTTPS se ven al instante. Los remitentes la cachean según el max_age declarado, típicamente 1 a 7 días, antes de revalidar.
¿Puedo usar `mta-sts.tudominio.com` sin servidor propio?
Sí. Cualquier hosting estático con HTTPS sirve. Workers de Cloudflare, S3 + CloudFront, Netlify, GitHub Pages: todos valen.
¿Necesito DNSSEC para MTA-STS?
No. MTA-STS se diseñó precisamente para no depender de DNSSEC.