¿MTA-STS evita que mis correos lleguen a spam?

No. MTA-STS protege el correo en tránsito cuando entra a tu dominio. No cambia nada en cómo Gmail u Outlook juzgan los mensajes que tú envías, ni en la carpeta donde caen. Eso lo mueven SPF, DKIM, DMARC, la reputación de envío y la higiene de listas.

¿Google Workspace o Microsoft 365 pueden alojar el archivo de política por mí?

No. Los dos documentan que el archivo lo publica el dueño del dominio. Microsoft dice que Exchange Online no aloja archivos de política para sus clientes, y las instrucciones de Google son subir el archivo a un servidor web que controles, en un host cuyo nombre empiece con mta-sts y con HTTPS con certificado de una autoridad confiable.

¿Qué pasa si dejo la política en modo testing para siempre?

No se rompe nada, y tampoco se protege nada. En modo testing los remitentes hacen la validación y te mandan reportes TLS, y luego entregan el mensaje haya pasado o no. Solo el modo enforce hace que un remitente rechace una conexión insegura, así que testing es un paso previo, no un destino.

MTA-STS en Google Workspace: registros, política y enforce

Imagina una empresa de logística de 30 personas que gana un contrato con un grupo hospitalario. En el papeleo de arranque aparece un cuestionario de seguridad, y una línea pregunta si el correo que entra a su dominio está protegido con MTA-STS. Nadie ahí lo ha oído nombrar. Su correo corre en Google Workspace, SPF, DKIM y DMARC están en orden, y ninguno de los tres tiene que ver con lo que están preguntando.

Así llega MTA-STS a una pyme casi siempre: no como un reclamo de entregabilidad, sino como un renglón en la revisión de alguien más. El trabajo es corto y las formas de romperlo son concretas, así que vale la pena hacerlo bien una vez en lugar de publicar medio registro que no reporta nada.

Qué hace MTA-STS y qué no toca

Cuando un servidor de correo le entrega un mensaje a otro, el cifrado normalmente es oportunista. El servidor que envía pregunta si hay TLS disponible, el que recibe dice que sí, y la conversación va cifrada. Si la respuesta es no, o si algo en el camino quita la oferta, la mayoría de los remitentes entrega el mensaje igual, en texto claro, en vez de fallarlo. Ese respaldo es justo lo que MTA-STS elimina.

MTA-STS, especificado en el RFC 8461, le permite al dueño de un dominio publicar una política que dice tres cosas: el correo para este dominio debe llegar por TLS, estos son los nombres de servidor autorizados a recibirlo, y el certificado tiene que ser válido para esos nombres. Un servidor que soporta el estándar lee la política, la guarda en caché y desde entonces se niega a entregar cuando la conexión no se puede asegurar. El RFC 8461 remite al RFC 6125 para la revisión del certificado: el nombre del certificado debe coincidir con el host del MX y el certificado no puede estar vencido.

De ahí salen dos consecuencias, y se confunden todo el tiempo.

Protege el correo que entra, no el que sale. Tu política le da instrucciones a los servidores de los demás. No cambia nada en la forma en que salen tus propios mensajes.
No es un control de autenticación. SPF, DKIM y DMARC deciden si un mensaje viene de verdad de tu dominio. MTA-STS decide si la conexión que lo trajo iba cifrada y si el servidor del otro lado era el correcto. Un dominio puede estar en DMARC p=reject y seguir aceptando correo por una conexión en texto claro.

Gmail lee lo que publican los demás dominios: Google anunció ese soporte con un despliegue que empezó el 10 de abril de 2019, y en el mismo anuncio aclaró que las políticas MTA-STS de tu propio dominio vienen apagadas por defecto. Microsoft documenta el mismo arreglo para Exchange Online: el soporte de MTA-STS entrante es parte del servicio y la política la publica el dueño del dominio.

Las tres piezas que se publican

Dos registros DNS y un archivo en un servidor web. El primer registro señala que existe una política:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261002120000"

