MTA-STS para email: qué es y cómo configurarlo paso a paso

MTA-STS es un estándar que permite a tu dominio exigir que el correo que le llega viaje cifrado con TLS y hacia un servidor MX auténtico. Si un servidor remitente no consigue una conexión segura, no entrega el mensaje en claro: lo retiene o lo rechaza. Se configura con tres piezas: un registro TXT en DNS, un archivo de política publicado por HTTPS y, muy recomendable, un registro TLS-RPT para recibir informes de fallos.

Esta guía explica cómo funciona, qué necesitas antes de empezar, cómo desplegarlo sin cortar tu propio correo y cómo encaja con SPF, DKIM y DMARC si envías campañas de email en frío.

Plusvibe

Cuida la entregabilidad de tus emails

PlusVibe reúne herramientas de entregabilidad y monitorización para equipos que gestionan campañas de email en frío.

Conoce PlusVibe

En resumen

MTA-STS evita que un atacante degrade o intercepte la conexión SMTP entre servidores, algo que el STARTTLS oportunista por sí solo no impide.
Necesitas un registro TXT _mta-sts, un archivo de política en un subdominio mta-sts con HTTPS válido y un registro _smtp._tls para TLS-RPT.
Empieza siempre en modo testing, revisa los informes diarios y pasa a enforce solo cuando no veas fallos legítimos.
Protege el correo que recibe tu dominio, no el que envías. Tus envíos dependen de que el destinatario tenga su propia política.

Tabla de contenidos

Qué es MTA-STS y qué problema resuelve
Cómo funciona: registro DNS, política y TLS-RPT
Requisitos previos antes de tocar el DNS
Configuración paso a paso
De testing a enforce sin perder correo
Errores frecuentes
MTA-STS, DMARC y la entregabilidad del email en frío
Nuestra perspectiva
Cómo te ayuda PlusVibe con la entregabilidad
Preguntas frecuentes
Fuentes

Qué es MTA-STS y qué problema resuelve

El correo entre servidores usa SMTP, y SMTP no tiene forma de obligar a cifrar. Lo habitual es STARTTLS oportunista: el servidor que envía pregunta si el receptor admite TLS y, si es así, cifra. Un atacante situado en medio puede borrar esa oferta de cifrado y el mensaje viaja en texto claro, sin que remitente ni destinatario lo noten. Google lo describe como un riesgo de ataques de intermediario en los que se elimina el cifrado o se intercepta el mensaje, y es la razón por la que explica MTA-STS y los informes TLS en su ayuda para administradores.

MTA-STS (Mail Transfer Agent Strict Transport Security) está definido en el RFC 8461, publicado en septiembre de 2018. El estándar permite que el dominio receptor publique una política que indica si los remitentes deben rechazar la entrega a hosts MX que no ofrezcan TLS con un certificado de servidor de confianza. La idea es la misma que HSTS en la web: tras conocer la política, el remitente la recuerda y no acepta una conexión degradada.

El NCSC británico resume el beneficio así: MTA-STS cubre vulnerabilidades que permiten redirigir conexiones entrantes o enviar el correo en texto claro. Por eso se recomienda a cualquier organización que reciba correo sensible: facturas, contratos, restablecimiento de contraseñas o respuestas de clientes.

Qué es MTA-STS y qué problema resuelve

Qué no hace MTA-STS

Conviene tener claras sus fronteras para no esperar lo que no da:

Solo protege el correo entrante. Según la guía del Gobierno británico sobre MTA-STS y TLS-RPT, la protección de lo que tú envías depende de que el servidor receptor tenga su propia política.
No sustituye a SPF, DKIM ni DMARC. Esos protocolos autentican quién envía; MTA-STS protege el canal por el que viaja el mensaje.
Depende de un primer descubrimiento por DNS. El propio RFC advierte de que quien pueda bloquear o manipular respuestas DNS puede intentar suprimir el descubrimiento de la política en la primera conexión. La caché del remitente reduce esa ventana, pero no la elimina.

Cómo funciona: registro DNS, política y TLS-RPT

Cuando un servidor quiere enviar un mensaje a tu dominio, hace lo siguiente:

Consulta en DNS el registro TXT _mta-sts.tudominio.com. Si existe, sabe que hay una política.
Descarga el archivo de política por HTTPS desde https://mta-sts.tudominio.com/.well-known/mta-sts.txt, una ruta que fija el RFC 8461.
Comprueba que el MX al que va a conectar figure en la política y que el certificado TLS sea válido.
Si algo falla y la política está en enforce, no entrega el mensaje por esa vía.
Guarda la política en caché durante el tiempo indicado en max_age.

El registro TXT `_mta-sts`

El registro contiene una versión y un identificador único. Un ejemplo con el formato que recoge la documentación de Google Workspace es v=STSv1; id=20190425085700. El identificador debe cambiar con un valor nuevo cada vez que modificas la política, porque es la señal que usan los remitentes para saber que deben descargarla otra vez. Muchos administradores usan una marca de fecha y hora para no repetirlo nunca.

