MTA-STS: la guía completa para proteger el transporte de tus emails

Q: ¿Cuál es la diferencia entre los modos testing y enforce?

En modo testing , los servidores emisores intentan la conexión TLS y notifican los fallos vía TLS-RPT, pero entregan igualmente el mensaje. En modo enforce , los servidores rechazan entregar el mensaje si el TLS falla. Empieza siempre por testing para identificar los problemas antes de pasar a enforce .

Por CaptainDNS
Publicado el 6 de febrero de 2026

MTA-STS: proteger el transporte de email con cifrado TLS obligatorio

TL;DR

MTA-STS (RFC 8461) fuerza el cifrado TLS en los emails entrantes e impide los ataques de tipo downgrade y man-in-the-middle sobre SMTP
Dos componentes a desplegar: un registro DNS TXT _mta-sts y un archivo de política alojado en HTTPS en mta-sts.captaindns.com/.well-known/mta-sts.txt
Tres modos disponibles: none (desactivado), testing (monitorización vía TLS-RPT) y enforce (rechazo si el cifrado TLS falla)
Siempre empezar por el modo testing y configurar TLS-RPT para recibir los informes de fallos antes de pasar a enforce

Tus emails transitan cada día entre servidores SMTP. Pero, ¿sabes si esos intercambios están realmente cifrados? Por defecto, SMTP utiliza STARTTLS de manera oportunista: si el servidor remoto no responde al cifrado, el mensaje se envía en texto plano. Un atacante posicionado en la red puede forzar este comportamiento e interceptar tus comunicaciones.

MTA-STS (Mail Transfer Agent Strict Transport Security) resuelve este problema. Definido en la RFC 8461, este estándar permite a un dominio declarar públicamente que exige el cifrado TLS para recibir emails. Los servidores emisores que respetan MTA-STS rechazarán enviar un mensaje si la conexión TLS falla.

Esta guía te explica cómo funciona MTA-STS, cuáles son sus componentes, cómo desplegarlo paso a paso, y por qué se ha convertido en un complemento indispensable de DMARC, SPF y DKIM en el stack de seguridad del email.

¿Qué es MTA-STS? (RFC 8461)

MTA-STS, Mail Transfer Agent Strict Transport Security, es un mecanismo que permite al propietario de un dominio publicar una política de seguridad del transporte para sus servidores de recepción de email (MX). Esta política indica a los servidores emisores que deben:

Negociar una conexión TLS válida antes de enviar un email
Verificar el certificado del servidor destinatario (nombre de host, cadena de confianza, expiración)
Rechazar el envío si el cifrado TLS falla (en modo enforce)

¿Por qué STARTTLS no es suficiente?

STARTTLS es el mecanismo estándar para cifrar las conexiones SMTP. Pero presenta dos fallos fundamentales:

Ataque downgrade: un atacante puede eliminar el comando STARTTLS de la respuesta del servidor, forzando el envío en texto plano. El servidor emisor no sabe que el cifrado estaba disponible.
Sin validación de certificado: aunque STARTTLS se negocie, SMTP no verifica la identidad del servidor destinatario por defecto. Un servidor falso con un certificado autofirmado puede interceptar los mensajes.

MTA-STS corrige estos dos problemas: la política, obtenida vía HTTPS (canal separado y autenticado), impone el cifrado TLS y la validación del certificado.

Esquema del funcionamiento de MTA-STS: el servidor emisor verifica la política antes de enviar

Los dos componentes de MTA-STS

MTA-STS se basa en dos elementos que funcionan juntos.

El registro DNS TXT `_mta-sts`

Un registro TXT publicado en tu zona DNS en _mta-sts.captaindns.com:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Tag	Obligatorio	Descripción
`v`	Sí	Versión del protocolo, siempre `STSv1`
`id`	Sí	Identificador único de la política, debe cambiarse en cada actualización

El campo id sirve como señal de actualización. Cuando un servidor emisor detecta un cambio de id, vuelve a descargar la política. Utiliza una marca de tiempo (ej.: 20260205120000) o un número incremental.

El archivo de política mta-sts.txt

Un archivo de texto alojado en la URL exacta https://mta-sts.captaindns.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 604800

Directiva	Obligatorio	Descripción
`version`	Sí	Siempre `STSv1`
`mode`	Sí	`none`, `testing` o `enforce`
`mx`	Sí	Patrón(es) MX autorizados (uno por línea, wildcards permitidos como `*.captaindns.com`)
`max_age`	Sí	Duración de la caché en segundos (máx. 31 557 600 = 1 año)

Alojamiento HTTPS obligatorio

