Herramientas de diagnóstico de red
Política de informes de TLS de SMTP
DNS y registros
Consulta DNS Todos los registros DNS de cualquier dominio Consulta de registro A Direcciones IPv4 de un dominio Consulta de registro AAAA Direcciones IPv6 de un dominio Consulta MX Servidores de correo de un dominio Consulta NS Servidores de nombres autoritativos Consulta TXT Registros TXT, SPF, verificación Consulta CNAME Registros de nombre canónico (alias) Consulta SOA Registro Start of Authority Consulta SRV Registros de localización de servicios Consulta CAA Qué CAs pueden emitir certificados DNS inverso (PTR) Dirección IP a nombre de host Comprobación DNSSEC ¿Está el dominio firmado y validado? Diagnóstico DNS Un informe completo de delegación y DNSEntregabilidad de correo
Comprobación SPF Valida tu registro Sender Policy Framework Comprobación DMARC Inspecciona y califica tu política DMARC Comprobación DKIM Encuentra y valida tu clave pública DKIM Comprobación de lista negra Comprueba una IP contra listas negras de correo (DNSBLs) Test SMTP Conecta a un servidor de correo y comprueba STARTTLS Comprobación MTA-STS Política TLS forzada para el correo entrante Comprobación BIMI Registro del logo de marca para el correo Comprobación TLS-RPT Política de informes de TLS de SMTPRed y web
Comprobación de certificado SSL Inspecciona el certificado TLS de un sitio y su caducidad Comprobación de cabeceras HTTP Inspecciona cabeceras de respuesta, redirecciones y seguridad Ping (TCP) Accesibilidad y latencia sobre TCP Comprobación de puertos Qué puertos comunes están abiertosDominio
Consulta WHOIS Datos de registro de dominios, IPs y ASNsTLS-RPT (SMTP TLS Reporting) permite que un dominio reciba informes diarios sobre fallos de conexión TLS de los servidores remitentes, para que detectes correo entregado de forma insegura. IPeek lee el registro TXT _smtp._tls y muestra los destinos de los informes. Complementa MTA-STS y DANE al darte visibilidad sobre cómo rinden esas políticas en el mundo real.
TLS-RPT se publica como un único registro DNS TXT en _smtp._tls.tu-dominio. El registro contiene una etiqueta de versión y una etiqueta rua= que indica dónde deben enviarse los informes, ya sea una dirección mailto o un endpoint HTTPS. Los servidores remitentes que admiten el estándar agregan los resultados de sus negociaciones TLS con tus hosts MX a lo largo de un día y entregan un informe JSON a esos destinos. Cada informe cuenta las sesiones exitosas y fallidas y categoriza los fallos, como errores de validación de certificado o la ausencia de STARTTLS, dándote un bucle de retroalimentación sobre la entrega real.
IPeek confirma si el registro TXT _smtp._tls existe y muestra los destinos rua que analiza. Verifica que la versión sea TLSRPTv1 y que cada destino rua sea un buzón válido o una URL HTTPS que realmente monitorices. El registro en sí no impone nada; solo solicita informes, así que su presencia significa que los remitentes saben dónde enviar los datos de fallos TLS. Cuando lleguen los informes, fíjate en los tipos de fallo: certificate-expired, fallos de validación y starttls-not-supported apuntan cada uno a un arreglo concreto en tu infraestructura receptora antes de que causen problemas de entrega silenciosos.
MTA-STS y DANE imponen TLS en el correo entrante, pero la aplicación solo es segura si puedes ver qué hace con el tráfico real. TLS-RPT aporta esa visibilidad: cuando despliegas MTA-STS en modo testing, los informes revelan qué remitentes encuentran fallos de TLS antes de que pases a enforce. Lo mismo aplica a las discrepancias TLSA de DANE. Considera TLS-RPT como la capa de monitorización de tu postura TLS, desplegada junto a los mecanismos de aplicación, no en su lugar, para que detectes problemas de certificados y configuración pronto.
Es un registro TXT publicado en _smtp._tls.tu-dominio que solicita informes de fallos TLS. El registro contiene una etiqueta de versión v=TLSRPTv1 y una etiqueta rua= que especifica dónde van los informes, como una dirección mailto o una URL HTTPS. Los servidores remitentes compatibles con TLS-RPT lo usan para saber dónde entregar sus informes agregados diarios sobre las conexiones TLS hacia tu dominio.
Un informe TLS-RPT es un documento JSON que resume un día de negociaciones TLS entre un servidor remitente y tus hosts MX. Cuenta las sesiones exitosas y fallidas y desglosa los fallos por tipo, como certificados caducados, errores de validación de certificado o la ausencia de STARTTLS. Esto te permite identificar qué hosts receptores o certificados están causando entregas inseguras o fallidas.
No. TLS-RPT es puramente un mecanismo de informes y no impone nada por sí solo. La aplicación viene de MTA-STS o DANE, que exigen TLS y pueden bloquear la entrega insegura. TLS-RPT se sitúa junto a esas políticas como una capa de monitorización, dándote visibilidad sobre con qué frecuencia TLS funciona o falla para que despliegues la aplicación con confianza.
Publica un registro TXT en _smtp._tls.tu-dominio que contenga v=TLSRPTv1 y una etiqueta rua= que apunte a un buzón o endpoint HTTPS que monitorices, por ejemplo rua=mailto:tlsrpt@tu-dominio. Elige un destino que realmente vigiles, ya que los informes llegan a diario como JSON. Combínalo con MTA-STS o DANE para que los informes describan cómo está rindiendo tu política TLS aplicada.
TLS-RPT aporta la visibilidad que hace seguro desplegar MTA-STS. Cuando publicas una política MTA-STS en modo testing, los servidores remitentes reportan cualquier fallo de TLS a través de TLS-RPT, así que ves qué remitentes quedarían bloqueados antes de pasar a enforce. Los dos están diseñados para trabajar juntos: MTA-STS fija la política, y TLS-RPT te dice cómo está rindiendo en la práctica.