De testing a enforce: estrategia de despliegue progresivo de MTA-STS
Por CaptainDNS
Publicado el 10 de marzo de 2026
- MTA-STS en modo testing recopila los informes TLS-RPT sin bloquear la entrega de correos, ideal para detectar problemas de configuración
- El modo enforce rechaza toda conexión SMTP no cifrada hacia sus servidores MX, bloqueando los ataques de downgrade
- La transición de testing a enforce se realiza en cuatro pasos: despliegue inicial, configuración TLS-RPT, análisis de informes (1 a 2 semanas) y activación del modo enforce
- Aloje su política MTA-STS de forma gratuita con CaptainDNS: dos registros DNS son suficientes
Publicar una política MTA-STS en modo enforce sin fase de prueba equivale a activar un cortafuegos sin conocer el tráfico legítimo. Resultado posible: correos bloqueados, socios que ya no pueden escribirle y ninguna visibilidad sobre la causa. Según el Google Transparency Report, más del 90 % del tráfico entrante de Gmail ya utiliza TLS, pero sin MTA-STS nada garantiza que ese cifrado sea obligatorio en lugar de oportunista.
El RFC 8461 prevé exactamente este escenario. Define dos modos de funcionamiento: testing (observar sin bloquear) y enforce (bloquear las conexiones no cifradas). La estrategia correcta consiste en desplegar primero en testing, supervisar los informes TLS-RPT durante una a dos semanas, corregir las anomalías y luego pasar a enforce.
Esta guía detalla cada etapa de esta transición. Está dirigida a administradores de sistemas, DevOps y responsables de seguridad del correo electrónico que gestionan uno o varios dominios de mensajería.
Comprender los modos MTA-STS: testing vs enforce
MTA-STS (RFC 8461) impone el cifrado TLS para el correo entrante mediante una política HTTPS que contiene tres parámetros: los servidores MX autorizados, la duración de caché (max_age) y el modo (testing o enforce).
Modo testing: supervisar sin bloquear
El modo testing de MTA-STS permite que los servidores de envío (Gmail, Outlook, Yahoo) verifiquen su política sin bloquear la entrega en caso de fallo TLS. Las anomalías se reportan mediante un informe TLS-RPT (RFC 8460) enviado a la dirección que usted ha configurado.
version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400
Este modo permite detectar tres tipos de problemas antes de que afecten la entrega:
- Certificado TLS inválido: certificado expirado, nombre de dominio incorrecto o cadena de confianza incompleta
- MX no listado: un servidor MX responde a los correos pero no aparece en la política
- Fallo de negociación TLS: el servidor MX no soporta STARTTLS o rechaza la conexión cifrada
Modo enforce: imponer el cifrado TLS
El modo enforce de MTA-STS obliga a los servidores de envío a rechazar la entrega si la conexión TLS falla o si el servidor MX no figura en la política.
version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800
Este modo ofrece una protección real contra los ataques de downgrade SMTP. Un atacante que intente eliminar STARTTLS o redirigir hacia un servidor MX falso no podrá interceptar los correos: el servidor de envío rechazará la entrega.
Paso 1: desplegar MTA-STS en modo testing
El despliegue inicial requiere dos elementos DNS y un archivo de política HTTPS.
Registro DNS TXT
Publique un registro TXT en _mta-sts.captaindns.com:
_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260310T000000"
El campo id es un identificador de versión. Increméntelo con cada modificación de la política para que los servidores de envío descarguen la nueva versión.
Archivo de política HTTPS
El archivo debe ser accesible en https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Con CaptainDNS, dos registros CNAME son suficientes: sin servidor web que gestionar, sin certificado que renovar.
Comience con un max_age corto (86 400 segundos = 1 día) para poder corregir rápidamente en caso de problema:
version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400
Verificación
Utilice el verificador MTA-STS para confirmar que su registro DNS y su política están correctamente publicados.
Paso 2: configurar TLS-RPT para recibir los informes
Sin TLS-RPT, el modo testing no sirve de nada. Los servidores de envío detectan los problemas pero no tienen dónde reportarlos.
Registro DNS TLS-RPT
Publique un registro TXT en _smtp._tls.captaindns.com:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Los informes TLS-RPT (RFC 8460) se envían diariamente en formato JSON. Cada informe contiene:
- El dominio remitente y el dominio destinatario
- El tipo de política aplicada (MTA-STS o DANE)
- El número de sesiones exitosas y fallidas
- El detalle de los fallos: tipo de error, certificado presentado, código de resultado
Configurar con CaptainDNS
El generador TLS-RPT crea el registro DNS adaptado a su dominio. Puede dirigir los informes a una dirección de correo electrónico o a un endpoint HTTPS.
Paso 3: analizar los informes y corregir los problemas
Espere 1 a 2 semanas en modo testing antes de pasar a enforce. Este plazo permite recopilar suficientes informes TLS-RPT para identificar los problemas recurrentes.
Interpretar los informes
| Tipo de fallo | Causa probable | Corrección |
|---|---|---|
certificate-expired | Certificado TLS del servidor MX expirado | Renovar el certificado |
certificate-host-mismatch | El CN/SAN del certificado no corresponde al nombre MX | Corregir el certificado o la política |
starttls-not-supported | El servidor MX no soporta STARTTLS | Activar STARTTLS en el servidor |
sts-policy-fetch-error | La política HTTPS es inaccesible | Verificar el DNS CNAME y el servidor HTTPS |
sts-webpki-invalid | El certificado HTTPS de la política es inválido | Renovar el certificado del servidor web |
validation-failure | El MX no figura en la política | Agregar el MX faltante a la política |
Criterios para pasar a enforce
Antes de activar el modo enforce, verifique estas tres condiciones:
- Cero fallos TLS recurrentes en los informes de los últimos 7 días
- Todos sus servidores MX figuran en la política
- Certificados TLS válidos en cada servidor MX (no expirados, CN/SAN correcto)
Si los fallos persisten, corríjalos primero. Un paso prematuro a enforce bloqueará los correos provenientes de servidores que encuentren estos errores.
Paso 4: pasar a modo enforce
La transición se realiza mediante dos modificaciones: el archivo de política y el registro DNS.
Modificar la política
Cambie mode: testing por mode: enforce y aumente max_age a 604 800 segundos (7 días):
version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800
Un max_age de 7 días ofrece un buen equilibrio: suficientemente largo para que los servidores de envío almacenen la política en caché (protección contra TOFU), suficientemente corto para permitir un retorno a testing si es necesario.
Actualizar el identificador DNS
Incremente el id en el registro TXT para forzar la actualización:
_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260310T120000"
Estrategia de retroceso
Si surgen problemas después del paso a enforce:
- Vuelva inmediatamente a
mode: testing - Incremente el
idDNS - Espere la expiración del
max_ageanterior (7 días como máximo) - Analice los nuevos informes TLS-RPT
- Corrija los problemas antes de reintentar el paso a enforce
Errores comunes y soluciones
| Error | Consecuencia | Solución |
|---|---|---|
| Pasar a enforce sin TLS-RPT | Ninguna visibilidad sobre los bloqueos | Siempre configurar TLS-RPT antes de enforce |
max_age demasiado largo en testing | Corrección lenta en caso de problema | Usar 86 400 s (1 día) en testing |
max_age demasiado corto en enforce | Protección TOFU reducida | Usar 604 800 s (7 días) en enforce |
| Olvidar un servidor MX en la política | Correos rechazados en enforce | Listar todos los MX con dig MX captaindns.com |
No incrementar el id | Servidores de envío usan la política antigua | Siempre cambiar el id tras cada modificación |
| Certificado TLS expirado | Fallo de validación en enforce | Automatizar la renovación (Let's Encrypt) |
Plan de acción recomendado
- Verifique su configuración actual: lance un análisis con el verificador MTA-STS
- Despliegue en modo testing: publique su política con
mode: testingymax_age: 86400 - Active TLS-RPT: configure el registro
_smtp._tlspara recibir los informes diarios - Supervise de 1 a 2 semanas: analice cada informe, corrija los fallos TLS
- Pase a enforce: cambie
mode: enforce, aumentemax_agea 604 800 s, incremente elid
Asegure el transporte de sus correos ahora: aloje su política MTA-STS de forma gratuita con CaptainDNS. Dos registros DNS, cero servidores web, protección activa en 5 minutos.
FAQ
¿Cuál es la diferencia entre el modo testing y el modo enforce de MTA-STS?
En modo testing, los servidores de envío verifican su política MTA-STS pero entregan los correos aunque la conexión TLS falle. Envían un informe TLS-RPT para reportar el problema. En modo enforce, los servidores rechazan la entrega si TLS falla o si el servidor MX no figura en la política.
¿Cuánto tiempo hay que permanecer en modo testing antes de pasar a enforce?
Mínimo de 1 a 2 semanas. Este plazo permite recopilar suficientes informes TLS-RPT provenientes de los principales remitentes (Gmail, Outlook, Yahoo). Si los informes muestran cero fallos TLS durante 7 días consecutivos, puede pasar a enforce.
¿Qué sucede si se pasa directamente a enforce sin fase de testing?
Los correos provenientes de servidores que encuentren un problema TLS con sus MX serán rechazados. Sin informes TLS-RPT previos, no tendrá ninguna visibilidad sobre estos rechazos. Socios o clientes podrían dejar de poder enviarle correos sin que usted lo sepa.
¿Qué max_age utilizar en modo testing y en modo enforce?
En testing, utilice 86 400 segundos (1 día). Este plazo corto permite corregir rápidamente la política si se detecta un problema. En enforce, pase a 604 800 segundos (7 días) para reducir la vulnerabilidad TOFU: los servidores de envío almacenan la política en caché durante más tiempo.
¿Cómo volver al modo testing después de haber activado enforce?
Modifique el archivo de política para volver a mode: testing y luego incremente el id en el registro DNS TXT. Los servidores de envío que hayan almacenado en caché la política enforce seguirán aplicándola hasta la expiración del max_age anterior (7 días como máximo).
¿Es obligatorio TLS-RPT para MTA-STS?
No, TLS-RPT no es técnicamente requerido para que MTA-STS funcione. Pero sin TLS-RPT, no tiene ninguna visibilidad sobre los fallos TLS. En la práctica, desplegar MTA-STS sin TLS-RPT equivale a pilotar a ciegas. Ambos protocolos están diseñados para funcionar juntos.
¿Gmail y Outlook respetan el modo testing de MTA-STS?
Sí. Gmail, Outlook y Yahoo verifican las políticas MTA-STS en modo testing y envían informes TLS-RPT a la dirección configurada. En modo testing, entregan los correos normalmente incluso en caso de fallo TLS, pero reportan el problema en el informe diario.
Descarga la checklist de despliegue
Los asistentes pueden reutilizar la checklist con los exports JSON o CSV de abajo.
Glosario
- MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política publicada vía HTTPS que impone el cifrado TLS para la recepción de correos en un dominio.
- TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de informes diarios que reporta los fallos de negociación TLS entre servidores de correo.
- TOFU: Trust On First Use. Modelo de seguridad donde la primera conexión no se verifica, pero las siguientes se validan gracias a los datos almacenados en caché.
- max_age: duración (en segundos) durante la cual un servidor de envío conserva en caché la política MTA-STS. Determina la frecuencia de actualización.
- STARTTLS: extensión SMTP (RFC 3207) que permite negociar una conexión TLS después de establecer una conexión en texto plano en el puerto 25.
- Downgrade SMTP: ataque de red que elimina la negociación STARTTLS para interceptar los correos en texto plano.
Guías de seguridad del transporte de correo relacionadas
- Ataques de downgrade SMTP: cómo funcionan y cómo protegerse: mecanismo del STARTTLS stripping y soluciones de protección
- MTA-STS vs DANE: ¿qué protocolo elegir para asegurar el transporte de correo?: comparación técnica y guía de elección
