Comprobador de registros TLS-RPT
Herramienta gratuita de consulta de TLS-RPT: verifica al instante el registro DNS de informes TLS de SMTP de tu dominio, comprueba que cumple con la norma RFC 8460, asegúrate de que se ajusta a tu política MTA-STS y confirma que tus direcciones de informe pueden recibir realmente los informes.
Google
  • Google
  • Cloudflare
  • OpenDNS
  • Quad9
Introduce un dominio raíz: consultamos automáticamente el registro TXT en _smtp._tls, lo validamos y comprobamos tu emparejamiento MTA-STS.

¿Por qué debes comprobar tu registro TLS-RPT?

Incluso un servidor de correo configurado correctamente puede dejar de entregar los mensajes a través de TLS sin que se note. Un registro TLS-RPT es la única forma de detectar cuándo ocurre esto.

Detectar a tiempo los fallos de TLS
Descubre exactamente cuándo los servidores de envío de correo no pueden establecer una conexión cifrada con tu dominio, antes de que se convierta en un problema de entrega.
Comprueba que tu configuración de MTA-STS sea correcta
Los informes de TLS-RPT detectan cualquier fallo en las políticas o en las conexiones provocado por la aplicación de MTA-STS; esta herramienta lee tu política de MTA-STS en tiempo real para que puedas ver el emparejamiento.
Confirmar que los informes pueden llegar
Una dirección de notificación no sirve de nada si el correo no puede llegar a ella. Comprobamos que cada destino de la RUA cuente realmente con un lugar donde entregar los informes.

Cómo utilizar el verificador TLS-RPT

Una consulta TLS-RPT tarda unos segundos en realizarse. Sigue estos tres pasos para comprobar la configuración de los informes TLS de SMTP.

1
Introduce tu dominio. Escribe tu dominio raíz (p. ej., example.com) - no hace falta añadir el _smtp._tls prefijo, eso lo gestionamos automáticamente.
2
Elige un servidor de resolución y compruébalo. Elige entre Google, Cloudflare, OpenDNS o Quad9 y, a continuación, pulsa Intro o haz clic en «Comprobar registro» para consultar el DNS en tiempo real desde nuestro servidor.
3
Revisa los resultados. Validamos las etiquetas «version» y «rua» según la norma RFC 8460, comprobamos tu política MTA-STS emparejada y confirmamos que se puede acceder a cada destino de notificación.

¿Qué es un registro TLS-RPT?

La notificación SMTP TLS (TLS-RPT) es un estándar de correo electrónico definido en el RFC 8460 que permite a los propietarios de dominios recibir informes sobre fallos en la entrega de correo electrónico a través de una conexión TLS cifrada. Funciona junto con MTA-STS para detectar problemas —validación de certificados fallida, ataques de degradación, STARTTLS no compatible— que, de otro modo, pasarían desapercibidos.

Un único registro TXT
Publicado en _smtp._tls.yourdomain.com, indica a los servidores de correo de recepción dónde deben enviar los informes agregados sobre los intentos de conexión TLS.
Informar, no imponer
TLS-RPT no bloquea ni impone nada por sí mismo. Se trata únicamente de un canal de retroalimentación: la capa de visibilidad que se combina con MTA-STS.
Gratis y sin mucho esfuerzo
Solo hacen falta dos etiquetas. No es obligatorio, pero es una buena práctica que no cuesta nada y que subsana un verdadero punto ciego.
_smtp._tls.tudominio.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
; v -> identifica el registro como TLS-RPT (RFC 8460)
; rua -> lugar al que se envían los informes TLS agregados

TLS-RPT frente a MTA-STS: ¿Cuál es la diferencia?

MTA-STS (Mail Transfer Agent Strict Transport Security) es un mecanismo de aplicación: indica a los servidores de correo remitentes que tu dominio requiere una conexión válida y cifrada mediante TLS, y bloquea la entrega a través de conexiones no cifradas o mal configuradas. TLS-RPT es un mecanismo de notificación: no impone nada por sí mismo, sino que indica a los servidores de envío dónde deben notificar tanto los intentos de conexión TLS que han tenido éxito como los que han fallado, incluidos aquellos causados por tu política MTA-STS.

Ambos están diseñados para funcionar conjuntamente: MTA-STS garantiza el cifrado, y TLS-RPT te proporciona el bucle de retroalimentación necesario para saber si esa aplicación está causando problemas de entrega. Por eso, esta herramienta de comprobación también analiza tu política de MTA-STS: así podrás confirmar que ambos aspectos coinciden. Puedes profundizar en el aspecto de la aplicación con nuestra herramienta de comprobación de registros MTA-STS.

Explicación de las etiquetas TLS-RPT

Cada registro TLS-RPT se compone de un pequeño conjunto de etiquetas. A continuación se explica el significado de cada una de ellas.

v=
Versión (obligatorio)

Identifica el registro como un registro TLS-RPT. Debe ser la primera etiqueta y estar siempre establecida en TLSRPTv1.

rua=
URI del informe agregado (obligatorio)

Lugar al que se envían los informes TLS agregados. Acepta un mailto: dirección, un https:// punto final, o una lista separada por comas de ambos.

Problemas habituales con TLS-RPT y cómo solucionarlos

A continuación se explican los problemas que suelen surgir con una configuración TLS-RPT y lo que cada resultado significa para tu dominio.

