Lee los servidores de correo de tu dominio desde MX, obtén de una vez el archivo de política MTA-STS, el registro _mta-sts y el registro de informes TLS, y mira lo que tu dominio publica hoy. Gratis, sin registro.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) indica a los servidores remitentes que tu dominio solo acepta correo por una conexión cifrada con un certificado válido, y en qué servidores. Sin él, el cifrado entre servidores de correo es opcional: un atacante en el camino puede eliminar la oferta de TLS y leer el correo en claro sin que el remitente lo note.
MTA-STS consta de un archivo de política en un servidor web y un registro TXT que lo anuncia. TLS-RPT (RFC 8460) añade una dirección de informes a la que los remitentes avisan cuando no pudieron entregar de forma segura. El generador escribe los tres.
1. Carga tus servidores de correo. Escribe el dominio y pulsa «Cargar registro publicado». El generador lee los registros MX y los pone como líneas mx de la política. Los hosts de un mismo proveedor pueden agruparse con un comodín como *.mail.protection.outlook.com.
2. Publica el archivo de política. Va en https://mta-sts.example.com/.well-known/mta-sts.txt, servido como texto plano por HTTPS con un certificado válido para mta-sts.example.com. El subdominio necesita un registro A o CNAME hacia cualquier servidor web que pueda alojar el archivo.
3. Publica los dos registros TXT. _mta-sts con v=STSv1; id=... anuncia la política; _smtp._tls con v=TLSRPTv1; rua=mailto:... indica la dirección de los informes TLS diarios.
4. Empieza en testing y pasa a enforce. En modo testing, los remitentes informan de los problemas pero siguen entregando. Tras dos semanas de informes TLS limpios, cambia el archivo a mode: enforce y modifica el id del registro TXT para que los remitentes descarguen la nueva versión.
| Línea | Significado |
|---|---|
version: STSv1 |
Siempre este valor. |
mode: testing |
testing solo informa, enforce rechaza la entrega insegura, none retira una política. |
mx: mx1.example.com |
Una línea por servidor autorizado a recibir correo. Un comodín cubre exactamente un nivel. |
max_age: 604800 |
Segundos que un remitente puede guardar la política en caché. Como máximo 31557600, un año. |
Las líneas se separan con CRLF, igual que en el archivo descargado. El id del registro TXT es una cadena libre de hasta 32 caracteres; el generador usa la marca de tiempo actual, así que cada política nueva recibe automáticamente un id nuevo. Los remitentes solo vuelven a descargar el archivo cuando cambia el id o vence max_age.
*.example.com coincide con mx1.example.com, pero no con mx1.eu.example.com.De los 1.000 dominios .de mejor clasificados de la lista Tranco (lista 467YX, leída el 19 de octubre de 2026), 924 reciben correo. Solo 63 publican un registro MTA-STS y 62 un registro TLS-RPT. Más de nueve de cada diez dominios alemanes con servidor de correo siguen aceptando, sin que nadie lo note, que se rebaje la entrega a una sin cifrar. MTA-STS es una de las pocas protecciones de correo que solo cuestan un archivo pequeño y dos registros DNS.
Las líneas mx deben coincidir con los nombres de host de tus registros MX. En el correo alojado, los nombres del proveedor son estables, y un comodín mantiene válida la política cuando se añade un host.
| Correo alojado en | Líneas mx de la política |
|---|---|
| Microsoft 365 | mx: *.mail.protection.outlook.com |
| Google Workspace | mx: smtp.google.com para la configuración actual, o mx: aspmx.l.google.com más mx: *.aspmx.l.google.com para la clásica |
| Tu propio servidor | exactamente los nombres de tus registros MX, p. ej. mx1.example.com |
Compara el resultado con tus registros MX reales antes de pasar a enforce. «Cargar registro publicado» rellena el campo desde MX y, una vez publicada una política, la comprobación señala cada host MX que no cubre. Recuerda que un comodín cubre un solo nivel: *.aspmx.l.google.com coincide con alt1.aspmx.l.google.com, pero no con aspmx.l.google.com, que por eso necesita su propia línea.
El archivo solo necesita HTTPS con un certificado válido para mta-sts. seguido de tu dominio. Opciones habituales:
/.well-known/mta-sts.txt.Uses lo que uses, el archivo debe servirse con estado 200, directamente desde mta-sts. seguido de tu dominio, sin redirigir a otro host. Los remitentes no siguen redirecciones, y una política redirigida cuenta como inexistente.
Sí, pero uno mínimo. Los remitentes descargan un pequeño archivo de texto por HTTPS desde mta-sts.tudominio. Sirve cualquier hosting web o estático con un certificado válido para ese nombre; el archivo solo cambia cuando cambian tus servidores de correo.
En testing, los remitentes comprueban la política e informan de los fallos mediante TLS-RPT, pero entregan igualmente. En enforce, se niegan a entregar a un servidor listado por una conexión sin TLS válido. Empieza en testing y cambia cuando los informes estén limpios.
Los dos resuelven el mismo problema de dos maneras. DANE necesita DNSSEC y lo usan muchos proveedores europeos; MTA-STS funciona sin DNSSEC y lo admiten Gmail y Microsoft. Publicar ambos es habitual y no tiene inconvenientes.
Un informe JSON por remitente y día: cuántas conexiones se establecieron, cuántas funcionaron con TLS válido y el motivo de cada fallo, como un certificado caducado o un host que falta en la política. No contienen el contenido de ningún mensaje.
Cambia el archivo a mode: none, da un id nuevo al registro TXT y mantén ambos en línea al menos durante el max_age que publicaste antes. Si borras los registros enseguida, los remitentes seguirán aplicando la política en caché hasta que caduque.
No. La política y los registros se crean en el navegador. «Cargar registro publicado» lee MX, _mta-sts y _smtp._tls del dominio y descarga el archivo de política publicado, como haría cualquier remitente. No se guarda nada.
«Cargar registro publicado» pide a nuestro resolver los registros MX y los registros TXT en _mta-sts y _smtp._tls, y descarga el archivo de política desde https://mta-sts. seguido de tu dominio. Después, el validador del Email Security Check compara cada línea mx de una política publicada con los hosts MX reales, de modo que un servidor que la política no cubre se señala antes de que enforce lo bloquee.
El generador funciona en el navegador: escribe la política con el modo, los servidores y el tiempo de caché que elijas, usa una marca de tiempo como id y construye el registro TLS-RPT a partir de tu dirección de informes. No puede configurar el servidor web ni el certificado del subdominio mta-sts, y no comprueba si tus servidores de correo presentan certificados válidos; eso lo dirán los informes TLS.