¿Qué valida el verificador MTA-STS?

El verificador realiza una validación completa: registro DNS TXT en _mta-sts.domain.com, archivo de política HTTPS en mta-sts.domain.com/.well-known/mta-sts.txt, validez del certificado TLS y validación cruzada de registros MX con patrones de política.

¿Por qué no se obtiene mi política MTA-STS?

Causas comunes: el subdominio mta-sts no existe, HTTPS no está configurado, el certificado es inválido, la ruta del archivo de política es incorrecta, o el servidor devuelve redirecciones (no permitidas). El verificador reportará el error específico.

¿Qué significa 'MX no cubierto por política'?

Esta advertencia significa que uno o más registros MX de su dominio no coinciden con ningún patrón en su política MTA-STS. Esta es una brecha de seguridad : agregue los patrones MX faltantes a su archivo de política.

¿Por qué el verificador muestra errores TLS?

MTA-STS requiere que el archivo de política se sirva sobre HTTPS con un certificado válido. Los errores TLS pueden significar: certificado expirado, certificado autofirmado, no coincidencia de nombre de host o versión TLS obsoleta.

¿Cuál es la diferencia entre los modos testing y enforce?

En modo 'testing', los servidores emisores reportan fallos TLS pero aún entregan correo. En modo 'enforce', la entrega se rechaza si TLS falla. Use testing primero para identificar problemas.

¿Con qué frecuencia debo verificar mi configuración MTA-STS?

Verifique después de cualquier cambio en DNS, registros MX o configuración del servidor de correo. También verifique después de renovaciones de certificado para el subdominio mta-sts. Verificaciones mensuales regulares ayudan a detectar problemas.

¿Cómo verifico MTA-STS para Microsoft 365 / Office 365?

Ingrese su dominio en nuestro MTA-STS Checker. Los dominios Microsoft 365 con dominios personalizados necesitan configuración MTA-STS separada : Microsoft no lo configura automáticamente. Debe crear el registro DNS TXT y alojar el archivo de política usted mismo o usar un servicio de terceros.

¿Cómo verifico MTA-STS para Google Workspace?

Use nuestra herramienta de lookup MTA-STS con su dominio de Google Workspace. Google Workspace soporta MTA-STS pero debe configurarlo usted mismo para dominios personalizados. El verificador valida su registro DNS _mta-sts, obtiene la política y verifica que los patrones MX coincidan con los servidores de correo de Google (ej: *.google.com o aspmx.l.google.com).

MTA-STS Checker Gratis - Lookup y Validación Online

Por qué verificar su MTA-STS

El transporte SMTP usa TLS de forma oportunista: si el cifrado falla, la conexión cae a texto plano sin alerta. Un atacante en posición de man-in-the-middle puede entonces eliminar el banner STARTTLS y forzar el envío de sus correos en texto legible.

MTA-STS (RFC 8461) cierra esta brecha. Publica una política servida por HTTPS respaldada por PKI pública que ordena a los MTAs emisores rechazar cualquier conexión sin TLS válido. Es la capa que faltaba para bloquear los ataques de downgrade y el spoofing TLS.

Verificar su configuración antes de pasar a enforce es crítico:

Política rota → los correos legítimos pueden ser bloqueados
Patrones MX incompletos → algunos servidores quedan vulnerables
Certificado expirado → la política se vuelve inválida, los MTAs emisores vuelven a TLS oportunista

Casos de uso comunes:

Después de la publicación → confirmar que DNS, política HTTPS y TLS son coherentes
Antes de mode: enforce → asegurarse de que ningún MX legítimo queda excluido
Auditoría de seguridad → validar la protección contra downgrade TLS

Cómo usar este verificador en 3 pasos

Paso 1: introducir el dominio a analizar

Ingrese el dominio exactamente como aparece en sus direcciones de correo:

captaindns.com (dominio principal)
marketing.captaindns.com (subdominio si envía desde un subdominio)

La herramienta consulta automáticamente _mta-sts.dominio, obtiene https://mta-sts.dominio/.well-known/mta-sts.txt y compara los patrones con los registros MX.

Paso 2: analizar los resultados

El verificador muestra:

