TLS-RPT: el informe de transporte cifrado

v=TLSRPTv1; rua=mailto:tlsrpt@ejemplo.com

Una diferencia de formato deliberada

La elección del JSON en lugar del XML no es anecdótica. Los informes DMARC heredaron el XML por razones históricas ligadas a la época de su diseño; TLS-RPT, más reciente, adopta un formato más ligero y más simple de parsear con las herramientas modernas. En concreto, esto significa que los scripts de ingesta para TLS-RPT suelen ser más cortos de escribir que sus equivalentes DMARC, un detalle apreciable cuando se plantea construir una cadena de procesamiento propia en lugar de depender de un servicio de terceros.

El formato de los informes

Los informes TLS-RPT están en formato JSON (al contrario que el XML de los informes DMARC), generalmente comprimidos en gzip y enviados por email como adjunto, o recuperables a través de la API cuando se ha elegido una URI https:. Cada informe cubre una ventana de 24 horas y agrupa los resultados por «policy domain» (el dominio cuya política MTA-STS se evaluó) y por tipo de fallo.

Un informe típico indica, por ejemplo: «4892 sesiones exitosas hacia mail.ejemplo.com, 3 sesiones fallidas de tipo certificate-expired, desde Gmail, en el periodo del 29 de julio». Esta granularidad permite aislar un problema preciso —aquí, un certificado que renovar con urgencia— en lugar de adivinar a partir de una queja vaga de un destinatario.

Por qué es imprescindible antes de enforce

El modo testing de MTA-STS registra los fallos sin bloquear la entrega, pero ese registro solo resulta útil si alguien lo lee. Sin TLS-RPT, no hay ninguna visibilidad sobre lo que ese modo de prueba observa realmente: se publica una política, se espera y se confía en que todo vaya bien. Con TLS-RPT, se ve concretamente, día tras día, si fallan conexiones y por qué, exactamente la misma lógica de prueba antes del endurecimiento que se aplica a la secuencia DMARC none → quarantine → reject, detallada en alcanzar p=reject sin romper el correo legítimo.

Pasar MTA-STS a enforce sin haber leído al menos unas semanas de informes TLS-RPT limpios es endurecer a ciegas: si un servidor destinatario legítimo tiene un problema de certificado temporal, el modo enforce rechazará la entrega del correo hacia él, sin más señal que una bajada silenciosa de entregabilidad, potencialmente durante semanas antes de que alguien lo perciba.

Leer un informe: las señales que alertan

Una vez los informes en marcha, algunas señales merecen una atención particular:

• Una tasa de fallo en subida repentina hacia un destinatario concreto, a menudo la señal de un problema de certificado o de configuración reciente de ese lado, que hay que vigilar pero que no es necesariamente competencia del emisor.
• Fallos mta-sts-policy-invalid repetidos: esos sí caen del lado del propietario del dominio, cuya política está mal formada o no se encuentra, y merecen una corrección inmediata.
• Fallos certificate-expired en los servidores propios: la señal más urgente, ya que indica que la infraestructura interna tiene un certificado TLS caducado, bloqueando potencialmente la recepción de correo legítimo en cuanto MTA-STS esté en enforce.
• Una ausencia total de informes: la primera comprobación es la sintaxis DNS, antes de concluir que todo va bien; igual que con rua en DMARC, un registro mal formado puede simplemente impedir el envío de los informes en lugar de señalar una ausencia de tráfico. El mismo reflejo de paciencia se aplica también: conviene dejar pasar 48 horas antes de inquietarse por un silencio.

Después de enforce: TLS-RPT sigue encendido

La tentación, una vez pasado MTA-STS a enforce, es considerar TLS-RPT como un andamio que desmontar: la prueba está hecha, ¿para qué seguir? Es exactamente lo contrario. Es en modo enforce cuando los informes se vuelven más valiosos: un certificado que caduca, una migración de servidor de correo, un cambio de MX olvidado en el fichero de política, cada uno de estos eventos ordinarios puede ponerse a bloquear correo legítimo, silenciosamente, de la noche a la mañana. TLS-RPT es entonces el único canal que avisa antes que los interlocutores. Merece un trato de supervisión permanente, al mismo título que el buzón rua de DMARC: un flujo que se lee mientras la política exista, no solo durante su fase de prueba.

El vínculo con DANE y los demás mecanismos de aseguramiento del transporte

TLS-RPT no está exclusivamente ligado a MTA-STS, aunque sea con mucho el uso más común. La RFC 8460 concibe el protocolo como un mecanismo de reporting genérico para los fallos de aseguramiento del transporte SMTP, lo que incluye también DANE (DNS-based Authentication of Named Entities), un enfoque alternativo que ancla la validación TLS en registros DNSSEC en lugar de en un fichero de política HTTPS. Cuando una organización ha desplegado DANE en lugar de (o además de) MTA-STS, TLS-RPT sigue proporcionando la misma visibilidad sobre los fallos de conexión, con códigos de error adaptados a ese mecanismo.

En la práctica, la gran mayoría de los despliegues en 2026 privilegian MTA-STS por su simplicidad de implementación: DANE exige una infraestructura DNSSEC ya establecida y correctamente mantenida, una barrera técnica más alta para muchas organizaciones. Pero el hecho de que TLS-RPT cubra los dos mecanismos significa que la inversión en la configuración de los informes no se pierde si más adelante se migra o se combinan los enfoques.

La ventana de 24 horas y el desfase que anticipar

Igual que con los informes agregados DMARC, hay que contar con un desfase entre el evento observado y su recepción en el buzón. Un informe TLS-RPT que cubre el día 29 de julio llega generalmente el 30 o el 31, una vez que el proveedor emisor ha terminado de agregar sus propias observaciones sobre la ventana. Este desfase tiene una consecuencia práctica directa sobre la cadencia de vigilancia durante la fase testing de MTA-STS: no hay señal instantánea tras un cambio de configuración del lado del servidor; el plazo a prever es más bien de 48 a 72 horas antes de poder juzgar el efecto real de un correctivo sobre la tasa de fallo observada.

Herramientas: leer JSON a mano no es viable

Igual que con los informes DMARC, leer manualmente decenas de ficheros JSON comprimidos diarios solo es realista para un dominio muy pequeño. En cuanto el volumen crece, una herramienta de agregación que transforme esos informes en un panel legible se vuelve necesaria: el mismo tipo de plataforma que ya procesa los informes DMARC agregados suele ofrecer un soporte TLS-RPT en paralelo, ya que los dos flujos comparten la misma lógica de recopilación y visualización. Reunir los dos en una sola herramienta evita multiplicar los paneles que hay que vigilar por separado, y facilita la correlación entre un incidente de autenticación y un incidente de transporte ocurridos en el mismo periodo.

En resumen

TLS-RPT es a MTA-STS lo que los informes agregados son a DMARC: el bucle de prueba que transforma una política publicada a ciegas en un endurecimiento fundado en datos reales. Configurarlo es un registro DNS más, sin trampa de autorización externa que gestionar, y la lectura regular de sus informes es lo que distingue un despliegue MTA-STS prudente de una apuesta arriesgada sobre la entregabilidad.

Para comprobar el estado de la autenticación de email de base —el cimiento sobre el que MTA-STS y TLS-RPT vienen a añadirse— basta pasar el dominio por el analizador DMARC gratuito. Es el paso a tratar como prioridad; el transporte cifrado viene después a completar una identidad ya sólida, no a reemplazarla, y es en ese orden en el que los dos protocolos aportan más valor.