Cifrado en el transporte: MTA-STS y TLS-RPT

Entre servidores de correo el cifrado es voluntario y se puede desactivar por el camino. MTA-STS lo hace obligatorio; TLS-RPT informa de los fallos. Cómo se publican y qué falla.

Entre el programa de correo y su servidor, el cifrado lleva años siendo obligatorio. Entre un servidor y otro, no. Ahí se usa STARTTLS, que funciona como una pregunta: el servidor que envía pregunta si se puede cifrar y el que recibe contesta. Si la respuesta es no, el mensaje se envía igualmente, en claro.

Eso abre una puerta pequeña pero real. Quien esté en medio de la conexión no necesita romper nada: le basta con borrar la respuesta que ofrece el cifrado. Los dos servidores creen que la otra parte no sabe cifrar y continúan sin cifrado, sin que ninguno de los dos lo note. Es un ataque de degradación, y MTA-STS existe para cerrarlo.

MTA-STS es una declaración publicada por usted que dice: mi dominio acepta TLS, estos son mis servidores, y si el cifrado no se puede establecer, no entregues el mensaje. Un servidor emisor que respeta MTA-STS ya no acepta un «no» por respuesta. TLS-RPT es la pieza que la acompaña: pide a los remitentes que le informen de los fallos que encuentren.

Cómo se publica

MTA-STS tiene dos partes, y las dos tienen que estar. Esa es la causa de casi todos los problemas.

Primero, un registro TXT que anuncia que la política existe:

_mta-sts.ejemplo.es.  IN  TXT  "v=STSv1; id=20260916000000"

El campo id es una etiqueta de versión. Cambia cada vez que modifica la política: es lo que indica a los remitentes que vuelvan a descargarla.

Segundo, un archivo servido por HTTPS en un subdominio con nombre fijo, en https://mta-sts.ejemplo.es/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.ejemplo.es
mx: respaldo.ejemplo.es
max_age: 604800

El subdominio mta-sts necesita su propio certificado TLS válido. Es el paso que más se olvida: el registro se publica, el archivo se sube, y el certificado del subdominio no cubre ese nombre.

Y aparte, TLS-RPT, que es independiente y se puede publicar solo:

_smtp._tls.ejemplo.es.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls@ejemplo.es"

Con él, los grandes proveedores le envían un resumen diario de las conexiones que han hecho hacia sus servidores y de los fallos de cifrado. Es información que de otro modo no tiene forma de ver.

El orden que conviene seguir

MTA-STS en enforce es el único mecanismo de esta comprobación capaz de impedir que le llegue correo si se configura mal. Por eso el orden importa.

Y una regla para después: cada vez que cambie sus registros MX, actualice el archivo de política antes. Un servidor nuevo que no esté en la lista, con la política en enforce, no recibe correo.

Los hallazgos, uno por uno

Varios registros MTA-STS

Hay más de un registro TXT en _mta-sts que empieza por v=STSv1.

Importa porque el remitente no puede saber cuál vale y, en la práctica, la indicación queda inservible. Suele pasar al cambiar el id creando un registro nuevo en vez de editar el que había.

Qué hacer. Deje un único registro con el id actual y borre el resto.

MTA-STS en modo de prueba

La política está en mode: testing: los remitentes comprueban el cifrado, informan de lo que no cuadra y entregan igualmente.

No es un defecto, es la fase correcta al empezar. Lo señalamos porque testing no protege: un ataque de degradación sigue siendo posible, solo que ahora quedaría registrado en los informes. El riesgo real es quedarse ahí para siempre, que es lo que pasa cuando nadie mira los informes.

Qué hacer. Revise los informes de TLS-RPT de las últimas semanas. Si no aparecen fallos que le afecten, cambie a mode: enforce y actualice el id del registro TXT. Si aún no publica TLS-RPT, publíquelo antes: sin él, testing no le está contando nada a nadie.

MTA-STS desactivado (mode: none)

La política existe y dice expresamente mode: none, que significa: ignore cualquier política anterior de este dominio.

Importa porque no hace nada salvo anular. none está pensado como salida ordenada —se publica unos días antes de retirar MTA-STS, para que los remitentes que guardaron la política antigua la olviden— y casi siempre es el resto de una desactivación que nunca se terminó de limpiar.

Qué hacer. Decida: o vuelve a ponerla en testing y sigue el camino de arriba, o retira el registro TXT y el archivo. Dejarlo en none indefinidamente solo confunde a quien lo herede.

Validez de MTA-STS muy corta

El campo max_age es inferior a 86400 segundos, es decir, menos de un día.