Elemento	Descripción
Registro TXT	Versión `STSv1` e ID único de la política
Política HTTPS	Contenido del archivo `.well-known/mta-sts.txt`
Modo	`none`, `testing` o `enforce`
Patrones MX	Lista de hosts autorizados por la política
max_age	Duración de caché de la política en segundos
Certificado TLS	Validez, expiración, versión TLS del subdominio `mta-sts`
Cobertura MX	Todos los MX resueltos coinciden con un patrón

Paso 3: corregir los problemas señalados

Los resultados se clasifican por gravedad:

Crítico → la política es inutilizable, los MTAs emisores la ignoran
Advertencia → funciona, pero le expone a un riesgo o protección parcial
Info → buena práctica no bloqueante

Corrija el DNS o el archivo de política, espere la propagación y vuelva a ejecutar el verificador.

¿Qué es MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) es un mecanismo que:

Publica una política HTTPS que indica qué hosts MX soportan TLS
Fuerza el cifrado TLS entre MTAs emisores y receptores
Bloquea ataques de downgrade que eliminan STARTTLS

La arquitectura combina tres elementos:

Elemento	Rol
Registro DNS TXT	Publicado en `_mta-sts.dominio`. Señala la existencia de una política y su ID.
Política HTTPS	Servida en `https://mta-sts.dominio/.well-known/mta-sts.txt`. Contiene modo, MX, max_age.
Certificado TLS	El subdominio `mta-sts` debe presentar un certificado válido firmado por una CA reconocida.

Ejemplo de registro DNS:

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Ejemplo de política:

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.mail.captaindns.com
max_age: 604800

Diferencia con DANE: MTA-STS se basa en la PKI pública (autoridades de certificación), DANE se basa en DNSSEC y los registros TLSA. Ambos mecanismos son compatibles y pueden desplegarse juntos.

Qué verifica el checker

Siete dimensiones se analizan en paralelo para producir un score 0-100:

Registro DNS publicado

Verificación	Error si...
TXT presente en `_mta-sts.dominio`	Ningún registro
Comienza con `v=STSv1`	Prefijo ausente o malformado
Campo `id=` presente	ID faltante o caracteres inválidos
Registro único	Múltiples TXT MTA-STS detectados

Obtención del archivo de política

Verificación	Error si...
URL accesible por HTTPS	Conexión rechazada o timeout
Sin redirecciones	El servidor responde 3xx en lugar de 200
Content-Type `text/plain`	Tipo MIME incorrecto
HTTP en claro no aceptado	Política servida en puerto 80

Sintaxis de la política

Verificación	Error si...
`version: STSv1` presente	Línea ausente o versión desconocida
`mode:` válido	Valor distinto a `none`, `testing`, `enforce`
Al menos una línea `mx:`	Ningún patrón MX definido
`max_age:` en rango	Fuera de los límites RFC (1 a 31557600 segundos)

Cobertura de los servidores MX

Todos los MX resueltos para el dominio deben coincidir con al menos un patrón:

Coincidencia directa: mx: mail.captaindns.com cubre mail.captaindns.com
Wildcard limitado a una etiqueta: *.mail.captaindns.com cubre eu.mail.captaindns.com pero no mail.captaindns.com

Validez del certificado TLS

El subdominio mta-sts.dominio se sondea por HTTPS:

Certificado no expirado
Nombre de host presente en el SAN
Cadena completa hasta una CA reconocida
Versión TLS reciente (1.2 mínimo)

Coherencia entre DNS y política

El ID DNS y el ID de la política servida deben coincidir. Una discrepancia indica una actualización parcial peligrosa para la caché de los MTAs emisores.

Presencia de TLS-RPT

El verificador señala la ausencia del registro _smtp._tls (TLS-RPT, RFC 8460). Sin TLS-RPT, nunca sabrá si la política provoca fallos de entrega silenciosos.

Diagnósticos comunes y soluciones

Política inaccesible (policy_fetch_failed)

Causa: el subdominio mta-sts.dominio no responde, no sirve HTTPS, o devuelve un error HTTP.

Soluciones:

