MTA-STS Validator Gratis

Por qué usar un validador offline

Un validador de sintaxis MTA-STS analiza su registro DNS TXT y su archivo de política sin publicarlos ni consultar el DNS. Este enfoque offline cubre tres casos de uso clave que una auditoría en vivo no puede abordar.

Casos de uso típicos:

• Antes del despliegue → Valide un borrador de política antes de publicarlo, para evitar una configuración incorrecta en producción.
• Preparación multi-dominio → Verifique varias políticas en lote durante una migración o una auditoría interna.
• Depuración offline → Reproduzca y corrija un error sin acceso al DNS público, por ejemplo en un entorno aislado o pre-producción.
• Revisión de configuración → Examine un registro recibido de un socio o exportado por una herramienta de terceros antes de aplicarlo.

El validador aplica las reglas de sintaxis del RFC 8461: versión, identificador, modo, patrones MX, max_age y coherencia entre el registro DNS y la política. No se conecta a ningún servidor, no resuelve DNS y no descarga ningún archivo remoto.

Cómo usar este validador en 3 pasos

Paso 1: pegar el registro y la política

Puede validar tres combinaciones:

• Solo el registro TXT _mta-sts (modo record_only)
• Solo el contenido del archivo mta-sts.txt (modo policy_only)
• Ambos juntos para verificar la coherencia (modo combinado)

No se realiza ninguna conexión de red. Sus datos permanecen en su navegador.

Paso 2: añadir un dominio (opcional)

Añadir un dominio activa la validación híbrida: el validador resuelve los registros MX del dominio y verifica que los patrones declarados en la política coinciden con los servidores reales. Este modo ayuda a detectar una política demasiado restrictiva o un MX olvidado.

Sin dominio, solo se analiza la sintaxis pura.

Paso 3: analizar el veredicto

Los resultados se clasifican por nivel de gravedad:

• ❌ Error → Problema bloqueante, los MTA destinatarios ignorarán la política
• ⚠️ Advertencia → Funcional pero se recomienda mejorar
• ✅ Válido → Sintaxis conforme con RFC 8461

Corrija cada alerta antes de publicar su registro y su archivo en producción.

Validador o record check: cuándo usar cada herramienta

Las dos herramientas son complementarias. No se sustituyen entre sí: intervienen en momentos diferentes del ciclo de vida de una política MTA-STS.

Flujo de trabajo recomendado:

1. Diseñe la política → validador para verificar la sintaxis
2. Publique DNS + archivo → espere la propagación
3. Record check para confirmar la auditoría en vivo completa

El validador detecta errores de entrada antes de que lleguen a sus usuarios. El record check detecta derivas, certificados caducados y problemas de obtención HTTPS que solo aparecen en condiciones reales.

Modos de validación

El validador soporta cuatro modos según los campos rellenados.

Modo record_only

Pega solo el registro TXT. Validación de:

• Formato v=STSv1
• Presencia y formato de la etiqueta id
• Etiquetas desconocidas o duplicadas

Modo policy_only

Pega solo el contenido del archivo de política. Validación de:

• Directiva version
• Directiva mode (enforce, testing, none)
• Patrones mx (al menos uno requerido)
• Directiva max_age (límites 0 a 31557600)

Modo combinado de registro y política

Pega ambos. Validación completa más:

• Coherencia de versión entre TXT y archivo
• Coherencia de intención (un mode: none con un id activo es sospechoso)

Modo híbrido con dominio

Añada un dominio al modo combinado para activar:

• Resolución de los MX del dominio
• Verificación de que cada MX real coincide con al menos un patrón mx:
• Detección de servidores MX olvidados o patrones demasiado estrictos

Esta validación MX permanece estática: compara los patrones con los hosts MX declarados sin probar conexiones SMTP.

Reglas de sintaxis verificadas

Registro DNS

El validador aplica las reglas del RFC 8461 §3.1 sobre el TXT _mta-sts.dominio:

Ejemplo válido:

v=STSv1; id=20240115120000

Archivo de política

El validador aplica el RFC 8461 §3.2 sobre mta-sts.txt:

Ejemplo válido:

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

Coherencia entre registro y política

Cuando se proporcionan ambos:

• El id del TXT debe corresponder a una política coherente (un cambio de política implica un nuevo id).
• mode: none con un TXT activo se señala: a menudo indica una intención de retirada incompleta.

Patrones MX y reglas wildcard

El RFC 8461 §4.1 define un formato estricto para los patrones mx:. El validador aplica el siguiente matching exacto.

Nombre de host exacto

mx: mail.captaindns.com
mx: smtp.captaindns.com

Coincide con el nombre exacto, sin distinguir mayúsculas/minúsculas.

Patrón wildcard

mx: *.mail.captaindns.com

Reglas estrictas:

• El wildcard * debe ser la etiqueta más a la izquierda
• Coincide con exactamente una etiqueta (server1.mail.captaindns.com coincide, a.b.mail.captaindns.com no)
• Sin doble wildcard (**.captaindns.com es inválido)
• Sin wildcard en el medio o al final (mail.*.captaindns.com es inválido)

