MTA-STS

Esta guía forma parte de nuestra guía de autenticación de correo electrónico. Relacionado: MTA-STS y DKIM vs DMARC.

MTA-STS (SMTP MTA Strict Transport Security) es un estándar que permite a un dominio exigir que el correo entrante se entregue a través de TLS cifrado y autenticado, previniendo los ataques de degradación y de intermediario (man-in-the-middle). TLS-RPT es su estándar complementario de generación de informes, que recopila informes diarios sobre los fallos de TLS en la entrega. MTA-STS protege la capa de transporte, complementando a SPF, DKIM y DMARC, que autentican al remitente en lugar de a la conexión.

El problema que resuelve MTA-STS

Cuando dos servidores de correo intercambian mensajes por SMTP, normalmente negocian el cifrado usando STARTTLS. El inconveniente es que STARTTLS es oportunista: el servidor emisor pregunta si el receptor admite TLS, y si la respuesta es no, recurre silenciosamente al texto plano. Esa pregunta y respuesta ocurren en claro, lo que significa que un atacante situado entre los dos servidores puede eliminar el comando STARTTLS de la conversación. El servidor emisor cree entonces que el receptor no admite TLS y entrega el mensaje sin cifrar, o se conecta a un servidor impostor que presenta un certificado falsificado.

Estos se conocen como ataques de degradación y de intermediario (man-in-the-middle). Como SMTP se diseñó primero para la interoperabilidad y la seguridad más tarde, históricamente no había forma de que un dominio receptor dijera “cifra siempre el correo hacia mí, y niégate a entregarlo si no puedes”. MTA-STS llena exactamente esa brecha. Permite a un dominio publicar una política que declara que el correo entrante debe entregarse a través de TLS, usando un certificado válido que coincida con uno de sus hosts MX publicados. Los servidores emisores que admiten MTA-STS respetan la política y aplazarán o rebotarán un mensaje en lugar de enviarlo en texto claro.

Cómo funciona MTA-STS

MTA-STS se basa en dos piezas que funcionan juntas: un registro TXT DNS que anuncia la política y un archivo de política alojado en HTTPS que la define.

Primero, publica un registro TXT en _mta-sts.yourdomain.com. Este registro señala que existe una política y lleva un ID que cambia cada vez que actualizas la política, para que los servidores emisores sepan cuándo volver a obtenerla.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

Segundo, sirve el archivo de política a través de HTTPS en una ubicación fija y bien conocida: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. El requisito de HTTPS importa porque el certificado de ese host demuestra que la política es auténtica y no ha sido manipulada en tránsito.

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

Las líneas mx listan cada nombre de host autorizado a recibir tu correo, coincidiendo con tus registros MX. max_age indica a los servidores emisores cuánto tiempo deben almacenar en caché la política, en segundos (604800 es una semana). Una caché más larga es más resistente frente a un atacante que pueda manipular brevemente el DNS, por lo que se recomienda un valor de al menos unos días una vez que tengas confianza en tu configuración.

Modo enforce frente a modo de pruebas

El campo mode en el archivo de política controla con qué rigor se aplica la política, y es el dial más importante al desplegar MTA-STS.

Empieza con mode: testing. En modo de pruebas, los servidores emisores evalúan tu política pero nunca bloquean la entrega cuando falla. En su lugar, combinado con TLS-RPT (más abajo), te informan de los fallos. Esto te permite descubrir hosts MX mal configurados, certificados caducados o discrepancias de nombre de host sin perder nunca un mensaje legítimo.

Una vez que tus informes vuelvan limpios durante una o dos semanas, cambia a mode: enforce. Ahora los servidores emisores se negarán a entregar correo que no pueda enviarse a través de TLS autenticado a un host MX listado. Un tercer valor, mode: none, desactiva efectivamente la política y se usa para retirar MTA-STS con elegancia. Pasa siempre de testing a enforce de forma deliberada, nunca a la inversa con prisas.

TLS-RPT: generación de informes

MTA-STS por sí solo no te dice nada sobre cómo va la entrega. TLS-RPT (SMTP TLS Reporting) es el canal de retroalimentación. Publicas un segundo registro TXT en _smtp._tls.yourdomain.com que nombra una dirección que debe recibir los informes agregados.

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

Los servidores emisores participantes te envían un informe JSON diario que resume las sesiones TLS exitosas y fallidas hacia tu dominio, incluyendo el motivo de cada fallo, como un certificado que no validó o una negociación STARTTLS que fue eliminada. Estos informes son lo que hace útil el modo de pruebas, y siguen siendo valiosos en modo enforce como sistema de alerta temprana ante la caducidad de certificados o cambios de MX. Muchos equipos dirigen la dirección rua a un panel de monitorización en lugar de a una bandeja de entrada humana.

Dónde encaja junto a SPF, DKIM y DMARC

Es fácil agrupar MTA-STS con los demás acrónimos, pero resuelve un problema diferente. SPF, DKIM y DMARC autentican al remitente, respondiendo a “¿este mensaje proviene realmente del dominio que dice?”. MTA-STS asegura la conexión, respondiendo a “¿este mensaje se está entregando de forma privada y al servidor correcto?”. Quieres ambos. Un mensaje puede estar perfectamente autenticado y aun así ser interceptado en tránsito, y una conexión perfectamente cifrada puede aun así transportar un mensaje suplantado.

Para el panorama completo de la autenticación del remitente, consulta nuestra guía de autenticación de correo electrónico. MTA-STS se combina de forma natural con esos estándares como una adición a nivel de transporte, y una vez que los tengas implementados, BIMI es otra capa avanzada que vale la pena considerar, ya que te permite mostrar un logotipo de marca verificado en las bandejas de entrada compatibles.

Preguntas frecuentes

¿Qué es MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) es un estándar que permite a un dominio exigir que el correo entrante se entregue a través de TLS cifrado y autenticado. Publica un registro DNS y un archivo de política alojado en HTTPS para que los servidores emisores hagan cumplir el cifrado y se nieguen a recurrir al texto plano, bloqueando los ataques de degradación y de intermediario contra SMTP.

¿Cuál es la diferencia entre MTA-STS y TLS-RPT?

MTA-STS es el estándar de exigencia: define la política que requiere la entrega por TLS. TLS-RPT es el estándar de generación de informes: define un registro DNS y un formato de informe JSON para que los servidores emisores te envíen resúmenes diarios de los éxitos y fallos de la entrega por TLS. Los despliegas juntos, usando TLS-RPT para validar de forma segura una política MTA-STS antes de hacerla cumplir.

¿Es obligatorio MTA-STS?

No, MTA-STS no es obligatorio, y el correo funciona sin él. Sin embargo, es muy recomendable para cualquier dominio que gestione correo sensible, porque cierra una brecha real que SPF, DKIM y DMARC no abordan. Desplegarlo primero en modo de pruebas no conlleva ningún riesgo de entrega, así que hay pocas razones para no adoptarlo.

¿MTA-STS reemplaza a SPF, DKIM o DMARC?

No. MTA-STS opera en una capa diferente. SPF, DKIM y DMARC autentican al remitente y detectan la suplantación, mientras que MTA-STS asegura la conexión de transporte para que el correo se entregue de forma privada al servidor correcto. Son controles complementarios, y un dominio bien protegido los despliega todos juntos en lugar de elegir uno sobre otro.