Importa porque anula buena parte de la protección. La idea de MTA-STS es que el remitente guarde la política: así, aunque un atacante bloquee la consulta la próxima vez, el remitente recuerda que ese dominio exige cifrado. Con una validez de horas, esa memoria casi no existe y basta con bloquear el acceso al archivo en el momento adecuado.

Qué hacer. Suba max_age a 604800 segundos, una semana, que es el valor habitual. Un valor bajo tiene sentido solo durante unos días, mientras prueba cambios, y conviene volver a subirlo después.

La política no nombra todos los servidores

En sus registros MX hay servidores que no figuran en el archivo de política. La política está en testing, así que de momento no se pierde nada.

Importa porque es un aviso con tiempo: hoy produce informes de error y el día que pase a enforce producirá correo que no llega. Casi siempre es rastro de un cambio de MX que no se reflejó en el archivo.

Qué hacer. El informe indica qué nombres faltan. Añádalos al archivo, una línea mx: por cada uno, y actualice el id del registro TXT para que los remitentes recarguen la política. Si sus servidores comparten sufijo, una línea con comodín, mx: *.ejemplo.es, evita que vuelva a pasar.

La política impuesta excluye sus propios servidores

Lo mismo que el hallazgo anterior, pero con mode: enforce. Hay servidores en sus MX que la política no reconoce.

Esto es urgente. Los remitentes que respetan MTA-STS —y son los grandes— comparan el servidor al que van a entregar con la lista de la política. Si no coincide, interrumpen la entrega. Su propio correo entrante deja de llegar desde esos remitentes, y el mensaje de error que le llega al remitente habla de un fallo de política, algo que nadie relaciona con su DNS.

Qué hacer. Dos opciones, y la primera es mejor si puede hacerla ahora mismo: añada los nombres que faltan al archivo y actualice el id. Si no puede tocar el archivo de inmediato, ponga mode: testing como medida provisional, lo que restablece la entrega mientras lo arregla. Tenga en cuenta que los remitentes que ya guardaron la política pueden tardar hasta el max_age en recargarla.

Registro MTA-STS sin archivo de política

El registro TXT anuncia una política, pero el archivo no está accesible en https://mta-sts.su-dominio/.well-known/mta-sts.txt.

Importa porque deja la situación a medias, y a medias es peor que nada: un remitente que ve el registro y no consigue el archivo puede interrumpir la entrega, sobre todo si ya tenía guardada una política anterior. Las causas habituales son que el subdominio mta-sts no existe, que su certificado TLS no cubre ese nombre, o que el archivo se sirve con el tipo de contenido equivocado.

Qué hacer. Compruebe primero abriendo esa dirección en el navegador: tiene que verse el texto de la política, sin avisos de certificado. Si el subdominio no existe, créelo y emita un certificado que lo cubra. Si no puede resolverlo ahora, retire el registro TXT mientras tanto: sin registro no hay promesa que incumplir.

TLS-RPT sin dirección de destino

Existe un registro en _smtp._tls pero no tiene campo rua, así que no dice a dónde enviar los informes.

Importa porque el registro no sirve de nada tal como está. Nadie le informará de los fallos de cifrado, que es su única función.

Qué hacer. Añada rua=mailto:tls@su-dominio al registro. Puede usar el mismo buzón que para los informes de DMARC; son formatos distintos, pero ambos son adjuntos que conviene tener separados del correo normal.

Preguntas frecuentes

¿Necesito MTA-STS si mi correo está en Microsoft 365 o Google Workspace?

No es imprescindible, y de hecho ambos proveedores ya cifran de forma oportunista con todo el mundo. MTA-STS aporta la garantía de que un ataque de degradación no funcione contra su dominio. Si maneja datos sensibles o le llegan documentos de clientes por correo, compensa. En ese caso, el archivo de política nombra los servidores del proveedor, que son los que están en sus MX.

¿Puedo publicar solo TLS-RPT?

Sí, y es una buena primera medida. No cambia nada en la entrega y le da visibilidad sobre algo que hoy no ve: cuántas conexiones hacia sus servidores se cifran y cuántas fallan. Con esos datos delante, la decisión sobre MTA-STS se toma con información.

¿Por qué no comprueban ustedes mi certificado de correo?

Porque no podemos, desde este servidor. El tráfico SMTP saliente está bloqueado, como en la mayoría de centros de datos, así que no hay forma de abrir una conexión con su servidor y mirar qué presenta. Preferimos decirlo antes que dar por buena una comprobación que no se ha hecho.

¿Qué pasa si cambio de proveedor de correo?

Actualice el archivo de política antes de cambiar los MX, y deje los nombres antiguos y los nuevos durante la transición. Si la política está en enforce y los MX nuevos no figuran, el correo deja de llegar desde los remitentes que respetan MTA-STS. También conviene revisar SPF y la recepción en la misma operación.