¿Cómo configuro MTA-STS y TLS-RPT para mi dominio?

¿Qué protege MTA-STS?

MTA-STS permite que un dominio de correo declare que admite TLS y que los remitentes deben negarse a entregar a cualquiera de sus hosts MX que no pueda presentar un certificado válido. Lo define la RFC 8461, un Proposed Standard de septiembre de 2018. Sin él, el cifrado entre servidores es oportunista: un remitente intenta STARTTLS y, si un atacante lo elimina, envía el mensaje en texto claro.

Con una política en modo enforce, un remitente compatible con MTA-STS obtiene su política, comprueba que el host MX aparece en la lista mx y exige una conexión TLS válida con un certificado que coincida. Si falla cualquier comprobación, el mensaje espera y no se entrega por un canal más débil. Protege solo el correo entrante y funciona únicamente con los remitentes que lo implementan. No autentica los mensajes: esa es la función de los registros de SPF frente a DKIM frente a DMARC.

¿Qué contiene el archivo de política?

El archivo de política es un archivo de texto plano con líneas clave: valor que contienen la versión, el modo, los patrones MX permitidos y una duración en segundos. La RFC 8461 define estos campos. version debe ser STSv1. mode es enforce (los remitentes no deben entregar a los hosts que no superen las comprobaciones), testing (la entrega puede continuar y los remitentes compatibles con TLS-RPT envían informes de fallos) o none (como si no existiera ninguna política). Cada línea mx nombra un host completo, por ejemplo mail.protonmail.ch, o usa un comodín en la etiqueta situada más a la izquierda, como *.example.net. max_age es un número de segundos, como máximo 31,557,600, y la RFC dice que normalmente debería ser de semanas o más. Su ejemplo usa 604800, una semana.

El archivo debe servirse por HTTPS en mta-sts.sudominio con un certificado válido para ese nombre. Solo cuenta una respuesta HTTP 200 y no se deben seguir las redirecciones, lo que descarta el reenvío de URL, un servicio que responde con una redirección. El archivo debe enviarse como text/plain. Use un alojamiento web pequeño o un alojamiento de páginas estáticas que usted controle. Las líneas mx deben coincidir con los registros de su proveedor, tal como se enumeran en qué es un registro MX.

¿Qué son el id y el orden de actualización?

El id del registro TXT es una etiqueta de 1 a 32 letras y dígitos que debe cambiar cada vez que cambia la política, para que los remitentes sepan que deben volver a obtener el archivo. La RFC 8461 dice que identifica una instancia de una política y que no existe ningún orden entre ids, por lo que funciona bien una marca de fecha y hora.

Actualice en este orden: publique primero el nuevo archivo de política y después cambie el id. Un remitente que vea el nuevo id antes del nuevo archivo volvería a guardar en caché la política antigua. Cuando cambia de proveedor de correo, los hosts MX también cambian, así que edite las líneas mx antes de cambiar los registros MX, mantenga los hosts antiguos en la lista durante el cambio y modifique el id. Una línea mx olvidada en modo enforce impide que llegue el correo, y la guía de migración cómo trasladar el correo a un nuevo proveedor ofrece el orden seguro del resto.

¿Qué es TLS-RPT y qué contienen los informes?

TLS-RPT es un formato de informes, la RFC 8460, en el que los servidores remitentes le indican cada día cuántas conexiones TLS a su dominio tuvieron éxito o fallaron. Usted publica un registro TXT en _smtp._tls.sudominio con v=TLSRPTv1 y un campo rua que contiene una dirección mailto: o https:. Los informes por mailto deben llevar una firma DKIM válida del dominio que informa.

Cada informe es un documento JSON que abarca un día UTC. Nombra la política aplicada (MTA-STS, DANE o ninguna), cuenta las sesiones correctas y fallidas e indica el tipo de fallo, como certificate-expired o starttls-not-supported, con las direcciones IP de envío y de recepción. Así se entera de que un certificado ha caducado o de que una línea mx tiene un error tipográfico, antes de pasar a enforce. Trate las primeras semanas como el periodo de prueba recomendado para DMARC.

¿Necesito MTA-STS para un dominio de correo personal?

No: MTA-STS es un refuerzo opcional y las reglas de los grandes remitentes no lo exigen. Google, Yahoo y Microsoft piden a los remitentes masivos SPF, DKIM y DMARC y no incluyen MTA-STS. Para un dominio personal en Proton Mail, Fastmail o Mailbox.org, la configuración solo compensa si usted acepta el mantenimiento de un alojamiento web y de un certificado.

Los proveedores difieren. Según la lectura de Postelva del 12 de noviembre de 2026 de las listas de configuración DNS de 4 proveedores (Proton Mail, Tuta, Mailbox.org y Fastmail), 1 incluye un registro MTA-STS en su propia configuración (Tuta, un CNAME), y las páginas de ayuda leídas de los otros tres no documentan ninguno. La configuración completa son 3 registros DNS y 1 archivo. Compruebe cada uno con los comandos de cómo comprobar los registros MX, SPF, DKIM y DMARC: dig TXT _mta-sts.example.com +short y dig TXT _smtp._tls.example.com +short.

Una definición citable: MTA-STS es la política que hace obligatorio el TLS cuando otros servidores entregan correo a su dominio, y TLS-RPT es el informe diario que le avisa cuando falla.