Comprobador de registros TLS-RPT (SMTP TLS Reporting)

Obtiene el registro TXT _smtp._tls de un dominio para diagnosticar si el destino de los informes (rua) para conexiones TLS fallidas está configurado correctamente según RFC 8460. Útil junto con MTA-STS/DANE.

Última actualización: 2026-09-20

Diagnosticar los informes de conexiones TLS fallidas (TLS-RPT)

Adoptar MTA-STS o DANE deja una cosa fuera de la vista: **si la entrega está fallando de verdad solo lo sabe el lado remitente.** TLS-RPT es el arreglo que llena ese hueco. Escriba una dirección de informe en el registro TXT `_smtp._tls` y **los servidores remitentes le enviarán un informe diario.** Esta herramienta recoge ese registro y comunica si su forma se ajusta a la RFC 8460.

**TLS-RPT no es en sí una defensa, sino un medio de observación.** Nada hace por detener un ataque; se limita a decirle con qué frecuencia falló el establecimiento de TLS. **Sin esa observación, sin embargo, no hay modo de juzgar cuándo pasar MTA-STS a `enforce`.** Si la entrega se detuviera en el instante en que empieza la obligatoriedad, usted no lo sabría hasta que alguien se quejara. **El orden asentado en la práctica consiste, por tanto, en montar primero TLS-RPT, tener MTA-STS en `testing` mientras se leen los informes, y pasar a `enforce` solo cuando se esté satisfecho de que nada falla.**

Cómo se usa

Introduzca el dominio Indique únicamente el dominio, en la forma `example.com`.
Compruebe el registro TXT **Busque `v=TLSRPTv1` y un `rua=`.**
Confirme la forma de la dirección de informe Se escribe con `mailto:` o `https:`. **Confirme también que esa dirección pueda recibir de verdad.**
Decida quién leerá los informes **Montarlo y no leerlos nunca no conduce a nada.** Decida quién mira, y cuándo.

Consejos para aprovecharla mejor

TLS-RPT lo declara el dominio receptor, pero lo utilizan los servidores de correo emisores, que lo usan para saber adónde enviar las estadísticas cuando falla una conexión TLS con tu dominio.
El campo rua puede incluir una dirección mailto:, un endpoint https:, o ambos separados por comas, de modo que puedas dirigir los informes a un buzón y a un recolector automatizado al mismo tiempo.
Los informes llegan en formato JSON (application/tlsrpt+json, a menudo comprimidos con gzip), por lo que conviene preparar un analizador o buzón dedicado en lugar de esperar leerlos manualmente.
Justo después de implementar MTA-STS o DANE, conviene vigilar los informes de TLS-RPT durante un tiempo para detectar cualquier error de configuración que se te haya pasado por alto.
Los principales proveedores de correo, como Google, Microsoft y Yahoo, envían informes TLS-RPT, por lo que los dominios que intercambian mucho correo con ellos son los que más se benefician al adoptarlo.

Cuándo resulta útil

Antes de pasar MTA-STS a la obligatoriedad

**Puede medir si algo está fallando mientras se sigue en `testing`**, lo que le da fundamento para decidir.

Advertir pronto un problema de entrega

Se entera de que hay fallos sin esperar a que alguien se lo diga.

Vigilar tras adoptar DANE

**Un desajuste entre certificado y registro TLSA aparece en los informes como un fallo.**

Confirmar la forma de su registro

Un error en cómo se escribe `rua` se manifiesta en que no llega informe alguno.

Términos de TLS-RPT

_smtp._tls TXT: **El registro DNS que lleva la dirección de informe.** Se escribe en la forma `v=TLSRPTv1; rua=mailto:...`.
Rua: Adónde han de ir los informes. **Indique una dirección de correo o un punto HTTPS preparado para recibirlos.**
RFC 8460: La norma que define el formato de TLS-RPT y el contenido de un informe.
Informe diario: El informe que un servidor remitente envía cubriendo un día. Lleva los recuentos de éxitos y fallos y los motivos de estos.
MTA-STS: El arreglo que impone TLS. **TLS-RPT se combina con él para ver cómo está resultando esa imposición.**
DANE: El arreglo que valida certificados sobre la premisa de DNSSEC. **Los problemas de aquí afloran también en los informes de TLS-RPT.**

Preguntas frecuentes

MTA-STS es el mecanismo de aplicación que fuerza TLS en el correo entrante. TLS-RPT es el mecanismo de observabilidad que informa si las conexiones TLS realmente están fallando. Se configuran de forma independiente y puedes adoptar cualquiera de los dos por separado.

No necesariamente: la mayoría de los dominios todavía no usan TLS-RPT. Pero si has adoptado MTA-STS o DANE, vale la pena configurar también TLS-RPT para poder detectar errores de configuración.

A la dirección mailto: o al endpoint https: que figure en el campo rua del registro TXT. Puedes indicar varios destinos separados por comas.

Los informes son datos JSON estructurados, así que la mayoría de los operadores recurren a una herramienta de monitorización o a un script para agregarlos automáticamente en lugar de leerlos a simple vista. Varios proveedores ofrecen servicios dedicados al análisis de estos informes.

Esta herramienta solo comprueba la sintaxis y los campos obligatorios (v, rua) del registro TXT. No verifica si los informes llegan realmente, así que tras la configuración conviene esperar unos días y confirmar que efectivamente llega un correo con el informe.

A propósito — El hueco de los "fallos silenciosos" que TLS-RPT vino a cerrar

TLS-RPT (TLS Reporting, RFC 8460) se publicó en 2018, casi al mismo tiempo que MTA-STS (RFC 8461). Ambos se desarrollaron en el mismo grupo de trabajo y comparten muchos elementos —los dos se apoyan en un registro TXT de DNS y ambos fueron impulsados conjuntamente por Google, Microsoft, Yahoo y otros—, pero desempeñan papeles muy distintos. MTA-STS es la capa de aplicación que fuerza el uso de TLS; TLS-RPT es la capa de observabilidad que revela qué ocurrió realmente una vez aplicado.

Antes de que existiera TLS-RPT, un fallo en el handshake TLS durante la entrega por SMTP se registraba, en la mayoría de los casos, solo en el servidor emisor, sin que el administrador del dominio receptor se enterara jamás. Un certificado caducado o una política MTA-STS mal configurada podían interrumpir silenciosamente la entrega de correo, y nadie lo notaría hasta que el correo dejara realmente de llegar; un auténtico punto ciego operativo.

Con TLS-RPT implementado, se envía un informe agregado diario al destino indicado en rua. El informe es un JSON estructurado (application/tlsrpt+json, a menudo comprimido con gzip) que contiene el número de éxitos y fallos y, para los fallos, la causa subyacente (una discrepancia de certificado, una negociación STARTTLS fallida, etc.), pensado para ser procesado por herramientas de monitorización más que leído por una persona.

En la práctica, TLS-RPT suele configurarse junto con MTA-STS o DANE. Implementar solo la aplicación forzada no permite detectar si un error de configuración está bloqueando silenciosamente correo legítimo; vigilar los informes de TLS-RPT permite desplegar la aplicación forzada con seguridad.

Ver todas las curiosidades