MTA-STS, qué es y para qué sirve

Cómo desplegar MTA-STS

El despliegue consta de tres elementos:

1. El registro DNS. Se publica un TXT en _mta-sts.ejemplo.es que contiene un identificador de versión de la política (v=STSv1; id=...). Este identificador cambia con cada actualización de la política, para señalar a los remitentes que deben volver a descargarla.

2. El fichero de política. Alojado por HTTPS en https://mta-sts.ejemplo.es/.well-known/mta-sts.txt, precisa el modo de aplicación (testing, enforce) y la lista de servidores MX autorizados a recibir el correo del dominio por TLS.

3. El modo de arranque: testing antes que enforce. Exactamente como para DMARC, la buena práctica es empezar en modo testing, que registra los fallos de conexión TLS sin bloquear la entrega, antes de pasar a enforce una vez validada la configuración. Ahí es donde interviene el protocolo complementario descrito más abajo.

TLS-RPT: el retorno de experiencia de MTA-STS

MTA-STS solo define qué exigir, pero no lo que pasa realmente en el lado de los remitentes que intentan contactar con el dominio. Ese es el papel de TLS-RPT (SMTP TLS Reporting), un protocolo compañero que hace por MTA-STS lo que los informes agregados hacen por DMARC: devuelve informes diarios que detallan los éxitos y los fallos de conexión TLS observados por los remitentes que escriben al dominio. Sin TLS-RPT, pasar MTA-STS a enforce equivale a endurecer una política DMARC sin leer nunca los informes — una apuesta a ciegas, donde nunca se sabe si un remitente legítimo ha sido bloqueado por no poder establecer TLS. El protocolo se detalla en TLS-RPT explicado; ambos se despliegan casi siempre juntos.

El paralelismo con DMARC

El parecido metodológico con DMARC no es casualidad — los dos protocolos responden al mismo problema estructural (un mecanismo de seguridad opcional, esquivable silenciosamente) con la misma solución (publicar una política explícita, y un bucle de informes para validarla antes de endurecer). Para quien ya ha llevado a cabo un despliegue DMARC mediante la secuencia none → quarantine → reject, la secuencia testing → enforce de MTA-STS, acompañada de TLS-RPT, resulta familiar. El principio de prudencia es idéntico: no hay que bascular a aplicación estricta hasta que los informes se hayan demostrado limpios.

¿Protege MTA-STS contra la suplantación de identidad?

No, y es una confusión frecuente que conviene disipar. MTA-STS protege el transporte — la confidencialidad y la integridad del mensaje durante su trayecto entre servidores. No dice nada sobre la identidad del remitente, que sigue siendo enteramente competencia de SPF, DKIM y DMARC. Un mensaje perfectamente cifrado en tránsito puede perfectamente ser un correo suplantado; un mensaje perfectamente autenticado puede perfectamente haber viajado en claro. Las dos capas son complementarias, no sustituibles — un despliegue de correo serio en 2026 cubre las dos, no la una en detrimento de la otra, porque tratar MTA-STS como un reemplazo de DMARC (o al revés) equivale a confundir el continente y el contenido.

Quién se beneficia más de MTA-STS

El protocolo tiene un valor especialmente elevado para las organizaciones que intercambian información sensible por correo: sector financiero, sanidad, jurídico, administraciones. Una degradación TLS explotada sobre este tipo de tráfico expone datos cuya confidencialidad es a menudo una obligación reglamentaria, no solo una buena práctica — basta pensar en los extractos bancarios, los historiales médicos o las piezas procesales intercambiadas por correo, donde una interceptación en claro constituye potencialmente un incidente que declarar. El tema cruza directamente con los asuntos de conformidad que afectan a los sectores más regulados — ver DMARC para los bancos para un ejemplo de sector donde este tipo de exigencia de transporte cifrado se añade naturalmente a las obligaciones de autenticación. Una empresa que debe demostrar su diligencia en materia de protección de datos de correo tiene todo el interés en documentar MTA-STS al mismo nivel que DMARC en su expediente de conformidad, en lugar de tratarlo como un detalle puramente técnico sin valor probatorio.

