SPF, DKIM y DMARC demuestran quién envió un mensaje. MTA-STS y TLS-RPT protegen el mensaje mientras está en movimiento: se aseguran de que la conexión que transporta tu correo esté genuinamente cifrada y te avisan cuando no lo está. MTA-STS (SMTP MTA Strict Transport Security, definido en el RFC 8461) permite que un dominio declare que el correo dirigido a sus servidores debe llegar por TLS con un certificado válido. TLS-RPT (SMTP TLS Reporting, RFC 8460) pide a los servidores emisores que presenten un informe diario sobre si ese cifrado tuvo éxito o falló. Ninguno autentica el contenido: juntos cierran una brecha distinta, la que el TLS oportunista sin más deja abierta de par en par. Esto es lo que hace cada uno y cómo desplegarlos sin romper tu correo entrante.
La respuesta rápida#
MTA-STS es una política que publicas para que los servidores de correo de otras personas
cifren el correo que te envían a ti. Tiene dos piezas móviles: un registro DNS TXT en
_mta-sts.yourdomain.com que señala que la política existe, y un archivo de política alojado
por HTTPS en https://mta-sts.yourdomain.com/.well-known/mta-sts.txt que enumera tus
nombres de host MX, un modo (none, testing o enforce) y durante cuánto tiempo cachearlo.
TLS-RPT es un segundo registro TXT en _smtp._tls.yourdomain.com que designa una dirección
que recibirá los informes diarios sobre cómo fueron esas conexiones TLS. El despliegue seguro
imita al de DMARC: publica primero en modo testing, lee los informes de TLS-RPT hasta estar
seguro de que todas las conexiones negocian TLS sin problemas, y luego cambia a enforce.
La brecha que cierra MTA-STS#
El SMTP moderno ya cifra la mayor parte del correo en tránsito mediante STARTTLS: el servidor emisor pregunta «¿admites TLS?», el receptor dice que sí y ambos negocian un canal cifrado. El problema es que este saludo es oportunista y no autenticado. Si cualquiera de los dos extremos no ofrece TLS, el correo vuelve a texto plano en lugar de fallar. Peor aún, un atacante situado entre los dos servidores puede eliminar la oferta de STARTTLS de la conversación —un ataque de degradación— y el servidor emisor, al no ver TLS ofrecido, entrega el mensaje sin cifrar sin hacer ruido. El certificado tampoco se verifica, así que un intermediario puede presentar el suyo propio e interceptar la conexión.
MTA-STS corrige ambas debilidades. Al publicar una política, les dices a los remitentes que la cumplen: el correo para este dominio debe ir por TLS, el servidor receptor debe presentar un certificado que sea válido y coincida con uno de mis nombres de host MX enumerados, y si no se cumplen esas condiciones, no lo entregues: aplaza y reintenta en lugar de volver a texto plano. Como la política se obtiene por HTTPS, su propio certificado actúa como ancla de confianza, y eso es lo que impide que un atacante la falsifique o la elimine. El resultado es que un fisgón pasivo o un atacante de degradación activo ya no pueden forzar tu correo entrante a viajar sin cifrar.
Qué aporta TLS-RPT#
MTA-STS por sí solo es imposición sin visibilidad: estarías diciendo a los remitentes que rechacen las conexiones inseguras, pero no tendrías forma de ver con qué frecuencia ocurre eso en realidad ni qué remitentes están fallando. TLS-RPT es el canal de retroalimentación. Funciona exactamente como los informes agregados de DMARC y encaja de forma natural con el hábito de leer los informes de DMARC.
Cuando publicas un registro de TLS-RPT, los remitentes participantes te envían un informe diario
en JSON que resume cada sesión TLS que abrieron hacia tus hosts MX: cuántas tuvieron éxito,
cuántas fallaron y —lo más importante— por qué fallaron. Un informe podría mostrar un
certificado caducado en uno de tus servidores MX, una discrepancia de nombre de host, una
negociación de STARTTLS que se interrumpió o un problema al obtener la política. Esa es
exactamente la información que necesitas antes de atreverte a poner MTA-STS en enforce,
porque un fallo en modo enforce significa correo entrante aplazado o rebotado. TLS-RPT es lo
que hace que el despliegue sea seguro en lugar de un salto de fe.
Configurar MTA-STS: el registro DNS y el archivo de política#
MTA-STS necesita tres cosas en su sitio: un registro DNS, un archivo de política y un subdominio para alojar el archivo por HTTPS.
1. El registro DNS TXT. Publica un registro TXT en _mta-sts.yourdomain.com. Su cometido
es pequeño: anuncia que existe una política y lleva un id que los remitentes usan para
darse cuenta de cuándo cambia la política.
_mta-sts.example.com. TXT "v=STSv1; id=20260725090000"
El id es una cadena arbitraria de hasta 32 caracteres alfanuméricos. Una marca de tiempo es
la convención habitual. La única regla que importa: siempre que edites el archivo de política,
cambia el id. Los remitentes cachean tu política, y un id nuevo es la señal que les
indica que vuelvan a obtenerla. Si olvidas incrementarlo, tus cambios pueden pasar
desapercibidos durante tanto tiempo como dure tu max_age.
2. El archivo de política. Aloja un archivo de texto plano en la ruta fija
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Enumera el modo, cada nombre de host
MX válido y una vida útil de caché:
version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400
Cada línea mx debe coincidir con un nombre de host de los registros MX de tu dominio, y la
forma con comodín (*.example.com) coincide con una única etiqueta situada más a la izquierda.
Cada host MX que enumeres tiene que servir un certificado que sea actualmente válido, encadene
hasta una CA pública y coincida con su nombre de host; de lo contrario, un remitente en modo
enforce lo rechazará. El max_age es la vida útil de la caché en segundos; el RFC 8461
permite valores de hasta 31557600 (alrededor de un año). Mantenlo corto (un día más o menos)
mientras estés en pruebas para que los cambios se propaguen rápido, y luego súbelo una vez que
tengas confianza en enforce: receptores como Google recomiendan un max_age largo en
producción, aunque el valor exacto lo eliges tú.
3. El subdominio mta-sts por HTTPS. El archivo de política debe estar accesible por
HTTPS en el subdominio mta-sts con un certificado válido para
mta-sts.yourdomain.com. En la práctica, apuntas ese subdominio (mediante A/AAAA o CNAME)
a lo que sirva el archivo —un pequeño host de estáticos o un CDN es lo habitual— y te aseguras
de que responda con Content-Type: text/plain. Muchos proveedores de DNS y de alojamiento
ofrecen ya una opción de MTA-STS gestionado que se encarga del archivo y del certificado por ti.
Configurar TLS-RPT#
TLS-RPT es con diferencia el más sencillo de los dos: un único registro TXT, sin archivo de política.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
La etiqueta rua designa a dónde van los informes. Acepta una dirección mailto:, un endpoint
https: que recibe los informes enviados por POST, o una lista separada por comas de ambos. El
JSON de TLS-RPT en bruto es denso, así que la mayoría de los equipos apuntan rua a un servicio
de monitorización que analiza los informes y los convierte en un panel legible, del mismo modo
que los informes de DMARC suelen fluir hacia un analizador en lugar de a una bandeja de entrada
humana. Puedes publicar TLS-RPT por su cuenta, y merece la pena hacerlo antes de MTA-STS: te
da una imagen del estado actual de tu TLS sin ningún riesgo para el flujo de correo.
Desplegar MTA-STS y TLS-RPT de forma segura#
El orden de las operaciones para MTA-STS y TLS-RPT importa más que los propios registros: hazlo mal y puedes aplazar tu propio correo entrante. Sigue la misma disciplina de monitorizar-y-luego-imponer que rige un buen despliegue de DMARC.
1. Publica TLS-RPT primero. Sin ninguna política MTA-STS todavía, los informes simplemente te dicen cuánto de tu correo entrante ya usa TLS y si alguno de tus certificados MX está mal configurado. Corrige aquí cualquier cosa obvia.
2. Publica MTA-STS en modo testing. Añade el registro DNS y el archivo de política con
mode: testing. En este modo los remitentes evalúan tu política e informan de los fallos por
TLS-RPT, pero siguen entregando el correo con normalidad. Nada de tu flujo de correo cambia:
solo estás recopilando datos. Déjalo aquí el tiempo suficiente para capturar un ciclo completo
de tus corresponsales habituales, idealmente un par de semanas.
3. Lee los informes de TLS-RPT y corrige los fallos. Vigila los problemas de certificados,
las discrepancias de nombre de host y los hosts MX que olvidaste enumerar. Cada fallo en modo
testing es un fallo que habrías provocado en modo enforce. Sigue iterando sobre tus
certificados y tu archivo de política hasta que los informes salgan limpios.
4. Cambia a mode: enforce. Una vez que los fallos se hayan silenciado, edita el archivo
de política a enforce e incrementa el id en el registro DNS para que los remitentes lo
vuelvan a obtener. A partir de este punto, los remitentes que cumplen la política se negarán a
entregar por una conexión no autenticada o degradada. Considera subir ahora el max_age para
una protección más fuerte frente a los intentos de degradación.
Dónde encaja esto junto a SPF, DKIM y DMARC#
Merece la pena ser preciso sobre lo que MTA-STS y TLS-RPT hacen y no hacen, porque es fácil archivarlos bajo «entregabilidad» y esperar de ellos lo que no toca.
SPF, DKIM y DMARC responden a ¿este mensaje procede realmente de quien dice proceder?: autentican identidad y contenido. MTA-STS y TLS-RPT responden a una pregunta distinta: ¿estaba realmente cifrada y verificada la conexión que transportó este mensaje?: protegen la confidencialidad en tránsito. Las dos capas son complementarias e independientes. Un mensaje puede pasar DMARC mientras viaja en texto plano, y puede viajar por TLS impuesto mientras falla DMARC. Una configuración completa quiere ambas.
Dos matices honestos. Primero, MTA-STS y TLS-RPT no forman parte de los requisitos para remitentes masivos de Google y Yahoo que entraron en vigor en 2024: esos obligan a SPF, DKIM, DMARC, la baja con un solo clic y una tasa de spam baja, no a políticas de seguridad del transporte. Dicho esto, los grandes proveedores sí publican y respetan MTA-STS como receptores, de modo que una política que publiques la aplican de verdad Gmail y otros cuando te entregan a ti. Segundo, MTA-STS no es un remedio para la carpeta de spam. Refuerza la seguridad del transporte entrante; no mejora, por sí solo, dónde aterriza tu correo comercial saliente. La ubicación en la bandeja de entrada la sigue decidiendo la reputación del remitente, la interacción y la higiene de la lista, y si tu correo va a spam, los motivos viven en esas señales, no en tu configuración de TLS. Trata a MTA-STS y TLS-RPT como el capítulo de seguridad del transporte de un dominio de envío maduro: merece la pena hacerlo, pero es algo distinto de las palancas de la guía de entregabilidad que de verdad mueven la ubicación en la bandeja de entrada.
Si quieres una analogía, MTA-STS es un primo cercano de DANE, la forma más antigua basada en DNSSEC de imponer TLS en SMTP. Ambos apuntan al mismo problema de degradación; MTA-STS se diseñó para que los dominios sin DNSSEC pudieran obtener igualmente la mayor parte de la protección, usando el sistema de certificados web en su lugar. Si ya usas DANE quizá no necesites MTA-STS, pero los dos pueden coexistir.
Preguntas frecuentes#
¿MTA-STS sustituye a SPF, DKIM o DMARC?#
No: operan en capas distintas y conviene tener ambos. SPF, DKIM y DMARC autentican el remitente y el contenido de un mensaje, demostrando que procede realmente de tu dominio y que no se alteró. MTA-STS y TLS-RPT protegen el transporte: obligan a que la conexión que lleva el mensaje use TLS verificado e informan cuando no lo hace. Un mensaje necesita autenticación y entrega cifrada, así que MTA-STS acompaña a DMARC en lugar de reemplazar ninguna de estas piezas.
¿Google y Yahoo exigen MTA-STS y TLS-RPT?#
No como parte de los requisitos de 2024 para remitentes masivos, que obligan a SPF, DKIM, DMARC, la baja con un solo clic y una tasa de spam inferior al 0,3 %; MTA-STS no está en esa lista. Pero los grandes proveedores publican sus propias políticas MTA-STS y respetan la tuya como receptores, de modo que una política que publiques la aplican de verdad Gmail y otros. Es una buena práctica recomendada para un dominio de envío maduro, aunque no un requisito formal para llegar a la bandeja de entrada.
¿Cuál es la diferencia entre MTA-STS y DANE?#
Ambos imponen TLS en el SMTP entrante y defienden frente a ataques de degradación; se diferencian en cómo establecen la confianza. DANE publica información de certificados en el DNS y se apoya en DNSSEC para que esos registros sean a prueba de manipulaciones. MTA-STS evita el requisito de DNSSEC sirviendo su política por HTTPS y usando el sistema de certificados web habitual como ancla de confianza. MTA-STS suele ser más fácil de desplegar en dominios sin DNSSEC; además, los dos pueden funcionar a la vez.
¿Mejorará MTA-STS mi posicionamiento en la bandeja de entrada?#
No de forma directa. MTA-STS es un control de seguridad del transporte para el correo que entra en tu dominio: no cambia cómo se filtra tu correo comercial saliente. La ubicación en la bandeja de entrada depende de la reputación del remitente, la interacción, las tasas de quejas y la calidad de la lista. Merece la pena configurar MTA-STS por seguridad e integridad, pero si tu correo cae en spam, la solución está en la higiene de la lista y la reputación, no en tu política de TLS.
MTA-STS y TLS-RPT refuerzan las tuberías por las que viaja tu correo, pero la bandeja de entrada se gana con la calidad de la lista. El verificador de correo gratuito detecta dominios muertos y erratas antes de que reboten, y el plan gratuito ejecuta todo el proceso de verificación sobre tu lista, porque un dominio seguro y bien autenticado solo se gana la ubicación cuando la lista que lo respalda está limpia.