Varios patrones en una política

Una política puede contener varias líneas mx::

mx: mail.captaindns.com
mx: smtp.captaindns.com
mx: *.backup.captaindns.com

Un MX real debe coincidir con al menos un patrón. El validador señala los MX reales huérfanos cuando se proporciona un dominio.

Patrones inválidos típicos

Errores de sintaxis comunes y correcciones

Versión incorrecta

Causa: v=sts1, v=STSV1 o version: stsv1 en lugar de STSv1 exactamente.

Corrección:

- v=sts1; id=20240115
+ v=STSv1; id=20240115

Identificador ausente

Causa: el registro TXT no contiene la etiqueta id.

Corrección: añada un identificador único (timestamp recomendado):

v=STSv1; id=20240115120000

Formato de id incorrecto

Causa: espacios, caracteres especiales o longitud excesiva en id.

Corrección: use solo caracteres alfanuméricos, 1 a 32 caracteres.

- id=my policy id
+ id=mypolicyid20240115

Modo inválido

Causa: mode: strict, mode: ENFORCE o error tipográfico.

Corrección: solo uno de los tres valores permitidos:

- mode: strict
+ mode: enforce

max_age fuera de límites

Causa: negativo, no numérico o superior a 31557600.

Corrección: entero en [0, 31557600]. Valor recomendado para producción: 604800 (1 semana).

- max_age: 99999999
+ max_age: 604800

Patrón malformado

Causa: wildcard mal colocado o caracteres prohibidos en una línea mx:.

Corrección: vea la sección de patrones MX más arriba.

- mx: mail.*.captaindns.com
+ mx: *.mail.captaindns.com

Sin patrón de servidor

Causa: ninguna línea mx: en una política en modo enforce o testing.

Corrección: añada al menos una línea mx: que se corresponda con su infraestructura. En modo none, la ausencia de mx: se tolera.

Herramientas complementarias y recursos

Guías relacionadas

• MTA-STS: la guía completa para proteger el transporte de tus emails - Configuración, despliegue y mejores prácticas.
• Resolución de problemas MTA-STS: errores comunes y soluciones - Diagnosticar problemas de política en producción.
• Pasar MTA-STS del modo testing al modo enforce - Migración progresiva sin romper la entregabilidad.

Especificaciones

• RFC 8461 - SMTP MTA Strict Transport Security (especificación oficial)
• Formato del registro DNS MTA-STS (§3.1)
• Formato del archivo de política MTA-STS (§3.2)
• Documentación MTA-STS de Google (guía Workspace)

FAQ - Preguntas frecuentes

P: ¿Qué diferencia hay entre el validador y el record check MTA-STS?

R: El validador analiza la sintaxis que usted pega, antes de la publicación, sin tocar el DNS. El record check consulta el DNS y HTTPS para verificar la configuración publicada. Use el validador antes y el record check después.

P: ¿Por qué validar sintaxis MTA-STS sin conexión?

R: Para detectar errores antes de que afecten a sus usuarios. Una política inválida es ignorada por los MTA destinatarios: su dominio queda expuesto. Es mejor corregir una errata en un borrador que diagnosticar un fallo en producción.

P: ¿Cuáles son los errores de sintaxis comunes?

R: Los clásicos: STSV1 en lugar de STSv1, mode: strict en lugar de enforce, max_age no numérico, wildcard mal colocado (mail.*.captaindns.com), ausencia de la etiqueta id en el TXT o varias líneas version en el archivo.

P: ¿Qué formatos de patrón MX son válidos?

R: Nombre exacto (mail.captaindns.com) o wildcard de una sola etiqueta en posición leftmost (*.mail.captaindns.com). Sin wildcard solo, sin doble wildcard, sin wildcard en medio de un nombre.

P: ¿Qué valores max_age se recomiendan?

R: RFC 8461 exige 0 ≤ max_age ≤ 31557600 (1 año). Valores comunes: 86400 (1 día) para la fase de testing, 604800 (1 semana) para producción estable, 31557600 (1 año) para una política madura y fija.

P: ¿Cómo corrijo un error 'versión inválida'?

R: La versión debe ser exactamente STSv1 (sensible a mayúsculas/minúsculas) en el TXT (v=STSv1) y en la política (version: STSv1). Verifique mayúsculas/minúsculas, espacios y la ausencia de caracteres parásitos.

P: ¿Cómo valido la sintaxis MTA-STS para Microsoft 365?

R: Pegue su TXT y su política. Asegúrese de que sus patrones MX cubren *.mail.protection.outlook.com. El validador verifica la conformidad RFC 8461 antes de publicar en DNS, luego use el record check tras el despliegue.

P: ¿Cómo verifico la sintaxis MTA-STS para Google Workspace?

R: Pegue su TXT y su política. Los MX de Google están en *.google.com (o aspmx.l.google.com). Asegúrese de que sus patrones coincidan con estos hostnames antes de publicar.