No se ha encontrado ningún registro
No hay nada en _smtp._tls
No existe ningún registro TXT en el servidor correcto, por lo que no recibes ningún informe de error de entrega TLS.
Publica un registro TXT en _smtp._tls.tudominio.com con las etiquetas v= y rua= válidas.
Etiqueta «v=» mal formada
No se reconoce como TLS-RPT
El registro no comienza con «v=TLSRPTv1», por lo que los servidores de correo no lo tratarán como un registro TLS-RPT.
Establece v=TLSRPTv1 como la primera etiqueta exacta del registro.
Falta «rua=» o es inválido
Los informes no tienen adónde ir
No se ha definido ningún destino para los informes, o bien el URI «mailto» o «https» tiene un formato incorrecto, por lo que no es posible enviar los informes.
Añade al menos un URI válido del tipo «mailto:» o «https:» y comprueba que el destinatario pueda recibirlo.
Varios registros
Más de un registro TLS-RPT
El RFC 8460 no permite que haya dos o más registros TLS-RPT en el mismo host, lo que podría provocar errores de validación.
Consolidar en un único registro TLS-RPT, con todos los destinos en una sola etiqueta «rua».

Cómo interpretar tus informes TLS-RPT

Una vez que tu registro esté activo, los servidores de correo receptores empezarán a enviar informes agregados periódicos a tu destino RUA. Esto es lo que contienen.

Detalles de la póliza
El tipo de política vigente (p. ej., sts, no-policy-found) para el dominio remitente al que se refiere el informe.
Recuento resumido
Total de intentos de conexión TLS exitosos y fallidos durante el periodo de referencia, que suele ser de 24 horas.
Detalles del fallo
Tipos de errores clasificados —certificado caducado, nombre de host no coincidente, STARTTLS no compatible— con ejemplos de direcciones IP de origen.

Los informes JSON sin procesar resultan difíciles de leer a gran escala, sobre todo cuando se reciben de docenas de proveedores de correo diferentes. La plataforma de PowerDMARC analiza automáticamente los informes TLS-RPT y los presenta en un panel de control fácil de leer, junto con tus datos de DMARC, SPF y MTA-STS.

Cómo publicar un registro TLS-RPT

Inicia sesión en tu proveedor de DNS y añade un nuevo registro TXT con estos valores.

Host / Nombre
_smtp._tls
Tipo
TXT
TTL
3600 (por defecto)
Propagación
Hasta 48 horas
Valor
v=TLSRPTv1; rua=mailto:[email protected]

Los cambios en el DNS pueden tardar hasta 48 horas en propagarse por completo, aunque la mayoría de los proveedores los actualizan en unas pocas horas. Una vez que estén activos, utiliza el verificador de arriba para confirmar que se han publicado correctamente.

Preguntas frecuentes

¿Es TLS-RPT lo mismo que DMARC?
No. Los informes DMARC recogen los errores de autenticación (SPF/DKIM) en los mensajes enviados desde tu dominio. Los informes TLS-RPT recogen específicamente los errores al establecer una conexión TLS cifrada cuando se entrega el correo a tu dominio. Se trata de estándares complementarios, pero independientes.
¿Se envían los datos de mi dominio a vuestros servidores?
El dominio que introduzcas se envía a nuestro servidor, que realiza la consulta DNS por ti utilizando el resolutor público que elijas; es la misma consulta que cualquiera podría realizar con un dig comando. No registramos ni almacenamos los dominios que consultes ni los registros que se devuelvan.
¿Necesito MTA-STS para utilizar TLS-RPT?
No, TLS-RPT se puede implementar por sí solo. Sin embargo, resulta más útil cuando se combina con MTA-STS, ya que informa de cualquier fallo en la conexión o en la política que provoque la aplicación de MTA-STS. Este verificador también revisa tu política de MTA-STS para que puedas comprobar cómo se complementan ambos.
¿Es obligatorio el TLS-RPT?
No, TLS-RPT es opcional y ningún proveedor importante de correo electrónico lo exige. Se trata de una forma gratuita y sencilla de detectar problemas de entrega TLS que, de otro modo, pasarían desapercibidos, y se considera una práctica recomendada junto con DMARC, SPF, DKIM y MTA-STS.
¿Puedo utilizar varias direcciones RUAs?
Sí. Puedes indicar varios destinos separados por comas, mezclando los URI «mailto:» y «https:»; por ejemplo: rua=mailto:[email protected],https://reports.example.com/tlsrpt. Esta herramienta comprueba cada una de ellas y verifica que los destinatarios de correo electrónico puedan recibir realmente los mensajes.
¿Se pueden enviar los informes a un dominio distinto al mío?
Sí. A diferencia de DMARC, la RFC 8460 no define ningún registro de autorización de destino externo para TLS-RPT, por lo que puedes configurar rua para que apunte a un procesador de terceros (como PowerDMARC) sin necesidad de realizar ninguna configuración adicional en el DNS. Esta herramienta marca los destinos externos para mayor claridad, pero son perfectamente válidos.
¿Por qué aparece mi registro TLS-RPT como «no encontrado»?
O bien el registro aún no se ha publicado, los cambios en el DNS no se han propagado por completo o el registro se ha añadido en un host incorrecto; debe ser exactamente _smtp._tls.yourdomain.com, y no solo tudominio.com.
¿Puedo utilizar un punto final HTTPS en lugar del correo electrónico para los informes?
Sí. El RFC 8460 admite tanto los URI de envío de informes «mailto:» como «https:». Un punto final «https» debe aceptar solicitudes HTTP POST que incluyan el informe como una carga útil JSON comprimida con gzip; esto suele ser habitual en organizaciones de mayor tamaño o en plataformas como PowerDMARC, que procesan los informes de forma automática.

Automatiza la autenticación de tu correo electrónico

PowerDMARC supervisa tus registros DMARC, SPF, DKIM, BIMI, MTA-STS y TLS-RPT en un único panel de control, con alertas en cuanto se produce algún fallo.

Reserva una demostración Empieza tu prueba de 15 días