Cómo configurar MTA-STS y TLS-RPT para el correo

Cómo configurar MTA-STS y TLS-RPT para proteger el correo electrónico

MTA-STS permite que un dominio receptor indique a los sistemas de correo remitentes qué servidores deben aceptar sus mensajes y que esas conexiones deben usar TLS de confianza. TLS-RPT añade informes: los remitentes que lo admiten pueden enviarte información sobre errores de entrega relacionados con TLS y problemas con las políticas. Si estás buscando cómo configurar MTA-STS y TLS-RPT para proteger el correo electrónico, empieza por la configuración del correo entrante, no por un registro DNS.

Estos mecanismos no sustituyen a SPF, DKIM ni DMARC. Protegen otra parte del recorrido: la conexión cifrada entre servidores de correo. Una política que incluya un host MX antiguo o mal configurado puede interrumpir la entrega, así que prueba toda la configuración antes de aplicarla.

1. Comprueba que tu servicio de correo esté listo

Empieza por revisar los registros MX actuales del dominio. Anota todos los nombres de host a los que apuntan, incluidos los que se usan para la entrega de respaldo o regional. Si tu proveedor gestiona el correo entrante, pídele que confirme qué nombres MX deben incluirse en la política MTA-STS y si todos admiten TLS con un certificado válido.

Comprueba los nombres, no solo la marca del proveedor. Un dominio podría tener registros MX como mx1.mail.example.com y mx2.mail.example.com, mientras que el proveedor también opera otros hosts que no están asociados a tu dominio. La política debe incluir los nombres de host MX que pueden recibir correo para el dominio.

Comprueba el certificado y la configuración TLS de cada host indicado. El certificado debe ser de confianza y válido para el nombre de host MX al que se conecta el sistema de correo remitente. Un certificado válido para el sitio web del proveedor, pero no para su servidor de correo, no sirve como sustituto.

Pregunta también a tu proveedor si tiene previsto cambiar algún host. Si durante la configuración va a cambiar un nombre de host MX, espera a tener la lista definitiva o coordina con el proveedor la actualización de la política. Un host de reemplazo que no esté incluido puede causar problemas de entrega cuando un remitente haya almacenado en caché una política aplicada.

2. Publica un destino para los informes TLS-RPT

Antes de publicar el registro DNS, decide dónde quieres recibir los informes. Puedes usar un buzón que los acepte o un servicio de informes TLS que te proporcione una dirección o un destino HTTPS. Confirma que alguien supervise el destino y que tu sistema de correo acepte los informes entrantes allí. Para configurar un registro DNS TLS-RPT para informes de correo, primero asegúrate de que el destino esté preparado para recibirlos.

Publica un registro TXT en _smtp._tls.example.com y sustituye example.com por tu dominio. Para indicar un buzón, usa un valor con este formato: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Si tu servicio de informes proporciona otro destino, utiliza exactamente el URI que te indique.

Si es posible, usa un buzón distinto de la bandeja de entrada habitual de una persona. Los informes TLS pueden llegar como archivos adjuntos estructurados, y un buzón específico facilita definir reglas de acceso, conservar los mensajes y asignar su revisión a la persona responsable de la entrega del correo. Antes de publicar el registro, comprueba el almacenamiento y los filtros del buzón.

Los cambios de DNS pueden tardar en propagarse porque los resolutores almacenan los registros en caché según su TTL. Después de publicar el registro, consulta el DNS autoritativo y un resolutor público para confirmar que ambos devuelvan el valor TXT previsto. Un error tipográfico en el nombre del registro puede hacer que los remitentes no encuentren el destino.

3. Aloja el archivo de política MTA-STS

Coloca la política en https://mta-sts.example.com/.well-known/mta-sts.txt y sustituye example.com por tu propio dominio. Si te preguntas cómo publicar una política MTA-STS, empieza por alojar el archivo en esta ruta y comprueba que el punto de acceso esté disponible mediante HTTPS con un certificado válido para el nombre de host mta-sts.example.com. Un archivo en la ruta habitual de la página de inicio del sitio web no cumple este requisito.

La política es un archivo de texto sin formato. Para una primera prueba, usa campos como estos:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Sustituye los nombres MX de ejemplo por los hosts reales que reciben correo para tu dominio. El valor max_age indica durante cuántos segundos puede almacenar en caché la política un remitente; el ejemplo anterior equivale a un día. Un periodo inicial más corto facilita modificar la política de prueba, mientras que uno más largo significa que los remitentes podrían conservarla durante más tiempo.

Usa el modo testing antes de aplicar la política. En este modo, los remitentes pueden informar de errores sin que la política les exija rechazar los mensajes que no puedan entregarse con las condiciones TLS establecidas. Prueba la URL desde fuera de tu red y verifica que el archivo se muestre sin necesidad de iniciar sesión, sin bucles de redirección y sin errores de la aplicación web.

4. Publica el registro de descubrimiento MTA-STS

