Comprobador gratuito de registros TLS-RPT

Lee el registro TLS-RPT que un dominio publica en _smtp._tls, compruébalo según el RFC 8460 y mira exactamente adónde se envían sus informes de TLS. Funciona gratis en tu navegador sobre DNS-over-HTTPS, sin registro y sin guardar nada.

Detecta los problemas antes de que te cuesten caro.

Crea una cuenta gratuita de Unspam para guardar tus resultados y repetir estas comprobaciones cuando quieras, así detectas una configuración rota antes de que te cueste caro. Sin tarjeta de crédito.

¿Qué es TLS-RPT?

TLS-RPT es un registro DNS que pide a los servidores de correo receptores que te cuenten cómo fue el cifrado cuando te entregaron correo. Los servidores compatibles envían un resumen una vez al día en el que indican cuántas conexiones negociaron TLS correctamente y cuántas fallaron, con el motivo. Publicarlo no cambia nada de cómo se entrega tu correo: es un canal de retorno, no una política. Lo que te da es enterarte de que ha caducado un certificado, de que un servidor de correo ha dejado de ofrecer STARTTLS o de que una política MTA-STS está fallando, antes de que te lo diga un cliente. El registro es una sola línea, vive en _smtp._tls bajo tu dominio, y este comprobador lo lee entero, porque a diferencia de MTA-STS no hay una segunda mitad detrás de un servidor web al que un navegador no puede llegar.

Cómo interpretar tu resultado

  • v=TLSRPTv1

    La versión, que debe ser lo primero del registro y debe escribirse exactamente así. El RFC 8460 la define como texto sensible a mayúsculas y dice a los remitentes que descarten todo lo que no empiece por v=TLSRPTv1 seguido de un punto y coma, así que v=tlsrptv1 no es una errata con consecuencias estéticas: es un registro que nadie lee.

  • rua=

    Adónde van los informes. Admite una dirección o una lista separada por comas, y solo se permiten dos tipos: mailto: para un buzón y https: para un punto final que acepte un POST. Los informes son JSON comprimido con gzip y llegan aproximadamente a diario desde cada proveedor compatible con el estándar.

  • Exactamente un registro

    Si un remitente encuentra más de un registro TLS-RPT en el nombre, el RFC 8460 dice que debe tratar el dominio como si no implementara TLS-RPT en absoluto. Dos registros no son una copia de seguridad, son un interruptor de apagado, que es la misma regla que usan SPF y DMARC y el mismo error que se comete al añadir un segundo registro en lugar de editar el primero.

  • Cualquier otra cosa

    El estándar define un hueco de extensión para campos futuros y dice a los remitentes que ignoren cualquier campo que no reconozcan, así que una etiqueta desconocida nunca puede romper un registro. En todos los proveedores de buzones, retransmisores y operadores de alojamiento con los que se ha probado este comprobador, ningún registro real lleva nada más allá de la versión y rua.

Problemas habituales y cómo solucionarlos

La etiqueta de versión está en la caja equivocada

v=tlsrptv1 o v=TLSRPTV1 parecen correctos y no recogen nada. El registro se descarta antes de analizarse, así que no hay error en ninguna parte: los informes simplemente no llegan nunca, y el único síntoma es un silencio que no esperabas que estuviera roto.

Dos registros en _smtp._tls

Suele ser el resultado de añadir un registro nuevo durante una migración en lugar de editar el antiguo. Apaga los informes en vez de enviarlos a ambos. Deja un solo registro que liste los dos destinos en su rua.

Una coma o un signo de exclamación sin codificar

La coma separa la lista de destinos, así que una coma sin codificar dentro de una dirección la parte en dos. El signo de exclamación es el sufijo de límite de tamaño de DMARC, que TLS-RPT no tiene, y debe escribirse como %21. Ambos deben ir codificados en porcentaje y ambos estropean la lista de destinos en silencio.

Un destino http en lugar de https

Solo existen mailto y https. Un punto final http normal no es un esquema que vaya a usar ningún remitente, así que los informes se descartan en lugar de degradarse.

El buzón de informes que nadie lee

Los informes de TLS llegan como JSON comprimido con gzip, a diario, desde cada proveedor compatible con el estándar. Apuntados a un buzón compartido se convierten en ruido en una semana. Apúntalos a un buzón o a un servicio de análisis que los procese, o el registro no está haciendo nada útil.

Esperar que TLS-RPT imponga algo

Informa, no exige. Si quieres que los servidores receptores insistan en usar TLS cuando te entregan correo, eso es MTA-STS o DANE. TLS-RPT es como averiguas si alguno de los dos funciona, y por eso se despliegan juntos habitualmente.

Tus dudas, resueltas.

¿Publicar TLS-RPT cambia cómo se entrega mi correo?
No. Pide a los servidores receptores un informe diario sobre cómo fue la negociación TLS, y nada de eso cambia el enrutamiento, el filtrado ni si se acepta un mensaje. Se puede publicar sin riesgo en cualquier dominio.
¿Necesito MTA-STS para que TLS-RPT sea útil?
No, pero funcionan bien juntos. Sin una política, los informes te dicen con qué frecuencia funciona el TLS oportunista. Con ella, te dicen cuándo está fallando la política, que es la parte que no puedes ver de ninguna otra forma.
¿Puedo enviar los informes a un tercero?
Sí, y a diferencia de DMARC no requiere ninguna configuración por su parte. Una dirección rua de DMARC en otro dominio tiene que publicar un registro de autorización antes de que se envíen los informes; el RFC 8460 no tiene ese paso, así que un destino TLS-RPT se acepta solo con que tú lo indiques.
¿Por qué mi registro aparece como no leído como TLS-RPT?
Casi siempre es la etiqueta de versión. Tiene que leerse exactamente v=TLSRPTv1 seguido de un punto y coma, con esas mayúsculas, y los remitentes descartan el registro en lugar de repararlo. Vuelve a publicarlo con la forma exacta y los informes empezarán a llegar.
¿La comprobación es en vivo?
Sí. Consulta el DNS actual mediante DNS-over-HTTPS directamente desde tu navegador, sin registro y sin guardar nada. Para ver cómo se autentica el correo que envías, ejecuta una comprobación de salud del correo gratuita.

Un registro correcto es solo el primer paso. Descubre dónde llega de verdad tu correo.