El archivo de política debe servirse vía HTTPS con un certificado TLS válido en el subdominio mta-sts. Este es un elemento fundamental de la seguridad de MTA-STS: a diferencia del DNS (que puede ser suplantado sin DNSSEC), HTTPS garantiza la autenticidad de la política mediante la validación del certificado.

Los 3 modos de MTA-STS: testing, enforce, none

Modo testing: monitorizar sin bloquear

mode: testing

En modo testing, los servidores emisores intentan negociar TLS y notifican los fallos vía TLS-RPT (RFC 8460), pero entregan igualmente el mensaje si el cifrado falla. Es el modo de inicio recomendado.

Modo enforce: cifrado o rechazo

mode: enforce

En modo enforce, los servidores emisores rechazan entregar el mensaje si la conexión TLS falla o si el certificado no es válido. Es el modo objetivo para una protección completa.

Modo none: desactivación

mode: none

El modo none indica que MTA-STS está desactivado. Úsalo para desactivar correctamente una política existente (los servidores emisores que tienen una política en caché deben esperar a que expire max_age).

¿Qué valor de max_age elegir?

Fase de despliegue	max_age recomendado	Duración
Inicio (testing)	86 400	1 día
Estabilización	604 800	7 días
Producción (enforce)	2 592 000 a 31 557 600	30 días a 1 año

Un max_age corto en la fase de pruebas permite corregir errores rápidamente. Una vez en enforce, un max_age largo reduce la frecuencia de re-descarga y refuerza la protección contra ataques DNS temporales.

Desplegar MTA-STS paso a paso

Paso 1: Verificar tus MX y certificados TLS

Antes de desplegar MTA-STS, asegúrate de que todos tus servidores MX disponen de un certificado TLS válido (TLS 1.2 como mínimo) con un nombre de host correspondiente. Un certificado expirado o mal configurado provocará rechazos en modo enforce.

Paso 2: Crear el archivo de política

Crea el archivo mta-sts.txt con tus servidores MX. Puedes usar el generador MTA-STS de CaptainDNS para crearlo automáticamente:

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 86400

Paso 3: Alojar la política en la URL .well-known

Publica el archivo en la URL exacta:

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

El subdominio mta-sts debe resolver hacia un servidor web HTTPS con un certificado válido. Opciones de alojamiento habituales:

Cloudflare Pages / Cloudflare Workers: gratuito, HTTPS automático
GitHub Pages: gratuito, certificado Let's Encrypt
Azure Static Web Apps: integración con Microsoft 365
Servidor web existente: Apache, Nginx con Let's Encrypt

El Content-Type de la respuesta debe ser text/plain.

Paso 4: Publicar el registro DNS TXT

Añade en tu zona DNS:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Paso 5: Validar tu configuración

Utiliza el verificador MTA-STS de CaptainDNS para comprobar que todo está en su sitio: registro DNS, archivo de política, certificado TLS, correspondencia MX.

Checklist de despliegue de MTA-STS en 5 pasos

MTA-STS vs DANE vs STARTTLS

Tres mecanismos coexisten para proteger el transporte SMTP. Estas son sus diferencias:

Criterio	STARTTLS solo	MTA-STS	DANE
Protección	Cifrado oportunista	Cifrado obligatorio	Cifrado obligatorio
Validación del certificado	No	Sí (vía HTTPS/CA)	Sí (vía DNSSEC/TLSA)
Resiste ataques downgrade	No	Sí	Sí
Prerrequisitos	Ninguno	HTTPS en subdominio `mta-sts`	DNSSEC en la zona DNS
Complejidad de despliegue	Baja	Media	Alta
Adopción	Universal	Creciente (Google, Microsoft)	Limitada (prerrequisito DNSSEC)
RFC	RFC 3207	RFC 8461	RFC 7671

En la práctica: MTA-STS es la opción pragmática. DANE ofrece una seguridad teóricamente superior (sin dependencia de las CA) pero requiere DNSSEC, aún poco desplegado. Ambos enfoques son complementarios y pueden coexistir.

TLS-RPT: monitorizar tu despliegue MTA-STS

TLS-RPT (SMTP TLS Reporting, RFC 8460) es el compañero indispensable de MTA-STS. Permite recibir informes JSON diarios que describen los éxitos y fallos de negociación TLS hacia tu dominio.

Para activar TLS-RPT, publica un registro DNS:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Estos informes son esenciales en modo testing: te permiten identificar los problemas (certificados expirados, MX no cubiertos, servidores incompatibles con TLS 1.2) antes de pasar al modo enforce.

Plan de acción recomendado

Verifica tus certificados TLS: todos tus servidores MX deben tener un certificado válido con TLS 1.2+
Despliega en modo testing: crea la política y el registro DNS con mode: testing y max_age: 86400
Activa TLS-RPT: publica el registro _smtp._tls para recibir los informes de fallos
Monitoriza durante 2-4 semanas: analiza los informes TLS-RPT y corrige los problemas identificados
Pasa a modo enforce: una vez que los informes estén limpios, cambia a mode: enforce y aumenta max_age