El id es una marca de versión de 1 a 32 caracteres alfanuméricos. Google recomienda usar la fecha y la hora actuales, para que sepas cuándo cambió la política por última vez, y darle un valor nuevo cada vez que edites el archivo. Los remitentes guardan la política en caché, y el id es la manera en que se enteran de que hay una versión más reciente.

La política es un archivo de texto plano. El nombre debe ser mta-sts.txt, tiene que vivir en un directorio .well-known dentro de un host cuyo nombre empiece con mta-sts, y la línea version va primero:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: testing
mx: smtp.google.com
max_age: 604800

La tercera pieza es un registro aparte para los reportes, definido en el RFC 8460. Sin él, aplicas la política a ciegas:

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

El RFC 8460 acepta destinos mailto: y https:, y la documentación de Google muestra varias direcciones mailto separadas por comas cuando los reportes deben llegarle a más de una persona. Crea el buzón antes de publicar el registro.

Las líneas mx tienen que coincidir con los MX que de verdad tienes

Aquí se cae casi todo primer intento. La política necesita una entrada mx por cada host MX del dominio, una por línea. Se permite un comodín, pero reemplaza una sola etiqueta de la izquierda, así que *.example.com cubre mail.example.com y no mail.eu.example.com.

En un dominio con Google Workspace la respuesta depende de qué configuración de MX tengas. La instrucción actual de Google es un solo registro MX, smtp.google.com con prioridad 1. Los dominios configurados antes de 2023 suelen seguir con el juego heredado que Google documenta, ASPMX.L.GOOGLE.COM más ALT1 hasta ALT4.ASPMX.L.GOOGLE.COM. Esos siguen funcionando y no hay que cambiarlos, pero una política escrita para una configuración y publicada en un dominio que corre la otra falla la validación, así que primero lee la respuesta MX en vivo. La regla del comodín de una etiqueta importa aquí: *.aspmx.l.google.com cubre los cuatro hosts ALT y no aspmx.l.google.com, así que un dominio heredado necesita las dos líneas.

Si el dominio está en Microsoft 365, Microsoft indica a los clientes cuyo MX apunta directo a Exchange Online usar *.mail.protection.outlook.com, con los mismos valores de version, mode y max_age que Microsoft publica para su propio dominio. Microsoft también dice sin rodeos que Exchange Online no aloja el archivo de política por el cliente. Google dice lo mismo con otras palabras: sube el archivo a un servidor web que controles. Publicar la política es una tarea de hosting, no un ajuste de correo, y por eso suele ser la parte que nadie tiene asignada.

Primero en modo testing, y qué te dicen los reportes

El campo mode acepta tres valores. testing le pide a los remitentes que hagan la validación y reporten el resultado, y que entreguen el mensaje de todas formas. enforce les pide que se nieguen a entregar cuando la validación falla. none retira una política que ya no quieres que se respete, lo cual importa porque algunos remitentes todavía pueden tener en caché la anterior.

max_age es cuánto tiempo, en segundos, puede durar ese caché. El RFC 8461 lo limita a 31557600, cerca de un año, y señala que se espera un valor de semanas o más, porque una vida corta le da al atacante más oportunidades en el momento de la renovación. Google recomienda entre 86400 y 31557600 en general, y entre 604800 y 1209600, una a dos semanas, mientras la política está en testing, para que una corrección se propague en días y no en meses.

Deja la política en testing un ciclo completo de reportes. El RFC 8460 dice que un reporte debería cubrir un día completo, de 00:00 a 24:00 UTC, y llega como archivo JSON, así que una semana te da unos siete archivos por cada remitente que reporta. Lo que buscas no es cero reportes. Son reportes con cero fallas. Un buzón en silencio casi siempre significa que el registro _smtp._tls está mal, no que todo esté sano.

Cuatro formas en que falla la lectura de la política

Todo esto es DNS y un archivo estático, así que suena difícil de arruinar. En la práctica, cuatro problemas explican casi todas las políticas rotas que encontramos.