El papel del fichero de política servido por HTTPS

Un detalle arquitectónico merece explicarse, porque revela por qué MTA-STS es más robusto que STARTTLS solo. El fichero de política no se almacena en el DNS mismo (a diferencia de DMARC o SPF) — se aloja por HTTPS, en un subdominio dedicado mta-sts.ejemplo.es. ¿Por qué esta arquitectura en dos tiempos, un registro DNS y un fichero web?

La respuesta está en el tamaño y la naturaleza de la información. Un registro DNS TXT está limitado en tamaño y poco adaptado a contener una lista de servidores MX y reglas de modo. En cambio, un registro DNS ligero (solo un identificador de versión) acoplado a un fichero HTTPS completo (protegido por los certificados TLS estándar de la web, ellos mismos verificados) da lo mejor de los dos mundos: una notificación ligera y rápida de consultar en el DNS, y un contenido detallado protegido por la infraestructura de confianza HTTPS existente. Un atacante que quisiera falsificar la política tendría, por tanto, que comprometer a la vez el DNS y obtener un certificado TLS válido para el subdominio — una barrera mucho más alta que un registro DNS solo.

La puesta en caché en el lado del remitente

Otro mecanismo que conviene conocer: los remitentes que respetan MTA-STS no vuelven a descargar el fichero de política con cada correo enviado — lo ponen en caché, generalmente durante un tiempo definido en el propio fichero (a menudo varios días). Es por esta razón que el identificador de versión (id=) en el registro DNS es esencial: es la señal que indica a un remitente en caché que existe una nueva versión y debe volver a descargarse. Basta con cambiar la política (por ejemplo, añadiendo un nuevo servidor MX) sin cambiar ese identificador para que algunos remitentes sigan aplicando la versión antigua durante toda la duración de su caché — una trampa clásica en una migración de infraestructura de correo.

Mantener vivo el punto de publicación

Desplegar MTA-STS crea también una dependencia operativa que se olvida fácilmente: el punto HTTPS que sirve el fichero de política debe permanecer en línea, y su certificado TLS válido. A diferencia de un registro DNS, que duerme tranquilamente una vez publicado, un punto web puede pudrirse — un certificado que expira sin que nadie se dé cuenta, un servidor dado de baja durante una migración, una redirección añadida sin saber que la URL de política debe responder directamente. Cuando la política ya no puede descargarse, los remitentes que tienen una copia en caché siguen aplicándola hasta que expira, y los nuevos ya no pueden simplemente descubrir las exigencias del dominio — una erosión silenciosa de la protección, más que una avería visible. El remedio es procedimental, no técnico: el host de política debe estar bajo la misma supervisión de renovación de certificado y de disponibilidad que cualquier servicio de producción.

Límites que conviene conocer

MTA-STS solo protege el trayecto entre servidores de correo (el tramo SMTP de servidor a servidor); no cubre la conexión entre un cliente de correo y su propio servidor de envío (generalmente ya cifrada por otros medios), ni el contenido una vez almacenado en un buzón. Es una protección centrada en un eslabón preciso de la cadena — valiosa, pero no una solución de cifrado de extremo a extremo. Para ese nivel de garantía, harían falta mecanismos distintos como S/MIME o PGP, que cifran el contenido mismo en lugar del solo transporte entre servidores.

En resumen

MTA-STS cierra una brecha estructural de SMTP — la degradación silenciosa a texto claro — reemplazando una negociación opcional por una política publicada y verificable. Asociado a TLS-RPT para la visibilidad, y desplegado con la misma prudencia metodológica que un despliegue DMARC (testing antes que enforce), es una capa de seguridad que completa, sin reemplazarla, la autenticación aportada por SPF, DKIM y DMARC.

Para verificar el estado de la autenticación de correo de base antes de añadir esta capa de transporte, basta con pasar un dominio por el analizador DMARC gratuito — la identidad primero, el cifrado del trayecto después, en ese orden de prioridad. Una vez publicada la política de transporte, el analizador MTA-STS gratuito confirma su modo y su correcta recuperación.