MTA-STS y TLS-RPT: qué hacen y si los necesita
MTA-STS es una política con la que indica a los servidores de envío que el correo hacia su dominio solo puede entregarse por una conexión TLS cifrada y verificada. TLS-RPT es el canal de informes correspondiente: los remitentes le envían a diario un informe de las conexiones que no cumplieron esa política. Ambos protegen el correo que usted recibe; para el correo que envía, lo que necesita sobre todo es un servidor de envío que respete estas políticas en el destinatario.
El problema que resuelven
El correo entre servidores viaja desde hace años en buena medida cifrado, mediante STARTTLS. Pero STARTTLS es oportunista: el servidor de envío pregunta si el receptor admite cifrado y, si no llega respuesta o el certificado no cuadra, vuelve en silencio a una conexión sin cifrar. Quien esté en medio de ambos servidores puede filtrar esa pregunta y dejar pasar el correo en forma legible. MTA-STS elimina esa vía de retroceso: si su política está en «enforce», un remitente que no consiga cerrar el cifrado no puede entregar el correo.
Cómo funciona MTA-STS
Consta de dos partes que publica usted mismo:
- Un registro DNS en _mta-sts.sudominio.be con una versión y un identificador. Ese identificador se cambia cada vez que modifica la política; así los remitentes saben que deben volver a recogerla.
- Un archivo de política en https://mta-sts.sudominio.be/.well-known/mta-sts.txt. En él figuran el modo (none, testing o enforce), los servidores de correo autorizados a recibir para su dominio y cuánto tiempo puede recordar un remitente la política.
Esa segunda parte explica por qué MTA-STS va por HTTPS y no solo por DNS: el certificado de esa página web demuestra que la política viene realmente de su dominio, sin necesidad de DNSSEC. La alternativa, DANE, hace lo mismo por DNS pero sí exige DNSSEC en su dominio, algo que en la práctica no está activado por defecto en muchos registradores y planes de alojamiento belgas.
Cómo funciona TLS-RPT
TLS-RPT es un registro DNS en _smtp._tls.sudominio.be con una dirección en la que quiere recibir los informes. Los remitentes que lo admiten (entre ellos los grandes proveedores) le envían entonces una vez al día un informe con, por servidor de envío, cuántas conexiones tuvieron éxito y cuántas fallaron, y por qué: certificado caducado, nombre de servidor que no coincide, STARTTLS no ofrecido, política no recuperable.
Ese informe es la razón para empezar por TLS-RPT antes incluso de aplicar MTA-STS. Le dice si hay remitentes que no podrán entregarle correo cuando ponga el modo en enforce. Compárelo con DMARC: primero mirar, después endurecer. Cómo leerlo está en nuestro artículo sobre los informes DMARC; la lógica es la misma.
¿Los necesita?
Depende de qué lado de la conexión mire.
Como receptor
Si su dominio recibe correo sensible (expedientes de personal, datos médicos, correspondencia jurídica, instrucciones de pago), MTA-STS es una protección barata contra la interceptación del correo en tránsito. Para un dominio que recibe sobre todo boletines y confirmaciones de pedido la ganancia es menor, pero cuesta poco: un registro DNS, un pequeño archivo estático en un subdominio con certificado válido y un buzón para los informes.
Como remitente
MTA-STS en su propio dominio no cambia nada del correo que envía. Lo que sí cuenta: el servidor con el que envía debe comprobar y respetar la política MTA-STS del destinatario, y debe tener él mismo un certificado TLS correcto. Si envía por un relay SMTP, eso es responsabilidad del relay. Pregúntelo si no está seguro: un remitente que ignore la política será rechazado por un destinatario en modo enforce, y eso lo verá como un rebote.
Un plan práctico
- Ponga el registro TLS-RPT y deje que los informes lleguen unas semanas a una dirección que alguien lea de verdad.
- Publique la política MTA-STS en modo testing. Los remitentes comunicarán entonces las desviaciones en los informes pero seguirán entregando con normalidad.
- Resuelva lo que vea en los informes: normalmente un servidor de correo que no estaba en la política, o un certificado emitido a otro nombre.
- Ponga el modo en enforce y suba el identificador del registro DNS.
- Revise los informes cada mes y compruebe con cada cambio de sus servidores de correo que el archivo de política sigue siendo correcto.
Quien use una plataforma de correo alojada encontrará los nombres de servidor para la política en los ajustes MX de esa plataforma. Quien gestione servidores de correo propios debe vigilar el certificado de esos servidores: un certificado caducado significa, en modo enforce, que el correo externo deja de entrar.
Lo que no hace
MTA-STS no dice nada sobre quién puede enviar correo en su nombre; para eso siguen haciendo falta SPF, DKIM y DMARC. Tampoco protege el camino del servidor receptor al buzón del lector, ni cifra el contenido en el propio servidor. Cierra una fuga concreta: el retroceso sin cifrar entre dos servidores de correo.
Preguntas frecuentes
¿MTA-STS es obligatorio?
No. Es una recomendación que los grandes proveedores admiten, no un requisito para entregar. En algunos sectores y licitaciones sí se pide cada vez más.
¿Puedo poner MTA-STS si mi correo está en Microsoft 365 o Google Workspace?
Sí. La política la publica usted, con los servidores MX de esa plataforma dentro. Ambas plataformas tienen certificados válidos en esos servidores.
¿Y si en ese dominio solo envío y no recibo nada?
Entonces MTA-STS tiene poco sentido para ese dominio. Dedique su tiempo a la autenticación y a la entregabilidad; es lo que se juzga en su correo saliente.