SPF, DKIM y DMARC autentican al remitente de un correo, pero ninguno de los tres protege el trayecto del mensaje entre dos servidores SMTP. Un servidor malicioso situado en ese trayecto puede ofrecer un repliegue hacia una conexión sin cifrar, interceptando o modificando el contenido sin que ni el remitente ni el destinatario lo noten. MTA-STS (RFC 8461) cubre ese hueco imponiendo TLS en el momento de la entrega, y TLS-RPT (RFC 8460) permite vigilar los fallos de esa negociación día a día.
El problema que resuelve MTA-STS: el repliegue TLS silencioso
Desde hace años, la mayoría de los servidores SMTP negocian STARTTLS antes de la entrega. El problema es que esa negociación sigue siendo oportunista: si falla, el protocolo SMTP clásico permite un repliegue hacia una conexión sin cifrar en lugar de bloquear el envío. Un atacante en posición de interceptar el tráfico, mediante secuestro de DNS, secuestro de BGP o un relé comprometido, puede forzar ese repliegue simplemente cortando la negociación TLS, sin necesidad de romper ningún cifrado. MTA-STS retira esa opción al servidor remitente: una vez publicada y respetada la política, la ausencia de TLS válido se convierte en motivo de rechazo del envío en lugar de un repliegue silencioso. DANE, que se apoya en DNSSEC, persigue el mismo objetivo por otra vía, pero su despliegue depende de una zona DNS firmada que todavía pocos proveedores ofrecen de forma estándar; MTA-STS, en cambio, solo necesita un registro TXT y un archivo servido por HTTPS.
Desplegar una política MTA-STS paso a paso
Una política MTA-STS se compone de tres elementos: un registro DNS que señala su existencia y versión, un archivo de política servido por HTTPS en un subdominio dedicado, y un certificado válido para ese subdominio. Nada de esto requiere tocar la configuración del propio servidor de correo: la política describe el comportamiento esperado de los servidores remitentes externos, no cambia nada del lado de la recepción.
El registro DNS tiene esta forma:
_mta-sts.ejemplo.es. IN TXT "v=STSv1; id=20261108000000;"
mta-sts.ejemplo.es. IN CNAME ejemplo.es.
El archivo de política, por su parte, debe estar accesible en https://mta-sts.ejemplo.es/.well-known/mta-sts.txt, servido con la cabecera Content-Type: text/plain:
version: STSv1
mode: testing
mx: mail.ejemplo.es
mx: mail2.ejemplo.es
max_age: 86400
El campo id del registro DNS debe cambiar cada vez que se modifica el archivo de política: así es como se indica a los servidores que ya la tenían en caché que existe una versión nueva. Una simple marca de tiempo, como en el ejemplo anterior, es suficiente.
Entender los tres modos: none, testing y enforce
El campo mode del archivo de política determina el comportamiento real que aplican los servidores remitentes que respetan MTA-STS.
| Modo | Comportamiento si falla TLS | Uso recomendado |
|---|---|---|
none | Sin bloqueo, la política se ignora en la práctica | Desactivación temporal sin retirar la política |
testing | El correo se envía pese al fallo, pero se informa vía TLS-RPT | Fase de observación antes de producción |
enforce | El correo no se entrega sin TLS válido | Política definitiva, tras validar en modo testing |
enforce sin una fase de pruebas supone el riesgo de bloquear silenciosamente correos legítimos si cambia un registro MX, si un certificado caduca sin renovación automática, o si un relé de salida mal configurado falla en la negociación TLS. El modo testing, mantenido varias semanas, sirve precisamente para detectar estos casos antes de que cuesten una entrega.Activar TLS-RPT para recibir informes de fallos
TLS-RPT funciona de forma independiente a MTA-STS, pero ambos se complementan de manera natural: uno impone el cifrado, el otro informa de lo que ocurre cuando falla la negociación, ya sea por MTA-STS, por DANE o por una política TLS oportunista clásica. Activarlo se reduce a un registro DNS:
_smtp._tls.ejemplo.es. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Los servidores que admiten TLS-RPT envían entonces un informe agregado, normalmente diario, en formato JSON comprimido, a la dirección declarada en rua. El principio es el mismo que el de los informes agregados descritos en la guía de autenticación SPF, DKIM y DMARC: una síntesis periódica en lugar de una alerta en tiempo real, pensada para un tratamiento automatizado más que para una lectura manual diaria.
Leer y aprovechar un informe TLS-RPT
Un informe TLS-RPT agrupa los intentos de conexión por política observada, MTA-STS, DANE o ninguna, y por tipo de fallo: certificado caducado, nombre de certificado que no coincide con el MX, fallo de la propia negociación, o política MTA-STS no encontrada pese a estar publicada. Un volumen de fallos que se dispara justo tras un cambio de proveedor o de certificado suele ser la primera señal visible de una mala reconfiguración, incluso antes de que un destinatario reporte un problema de entrega.
Un repliegue TLS hacia una conexión sin cifrar no genera ninguna alerta en el lado del remitente si nada lo vigila: TLS-RPT es, para el transporte SMTP, el equivalente de lo que los informes agregados de DMARC aportan a la autenticación.
Errores frecuentes y buenas prácticas de despliegue
Tres errores se repiten con más frecuencia en los despliegues de infraestructuras de envío gestionadas por equipos reducidos. El primero, olvidar renovar automáticamente el certificado del subdominio mta-sts, lo que convierte una política en enforce en un bloqueo de la entrega en cuanto falla una renovación. El segundo, modificar la lista de MX sin volver a publicar el archivo de política con un nuevo id, lo que deja a los servidores remitentes apoyándose en una política en caché ya incorrecta hasta que expire el max_age. El tercero, descuidar la coherencia entre la lista de mx declarada en la política y los registros MX reales del dominio: cualquier divergencia hace que la validación del lado remitente falle, sea cual sea el modo elegido.
El despliegue completo, para un dominio que ya gestiona las causas habituales de caer en spam y su autenticación SPF, DKIM y DMARC, suele llevar entre dos y cuatro semanas, y la mayor parte de ese tiempo corresponde a la observación del modo testing y no a la configuración técnica en sí, que se reduce a unos pocos registros DNS y un archivo estático. Las plataformas de envío transaccional más utilizadas ya documentan su propio procedimiento de MTA-STS, lo que simplifica la parte de certificado y alojamiento del archivo de política para quien no opera sus propios servidores de salida.
Lo que hay que recordar
- MTA-STS impide el repliegue silencioso hacia una conexión SMTP sin cifrar al imponer TLS en el momento de la entrega.
- El despliegue implica un registro DNS, un archivo de política por HTTPS y un modo progresivo:
testingantes deenforce. - TLS-RPT ofrece informes agregados sobre los fallos de negociación TLS, ya vengan de MTA-STS, de DANE o de una política oportunista.
- Un certificado no renovado o una política no vuelta a publicar tras un cambio de MX son las dos causas más frecuentes de bloqueo una vez en modo
enforce.
MTA-STS sigue estando muy poco desplegado entre los hostings compartidos y las infraestructuras pequeñas, pese a que su configuración técnica es claramente más sencilla que la de DMARC. El verdadero freno está en la disciplina de volver a publicar la política con cada cambio de infraestructura de envío, no en la complejidad del protocolo. En los dominios seguidos que lo han adoptado, la fase testing ha revelado sistemáticamente al menos un MX secundario mal configurado que nadie había detectado antes, un buen motivo para tratarla como una auditoría gratuita más que como un trámite de seguridad. — Simon Janvier
Para profundizar: la especificación MTA-STS (RFC 8461) y la especificación TLS-RPT (RFC 8460).