El archivo de política

Es un archivo de texto con pocas líneas. Sus campos principales, según el RFC 8461, son:

Campo	Para qué sirve	Ejemplo
`version`	Versión del protocolo	`STSv1`
`mode`	`testing`, `enforce` o `none`	`testing`
`mx`	Servidores MX autorizados, uno por línea	`mail.tudominio.com`
`max_age`	Segundos que el remitente guarda la política	`86400`

Un ejemplo completo en fase de pruebas sería:

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

Los nombres de mx deben coincidir con los registros MX reales de tu dominio. Si usas Google Workspace o Microsoft 365, utiliza los valores que indique tu proveedor y no los inventes: un MX omitido en modo enforce significa correo rechazado.

TLS-RPT: los informes que te dicen si algo falla

TLS-RPT es el complemento de MTA-STS. Según el GOV.UK sobre TLS Reporting, los servicios de envío remiten informes agregados diarios sobre los problemas que tienen al usar TLS con tu dominio. Se publica como registro TXT en _smtp._tls.tudominio.com con este formato: v=TLSRPTv1; rua=mailto:informes@tudominio.com.

La guía neozelandesa de despliegue indica que TLS Reporting debe estar configurado antes que MTA-STS, para poder ver los fallos desde el primer día. Hazlo en ese orden.

Requisitos previos antes de tocar el DNS

No hace falta ser un experto en redes, pero sí revisar cuatro cosas:

Certificados válidos y vigentes en todos los servidores MX. La guía del Gobierno británico lo señala como requisito, junto con la compatibilidad con TLS 1.2.
TLS 1.2 en tus servidores de correo. Los que no lo soporten no deben incluirse en la política.
Un subdominio mta-sts con certificado HTTPS y un sitio capaz de servir el archivo de política en la ruta .well-known. Sirve un alojamiento estático sencillo.
Acceso a la zona DNS para crear dos registros TXT y, si hace falta, el registro del subdominio.

Si tu correo lo gestiona un proveedor como Google Workspace, comprueba primero qué hace por ti. Google detalla en su ayuda el paso de activar MTA-STS y los informes TLS, incluido el formato del registro y el cambio de identificador al modificar la política.

Configuración paso a paso

Cinco pasos para configurar MTA-STS

1. Publica TLS-RPT

Crea el registro TXT _smtp._tls con una dirección que leas de verdad. Mejor un buzón dedicado o un servicio que procese los informes JSON, porque llegan en formato técnico y en volumen.

2. Crea y aloja el archivo de política

Escribe el archivo con mode: testing, tus MX y un max_age corto. Súbelo a https://mta-sts.tudominio.com/.well-known/mta-sts.txt. Abre la URL en el navegador y comprueba que el certificado no da avisos y que el texto se muestra tal cual.

3. Añade el registro TXT `_mta-sts`

Publica v=STSv1; id= seguido de un identificador único. Espera a que se propague el DNS.

4. Verifica antes de seguir

La guía de Nueva Zelanda propone comprobar el registro y el archivo de política con el MTA-STS Record Lookup de MXToolbox. También sirve cualquier comprobador que valide el TXT y descargue la política. Si algo no cuadra, es más barato corregirlo ahora.

5. Observa los informes en modo testing

En testing los remitentes no bloquean nada, pero te informan de los problemas. El GOV.UK recomienda revisar los informes diarios durante la fase de pruebas. Los fallos típicos son negociación TLS fallida, certificados inválidos o desajustes entre la política y los MX. Dedica unas semanas a esta fase: así ves el tráfico de proveedores grandes y de remitentes menos frecuentes.

De testing a enforce sin perder correo

Los tres modos son testing (solo informes), enforce (aplicación obligatoria) y none (política desactivada). La guía neozelandesa recomienda pasar a enforce solo tras confirmar en los informes que no hay fallos legítimos, y reducir temporalmente el TTL y el max_age para poder revertir con rapidez.

Un plan prudente:

Cambia mode a enforce manteniendo un max_age bajo.
Actualiza el id del registro _mta-sts. Sin cambio de identificador, los remitentes seguirán con la política antigua.
Vigila los informes TLS-RPT los días siguientes y pregunta a usuarios clave si les falta correo esperado.
Cuando todo esté estable, sube max_age a un valor largo.
Si necesitas retroceder, pon mode: none, cambia el id y espera a que caduque la caché.

El Gobierno británico añade una recomendación de sentido común: probar la compatibilidad de MTA-STS con tu infraestructura antes de implementarlo. Eso incluye servidores heredados, pasarelas antispam y servicios de terceros que reciban correo de tu dominio.

Errores frecuentes