Verifica tu configuración MTA-STS ahora: Usa nuestro verificador MTA-STS para analizar tu dominio en segundos.

FAQ

¿Qué es MTA-STS y por qué lo necesito?

MTA-STS (Mail Transfer Agent Strict Transport Security) es un estándar de internet (RFC 8461) que permite a un dominio declarar que exige el cifrado TLS para recibir emails. Sin MTA-STS, las conexiones SMTP utilizan STARTTLS de manera oportunista, lo que las hace vulnerables a ataques downgrade y man-in-the-middle. MTA-STS garantiza que tus emails entrantes estén siempre cifrados en tránsito.

¿Es obligatorio MTA-STS para la seguridad del email?

MTA-STS aún no es obligatorio en términos regulatorios, pero se recomienda encarecidamente. Google y Microsoft lo han activado en sus dominios y verifican la presencia de MTA-STS en los dominios que contactan. Para las organizaciones sujetas a requisitos de cumplimiento (RGPD, PCI-DSS), MTA-STS refuerza la postura de seguridad del transporte de email.

¿Cuál es la diferencia entre los modos testing y enforce?

En modo testing, los servidores emisores intentan la conexión TLS y notifican los fallos vía TLS-RPT, pero entregan igualmente el mensaje. En modo enforce, los servidores rechazan entregar el mensaje si el TLS falla. Empieza siempre por testing para identificar los problemas antes de pasar a enforce.

¿Cómo se compara MTA-STS con DANE?

MTA-STS utiliza HTTPS y las autoridades de certificación (CA) para autenticar la política, mientras que DANE utiliza DNSSEC y los registros TLSA. DANE ofrece una seguridad superior (sin dependencia de las CA) pero requiere DNSSEC, aún poco desplegado. MTA-STS es más sencillo de desplegar y tiene mayor adopción. Ambos mecanismos son complementarios.

¿Es necesario configurar también TLS-RPT con MTA-STS?

Sí, muy recomendado. TLS-RPT (RFC 8460) te envía informes diarios sobre los éxitos y fallos de negociación TLS hacia tu dominio. Sin TLS-RPT, no tienes visibilidad sobre los problemas de tu despliegue MTA-STS. Publica un registro _smtp._tls con una dirección de recepción.

¿Cómo configurar MTA-STS para Microsoft 365?

Para Microsoft 365, utiliza el patrón MX *.mail.protection.outlook.com en tu política MTA-STS. Aloja el archivo de política en Azure Static Web Apps, Cloudflare Pages o cualquier servidor HTTPS. Microsoft soporta MTA-STS tanto en emisión (verifica la política de tus destinatarios) como en recepción (puedes publicar una política para tu dominio M365).

¿Cómo configurar MTA-STS para Google Workspace?

Para Google Workspace, incluye los siguientes patrones MX en tu política: aspmx.l.google.com, *.google.com y *.googlemail.com. Google verifica activamente las políticas MTA-STS de los dominios que contacta y publica informes TLS-RPT. Aloja el archivo de política en un servidor HTTPS con un certificado válido para el subdominio mta-sts.

¿Qué pasa si el archivo de política no es accesible?

Si el archivo mta-sts.txt no es accesible (error HTTP, timeout, certificado inválido), el servidor emisor no puede aplicar la política. En ausencia de una política en caché, vuelve al comportamiento STARTTLS oportunista estándar. Si hay una política en caché (no expirada según max_age), esta sigue aplicándose. Por eso un max_age suficientemente largo protege contra interrupciones temporales.

Glosario

MTA-STS: Mail Transfer Agent Strict Transport Security. Estándar RFC 8461 que impone el cifrado TLS para la recepción de emails.
STARTTLS: Extensión SMTP que permite pasar de una conexión en texto plano a una conexión cifrada con TLS. Oportunista por defecto.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de informes sobre los éxitos y fallos de negociación TLS.
DANE: DNS-based Authentication of Named Entities (RFC 7671). Utiliza DNSSEC y los registros TLSA para validar los certificados TLS.
Ataque downgrade: Técnica en la que un atacante fuerza una conexión a utilizar un protocolo menos seguro (ej.: eliminar STARTTLS para forzar el envío en texto plano).
max_age: Directiva de la política MTA-STS que indica la duración del almacenamiento en caché en segundos.

Guias de MTA-STS relacionadas

Configurar MTA-STS para Microsoft 365 y Google Workspace (próximamente)
¿MTA-STS no funciona? Guía completa de solución de problemas (próximamente)