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.
Consejos
- 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.
Preguntas frecuentes
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.