Olvidar el cambio de id. Editas la política pero los remitentes no la vuelven a descargar.
Certificado caducado en mta-sts.tudominio.com. La política deja de ser accesible y los remitentes que la tenían en caché pueden tropezar con fallos.
Lista de MX incompleta. Un servidor de respaldo olvidado hará que parte del correo se rechace en enforce.
Saltarse testing. Es la forma más rápida de descubrir un problema a base de correos perdidos.
No leer los informes. Publicar TLS-RPT sin revisar lo que llega es como tener alarma sin escucharla.

MTA-STS, DMARC y la entregabilidad del email en frío

Si haces prospección por email, tu reputación depende sobre todo de la autenticación de lo que envías: SPF, DKIM y DMARC. MTA-STS no mejora por sí mismo que tus mensajes lleguen a la bandeja de entrada, porque protege el correo que recibe tu dominio. Pero tiene dos usos prácticos en una operación de outbound:

Tus respuestas son datos de negocio. Los prospectos contestan a tus dominios de envío, y esas respuestas contienen nombres, precios y condiciones. Cifrar ese tramo reduce el riesgo de que alguien las lea en tránsito.
Es una señal de madurez técnica. Si gestionas muchos dominios, tener una base consistente (autenticación, TLS, informes) facilita detectar anomalías antes de que se conviertan en bloqueos.

El orden de prioridades, si empiezas de cero, sería: SPF y DKIM, después DMARC y, cuando eso esté estable, MTA-STS y TLS-RPT. Para el primer paso tienes nuestra guía de configuración de DMARC paso a paso, y para entender qué informes leer, la de DMARC para email. Si además quieres mostrar tu logo en la bandeja, mira cómo configurar BIMI, que exige una política DMARC estricta.

Y si tus envíos empiezan a fallar con errores temporales de servidores receptores, nuestro artículo sobre el bloqueo temporal SMTP te ayuda a identificar si la causa es de reputación, de volumen o de configuración.

Nuestra perspectiva

Cuando acompañamos a equipos de ventas y agencias que envían desde muchas bandejas, vemos el mismo patrón: la gente corre a calentar cuentas y a escalar volumen, y deja la base técnica para después. La autenticación y el transporte seguro no hacen que un mal mensaje sea bueno, pero sí evitan que un buen mensaje se pierda por un descuido de configuración.

Nuestro enfoque en PlusVibe es separar lo que puede fallar: infraestructura de envío privada, warm-up gestionado y monitoreo de entregabilidad, para que sepas si el problema está en el dominio, en la IP o en el contenido. MTA-STS encaja en esa lógica de capas. Es un trabajo de una tarde que se hace una vez, se vigila con informes y deja tus respuestas mejor protegidas.

Nuestra recomendación: no lo trates como un extra decorativo. Aplícalo a los dominios donde recibes respuestas de clientes, empieza en testing y apóyate en una plataforma que te dé visibilidad del resto de la cadena.

Yaro

Cómo te ayuda PlusVibe con la entregabilidad

MTA-STS cuida el correo que entra. Para el que sale, en PlusVibe trabajamos con warm-up privado, infraestructura de envío aislada, rotación de bandejas y monitoreo de entregabilidad, pensados para reducir la colocación en spam y los rebotes. Puedes ver cómo lo planteamos en nuestra página de entregabilidad y empezar con la prueba gratuita desde los planes de PlusVibe, donde los planes Starter, Growth y Scale cuestan 19 $, 39 $ y 89 $ al mes respectivamente.

Plusvibe

Si gestionas dominios para varios clientes, también encontrarás ahí las opciones para agencias y los servicios de configuración de correo gestionada.

Preguntas frecuentes

¿MTA-STS es obligatorio?

No es obligatorio, pero sí recomendable si recibes correo con información sensible. Sin él, tu dominio depende de STARTTLS oportunista, que un atacante en medio puede degradar sin que nadie lo note. Se puede desplegar de forma gradual, empezando en modo testing.

¿Qué diferencia hay entre MTA-STS y STARTTLS?

STARTTLS es el mecanismo que permite cifrar una conexión SMTP, pero es oportunista: si falla, el correo viaja en claro. MTA-STS añade una política que obliga al remitente a exigir TLS válido o a no entregar. Se complementan, no compiten.

¿Puedo usar MTA-STS y DANE a la vez?

Sí. Son mecanismos distintos con el mismo objetivo y están pensados para no interferir entre sí, de modo que puedes desplegar ambos si tu DNS admite DNSSEC. MTA-STS tiene la ventaja de no requerirlo, aunque por eso mismo depende más del primer descubrimiento por DNS.

¿Cuánto tiempo debo dejar la política en testing?

Las guías oficiales no fijan un plazo único. Lo importante es revisar los informes TLS-RPT diarios hasta confirmar que no hay fallos legítimos. Muchos administradores esperan varias semanas para cubrir remitentes ocasionales antes de pasar a enforce.

¿Protege MTA-STS el correo que yo envío?

No. Protege el correo que recibe tu dominio. Para tus envíos, la protección depende de que el dominio del destinatario publique su propia política MTA-STS y de que tu servidor de salida respete TLS.