Verificar que mta-sts.dominio se resuelve en DNS (A o CNAME)
Confirmar que se sirve un certificado TLS válido (Let's Encrypt, autocert, etc.)
Confirmar que /.well-known/mta-sts.txt devuelve 200 OK en text/plain

Certificado TLS inválido (cert_invalid)

Causa: certificado expirado, autofirmado, nombre de host no cubierto por el SAN, o cadena incompleta.

Soluciones:

Renovar el certificado antes de la expiración
Incluir mta-sts.dominio en el SAN
Servir la cadena intermedia completa

Registro DNS ausente (missing_record)

Causa: ningún TXT existe en _mta-sts.dominio.

Solución: publicar

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Política desactivada (mode_none)

Causa: mode: none indica que MTA-STS se anuncia pero sin efecto.

Solución: pasar a mode: testing después de la publicación inicial, luego a mode: enforce cuando TLS-RPT esté limpio.

Cobertura MX incompleta (mx_partial_match)

Causa: uno o varios MX resueltos no coinciden con ningún patrón de la política.

Solución: listar explícitamente cada host MX o usar un wildcard más amplio adaptado a su infraestructura.

Ausencia de TLS-RPT (tls_rpt_missing)

Causa: ningún registro _smtp._tls.dominio está publicado.

Solución: publicar

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

Progresión de testing a enforce

Fase 1: publicación inicial en modo testing

version: STSv1
mode: testing
mx: mail.captaindns.com
max_age: 86400

Los MTAs emisores reportan los fallos TLS vía TLS-RPT sin bloquear la entrega
Mantenga max_age corto (1 a 7 días) para iterar rápido
Recopile informes TLS-RPT durante 2 a 4 semanas

Fase 2: estabilización y observación

Durante este periodo, verifique:

Ningún MX legítimo excluido (TLS-RPT señalaría fallos mx-mismatch)
Ningún problema de certificado en los hosts MX (TLS-RPT señalaría certificate-not-trusted)
Ningún MTA emisor en dificultad (informes vacíos o nulos)

Fase 3: paso al modo enforce

version: STSv1
mode: enforce
mx: mail.captaindns.com
max_age: 604800

Alargar max_age (mínimo 7 días, hasta 1 año)
Supervisar TLS-RPT de forma continua: los fallos ahora son no-entregas
Preparar un plan de rollback (volver a testing rápidamente si es necesario)

Errores frecuentes:

max_age demasiado corto → los MTAs emisores recuperan la política con demasiada frecuencia, carga inútil
max_age demasiado largo → un cambio de MX tarda semanas en propagarse
Patrones MX incompletos → los correos legítimos se rechazan silenciosamente

MTA-STS vs DANE

Ambos mecanismos protegen el transporte SMTP contra ataques de downgrade, pero con enfoques diferentes.

Criterio	MTA-STS	DANE
RFC	8461	7672
Prerequisitos	PKI pública (CA)	DNSSEC firmado
Distribución	DNS TXT + HTTPS	DNS (registros TLSA)
Pinning	No	Sí (huella del certificado)
Adopción MTA emisor	Amplia (Gmail, Outlook)	Limitada fuera del ecosistema alemán
Reporting	TLS-RPT (RFC 8460)	TLS-RPT (RFC 8460)
Coste de implementación	Moderado (DNS + HTTPS)	Alto (DNSSEC obligatorio)

Cuándo elegir MTA-STS: no tiene DNSSEC, o desea una implementación rápida con esfuerzo operativo mínimo.

Cuándo elegir DANE: su dominio ya está firmado con DNSSEC y desea la garantía adicional del pinning criptográfico.

Ambos son compatibles y pueden desplegarse en paralelo. Los MTAs emisores eligen el mecanismo que saben manejar.

Herramientas complementarias y recursos

Herramienta	Utilidad
Validador Sintaxis MTA-STS	Validar la sintaxis de una política ANTES de publicar
Generador MTA-STS	Crear registro TXT y política HTTPS conformes
Alojamiento MTA-STS	Alojar gratuitamente su política con TLS gestionado
Verificador TLS-RPT	Verificar el registro TLS-RPT asociado
Monitorización TLS-RPT	Recibe y analiza automáticamente tus reportes TLS-RPT
Inspector DMARC	Completar la autenticación de correo con DMARC
Lookup MX	Inspeccionar los registros MX del dominio

Recursos: