Generador de políticas MTA-STS y registros DNS TLS-RPT

Generador de políticas MTA-STS y registros DNS TLS-RPT

Referencia técnica integral y mejores prácticas para generar archivos de directivas RFC 8461 MTA-STS, registros DNS TXT _mta-sts y registros de informes RFC 8460 TLS-RPT.

Preajustes:
Configuración de directiva y DNS

Host de directiva: mta-sts.example.com

Strict security: rejects unencrypted/invalid TLS delivery.

Nombres de host autorizados para intercambio de correo (MX)2
mx:mail.example.com
mx:mx2.example.com
7 days (1 week)

Incrementa el ID al editar la directiva para que los remitentes la recarguen.

Informes de incidentes SMTP TLS-RPT (RFC 8460)
Domain: example.comMode: enforceCantidad MX: 2
RFC 8461 STSv1
version: STSv1
mode: enforce
mx: mail.example.com
mx: mx2.example.com
max_age: 604800
Lines: 6Chars: 86Size: 86 B
Served at https://mta-sts.<domain>/.well-known/mta-sts.txt
Postura de aplicación
enforceStrict TLS
Destinos de correo autorizados
2 MX Patterns
Vida útil de caché de directiva
7 days (1 week)

Compilación local de latencia cero

Sintetiza archivos de directivas RFC 8461 y registros DNS TXT al instante en la memoria del navegador, sin transmisiones de red.

Validación RFC 8461 y RFC 8460

Valida la sintaxis de comodines MX, restricciones de no-IP, límites alfanuméricos de ID de política y estándares HTTPS.

Listo para despliegue multiplataforma

Exporta fragmentos listos para implementar en BIND, Cloudflare, Route 53, Nginx, Caddy, Apache y HashiCorp Terraform.

Referencia técnica y guía de arquitectura

Guía para Desarrolladores del Generador de Políticas MTA-STS y Registros DNS TLS-RPT — Guía de referencia

Referencia técnica integral y mejores prácticas para generar archivos de directivas RFC 8461 MTA-STS, registros DNS TXT _mta-sts y registros de informes RFC 8460 TLS-RPT.

Parámetros clave y controles

modestring (enforce | testing | none)

Define el comportamiento de aplicación de MTA-STS para conexiones SMTP entrantes. 'testing' solicita a los MTAs emisores reportar fallos sin descartar correos, 'enforce' exige TLS válido y bloquea conexiones no seguras, y 'none' desactiva la directiva.

Por defecto: testing
mxstring | string[]

Lista de patrones de servidores de correo autorizados (FQDNs o comodines de un solo nivel como *.mail.example.com) contra los cuales los emisores deben conectar y validar los certificados SAN.

Por defecto: mail.example.com
max_ageinteger (segundos)

Tiempo en segundos durante el cual el MTA emisor almacena en caché la directiva localmente. Valores estándar en producción van de 604800 (1 semana) a 1209600 (2 semanas). En fase de despliegue se aconseja 86400.

Por defecto: 604800
policy_idstring

Identificador único especificado en el registro DNS TXT _mta-sts (normalmente una marca de tiempo como 2026101701). Al modificarse, obliga a los MTAs remotos a invalidar su caché y volver a descargar mta-sts.txt vía HTTPS.

Por defecto: 20261017000000
ruastring (mailto URI)

Dirección de correo electrónico receptora declarada en el registro _smtp._tls donde los servidores emisores compatibles envían informes agregados diarios en formato JSON sobre fallos de TLS.

Por defecto: mailto:[email protected]

Consejos profesionales y mejores prácticas

Configure su registro _smtp._tls

Configure su registro _smtp._tls TLS-RPT y mantenga MTA-STS en modo 'testing' durante al menos dos semanas antes de aplicar 'enforce'. Analice los informes diarios para detectar desajustes en suites de cifrado, certificados intermedios ausentes o problemas de SNI sin riesgo de pérdida de correo.

El archivo de directiva debe servirse

El archivo de directiva debe servirse en https://mta-sts.<dominio>/.well-known/mta-sts.txt con código de estado HTTP 200, Content-Type text/plain y un certificado TLS público válido. No se admiten certificados autofirmados, expirados ni redirecciones entre diferentes nombres de host.

Las líneas 'mx

Las líneas 'mx:' de su directiva deben concordar exactamente con los registros DNS MX de su dominio y con los nombres SAN del certificado TLS del servidor de correo. Si su MX es mail.example.com, el certificado debe ser válido para mail.example.com o *.example.com.

Errores comunes y solución de problemas

Fallo al obtener la directiva: Los MTAs emisores reportan errores HTTPS o de certificado en el subdominio mta-sts

Verifique que existan registros DNS A/AAAA para 'mta-sts.<sudominio>' y que el servidor web entregue un certificado válido que cubra dicho subdominio. Confirme que el puerto 443 sea accesible públicamente y responda en menos de 10 segundos sin redirecciones externas.

Correos legítimos entrantes son rechazados tras activar el modo 'enforce'

Compruebe si el certificado TLS de algún servidor MX ha caducado o si el soporte STARTTLS ha fallado. Como medida de contingencia, cambie el modo a 'testing' en el archivo y actualice el valor de policy_id en el DNS TXT para forzar la recarga inmediata de la directiva en los MTAs emisores.

Preguntas frecuentes (FAQ)

¿Cuál es la diferencia entre MTA-STS y DANE TLSA?▼

MTA-STS (RFC 8461) se apoya en la infraestructura tradicional de Web PKI (certificados firmados por CAs públicas servidos sobre HTTPS) y registros DNS. Por su parte, DANE (RFC 7672) vincula claves o certificados directamente en el DNS mediante registros TLSA, requiriendo que la zona esté completamente firmada con DNSSEC.

¿Por qué es crucial el parámetro policy_id (id) en el registro DNS?▼

Los servidores de correo almacenan la directiva en caché durante el tiempo indicado en max_age. Para no saturar con peticiones HTTPS, los emisores solo consultan el DNS TXT; si el valor de 'id=' no cambia, no vuelven a descargar el archivo de directiva, manteniendo activa la versión anterior en memoria caché.

¿Qué ocurre si un servidor emisor no soporta MTA-STS?▼

Los servidores que no implementan RFC 8461 omiten los registros _mta-sts y la comprobación HTTPS. Continúan operando con STARTTLS oportunista estándar y, en caso de fallo en la negociación TLS, transmitirán el mensaje en texto sin cifrar.

¿Es posible declarar múltiples servidores MX en una sola política MTA-STS?▼

Sí. Puede incluir tantas líneas 'mx:' como requiera (por ejemplo, 'mx: mx1.example.com' y 'mx: mx2.example.com'). Todos los hosts MX publicados en la zona DNS de su dominio deben estar contemplados en el archivo de política.

Herramientas y utilidades relacionadas

Todas las herramientas →
Decodificador e Inspector de Seguridad de Tokens JWTSeguridad

Utilidad para desarrolladores que decodifica tokens JWT del lado del cliente, inspecciona claims RFC 7519 y OIDC, audita tiempos de expiración y verifica firmas HMAC localmente.

Abrir herramienta→
Generador Criptográfico de Contraseñas y Frases de PasoSeguridad

Genere contraseñas seguras de alta entropía, frases de paso memorables (Diceware), códigos PIN y tokens de API mediante la API Web Crypto CSPRNG según NIST SP 800-63B.

Abrir herramienta→
Generador de Huellas y Hash CriptográficoSeguridad

Calcule al instante valores hash SHA-256, SHA-512, MD5, SHA-1, SHA-3, Keccak y CRC32 localmente en su navegador mediante la API Web Crypto 100% segura.

Abrir herramienta→
Depurador y Verificador de Firmas JSON Web Token (JWT)Seguridad

Decodifica, inspecciona y verifica firmas HMAC (HS256/384/512) y RSA (RS256/384/512) 100% en la memoria del navegador. Cero telemetría en la nube.

Abrir herramienta→
Verificador de Fuerza de Contraseña ReferenciaSeguridad

Guía técnica para evaluar la fortaleza de contraseñas, cálculo de entropía y estimación de tiempo de vulneración.

Abrir herramienta→
Referencia para Desarrolladores de AES Encryption ToolSeguridad

Especificaciones tecnicas y guia de parametros para cifrado simetrico AES-GCM y AES-CBC mediante Web Cryptography API.

Abrir herramienta→