Una redirección. El RFC 8461 solo acepta un HTTP 200 al leer la política: las redirecciones 3xx no se deben seguir y el caché HTTP no se debe usar. Una regla de apex a www aplicada a todos los subdominios, o un hosting que manda mta-sts.example.com a www.example.com sin avisar, rompe la política aunque el archivo esté bien.
El tipo de contenido equivocado. Los remitentes deberían verificar que el tipo de medio sea text/plain. Un servidor que entrega extensiones desconocidas como binario genérico, o que responde con una página HTML de error, falla esa revisión.
Un problema de certificado en el host de la política. El subdominio mta-sts necesita HTTPS con un certificado de una autoridad pública confiable, y necesita seguir vigente. Es un segundo certificado que mantener vivo, distinto de los de tus servidores de correo, y el que se olvida porque ninguna persona entra nunca a esa página.
Un id viejo. Editas la política, olvidas el id, y todo remitente con una copia en caché sigue usando el archivo anterior hasta que expire max_age. El síntoma es un cambio que funciona con los nuevos y no con tu principal corresponsal.

Qué revisamos en el dominio de un cliente antes de pasar a enforce

El orden importa, porque el error caro es aplicar una política que no describe la ruta real del correo del dominio.

Leer la respuesta MX en vivo y escribir las líneas mx a partir de eso, no de una guía de configuración.
Confirmar que el certificado de cada host MX coincide con el nombre que está en la política y no está cerca de vencer. El requisito que Google publica es TLS 1.2 o superior, con un certificado que coincida con el nombre del servidor de correo entrante y firmado por una autoridad raíz confiable.
Pedir la URL de la política desde fuera de la red y mirar el código de estado, la URL final y el tipo de contenido, no solo el cuerpo.
Buscar si hay una pasarela de entrada, equipo de filtrado o archivador externo delante de los buzones. Todo lo que termine SMTP para el dominio tiene que aparecer en la política con un certificado que coincida.
Publicar el registro de reportes TLS y verificar que un reporte llegue de verdad.
Correr una semana en testing, leer todos los reportes y recién entonces cambiar mode y subir el id en la misma edición.

En un dominio con Workspace, la consola de administración tiene un validador para esto, en Apps, Google Workspace, Gmail, Cumplimiento. Muestra el estado actual del registro _mta-sts, del archivo de política y del registro _smtp._tls por dominio, y la página de estado de seguridad también lo reporta. Úsalo como segunda opinión, después de leer los registros tú mismo.

Qué cambia el día que pasas a enforce y qué vigilar después

Después del cambio, un remitente que soporta MTA-STS y no logra una conexión TLS válida con uno de los hosts que listaste no va a entregar. Ese es el objetivo, y también el riesgo nuevo: tu correo entrante ahora depende de que los certificados sigan vigentes y de que la política siga describiendo la realidad.

Tres eventos deberían disparar una edición de la política, cada uno con un id nuevo: cambiar registros MX, agregar o quitar una pasarela de correo, y mover el dominio de plataforma. El caso de la migración es el que duele. Si pasas de Microsoft 365 a Google Workspace con una política en enforce que todavía lista *.mail.protection.outlook.com, todo remitente que entiende MTA-STS rechaza el correo que tus nuevos MX están recibiendo sin problema. Pon mode: testing antes del corte, o retira la política con mode: none y espera a que pase max_age, y luego vuélvela a armar en la plataforma nueva. La secuencia de nuestra guía para cambiar los registros MX sin perder correo aplica igual aquí.

Después, sigue leyendo los reportes TLS. Son la única señal rutinaria de que una renovación de certificado o una edición de DNS rompió algo en silencio.

Cómo ayuda Guanacos Tech

Publicamos MTA-STS y los reportes TLS para nuestros clientes dentro del mismo trabajo en que arreglamos SPF, DKIM y DMARC, porque las dos preguntas suelen llegar en la misma revisión de seguridad. Si quieres dejarlo bien desde la primera vez, o tienes una política publicada que no reporta nada, nuestra consultoría de entregabilidad de correo lo cubre. Con una llamada de 30 minutos alcanza para leer tus registros actuales, decirte en qué estado está el dominio y acordar el orden del despliegue.

MTA-STS y reportes TLS en Google Workspace: los registros, el archivo de política y un despliegue que no pierde correo