Los remitentes encuentran la política mediante un registro TXT en _mta-sts.example.com. Su valor incluye la versión y un identificador de política; por ejemplo: v=STSv1; id=20261104a. Elige un identificador que puedas rastrear en el registro de cambios, en lugar de reutilizar uno antiguo.

Cambia el identificador cada vez que publiques una versión revisada del archivo de política. Así indicas a los sistemas remitentes que deben consultar la política actualizada, en vez de depender únicamente de una copia en caché. El identificador sirve como señal de descubrimiento; no sustituye al archivo de política ni a su alojamiento mediante HTTPS.

Publica el registro solo cuando el archivo de política esté disponible en la URL requerida. Después, consulta el registro TXT y carga la URL desde una conexión externa. El registro DNS y el archivo deben reflejar la misma configuración actual: un identificador nuevo que apunte a un archivo inexistente o desactualizado sigue siendo una implementación defectuosa.

5. Comprueba el descubrimiento, la política y los hosts MX

Verifica cada componente por separado. Consulta los registros TXT de _smtp._tls y _mta-sts, solicita la política mediante HTTPS y compara cada línea mx: con los registros MX activos. Esta comprobación en tres partes detecta errores que una consulta DNS por sí sola no puede encontrar.

Confirma que la respuesta HTTPS use un certificado de confianza para el nombre de host MTA-STS y que el archivo contenga los campos previstos. Después, comprueba que cada host MX admita TLS y tenga un certificado válido para ese nombre de host exacto. Si tu proveedor tiene varios nombres MX de entrada, prueba cada uno en vez de dar por hecho que todos usan la misma configuración de certificados.

Guarda los resultados, incluidos los valores DNS, el identificador de la política, los nombres de host MX y la fecha de la comprobación. Así, la próxima persona administradora tendrá una referencia útil si más adelante los informes muestran algún error. Para consultar más información sobre configuración del correo, puedes añadir el canal RSS del blog de YourTrend a la lista de recursos del equipo.

6. Revisa los informes antes de aplicar la política

Mantén la política en modo de prueba mientras recopilas informes TLS-RPT y compruebas el funcionamiento normal del correo. Los informes pueden identificar sistemas remitentes que hayan encontrado problemas con un certificado, con la negociación TLS o con la correspondencia entre los hosts MX anunciados y la política. Un informe es un indicio que debes investigar, no una orden automática para cambiar un registro DNS.

Revisa el periodo del informe, el dominio afectado por la política y los datos del host receptor. Compáralos con tu inventario de MX y la configuración del proveedor. Si falta un host legítimo, actualiza el archivo de política y cambia el ID de la política; si el certificado es incorrecto, pide al proveedor que lo corrija antes de aplicar la política.

Prueba también la entrega desde los sistemas de correo de los que depende tu organización, como los de un socio comercial o los de otro servicio bajo tu control. Confirma que los mensajes lleguen y que los registros de entrada muestren conexiones TLS correctas. Que no haya actividad en el buzón de informes no demuestra por sí solo que todos los remitentes hayan probado la política.

Define un periodo de revisión que se ajuste al volumen de correo y a las necesidades operativas. No existe un número universal de días que garantice que todos los sistemas remitentes aparezcan en los informes, así que no consideres que un intervalo específico del calendario demuestra que la cobertura es completa. Anota qué comprobaste y cuáles de los remitentes conocidos entregaron mensajes correctamente durante la prueba.

7. Aplica la política, supervisa y mantén la configuración

Cuando la lista de MX, los certificados, la política HTTPS y los resultados de las pruebas estén listos, cambia el modo de la política de testing a enforce. Publica el archivo de política actualizado y un nuevo identificador de _mta-sts. Después de la actualización, verifica ambos desde fuera de tu red y sigue revisando los informes TLS-RPT y los registros del flujo de correo.

Con la política aplicada, se espera que los sistemas remitentes compatibles con MTA-STS usen TLS y validen el host receptor de acuerdo con la política. Si no pueden hacerlo, la entrega podría retrasarse mientras el remitente vuelve a intentarlo, en lugar de enviar el mensaje por una conexión desprotegida. Coordina el cambio con tu proveedor de correo y el equipo de soporte para que sepan cómo diagnosticar posibles retrasos en la entrega.

Documenta los pasos de mantenimiento junto con la URL de la política y los registros DNS. Si cambia un host MX, actualiza la política antes de depender del nuevo host; si se renueva un certificado, comprueba que cubra el nombre de host y que su cadena de confianza sea válida. Si al aplicar la política surge algún problema, volver al modo de prueba puede reducir su impacto, pero cambia el ID de la política y confirma que el archivo actualizado se sirva correctamente.

Asigna a alguien la revisión del buzón o servicio de informes y el seguimiento de los cambios de DNS y certificados. Si publicas notas operativas o avisos sobre el servicio de correo para tus colegas, también pueden seguir el canal del blog de YourTrend. Asignar una persona responsable y documentar el procedimiento para cambiar los registros MX facilita la próxima renovación o migración de proveedor.