Diez herramientas gratuitas para comprobar direcciones IP, DNS y correo electrónico
Ya están disponibles seis nuevas herramientas gratuitas en ReportedIP: Reverse DNS con confirmación directa, un buscador de contactos de abuso RDAP, una comprobación de Security Headers HTTP, verificación de rastreadores, un informe de ASN y redes, y MTA-STS, TLS-RPT y BIMI dentro de la comprobación de correo electrónico ya existente. Con ellas ya son diez las herramientas gratuitas, ninguna de las cuales requiere crear una cuenta.
Las diez se enumeran en reportedip.com/tools. El resto de esta entrada trata sobre los cuatro controles que hay detrás de ellas, que son fáciles de implementar, pero también es fácil implementarlos de forma incorrecta.
Para qué sirven las seis nuevas herramientas
| Herramienta | Entrada | A qué responde |
|---|---|---|
| Reverse DNS | IPv4, IPv6 o nombre de host | ¿Supera el PTR Record la comprobación hacia adelante? |
| Contacto de abuso | Dirección IP o dominio | ¿Qué buzón se encarga de esta dirección? |
| Cabeceras de seguridad | Dominio o URL | Qué directiva modificar, en función de su impacto |
| Verificación de bots | IP, User-Agent (opcional) | ¿Es el rastreador que se autoproclama como tal el auténtico? |
| Informe de ASN | Número IP o AS | Cómo se comporta toda la red, no una sola dirección |
| Comprobación de seguridad del correo | Dominio | SPF, DKIM, DMARC, DNSSEC, MTA-STS, TLS-RPT, BIMI |
¿Por qué un registro «A» no es suficiente para el Reverse DNS?
Un PTR Record por sí solo no prueba nada. Cualquiera que controle un bloque de direcciones puede publicar cualquier nombre en él, incluido mail.yourbank.com. La comprobación que realmente cuenta es el Forward-confirmed reverse DNS: resolver el nombre PTR en direcciones y comprobar si la dirección original se encuentra entre ellas.
Un error habitual en la implementación es comparar únicamente con el primer registro A. Según las mediciones realizadas el 20 de septiembre de 2026, 8.8.8.8 el nombre PTR es dns.google, y ese nombre se resuelve en cuatro direcciones:
8.8.8.8 -> dns.google -> 8.8.8.8, 8.8.4.4,
2001:4860:4860::8888, 2001:4860:4860::8844
8.8.4.4 -> dns.google -> las mismas cuatro direcciones
66.249.66.1 -> crawl-66-249-66-1.googlebot.com -> 66.249.66.1
Una herramienta que se detiene en la primera respuesta indica 8.8.4.4 como no confirmada, ya que el DNS devolvió 8.8.8.8 primero. Hay que comparar el conjunto completo de registros A y AAAA, y la comparación debe realizarse en formato binario a través de inet_pton(), nunca como cadena de caracteres. 2001:db8::1 y 2001:0db8:0000:0000:0000:0000:0000:0001 son la misma dirección y difieren en todos los caracteres.
La verificación de los rastreadores cambió con la llegada de los bots de IA
El encabezado «User-Agent» es texto libre. Por ello, todos los grandes operadores publican un método para verificar sus rastreadores y, durante dos décadas, ese método fue el Forward-confirmed reverse DNS. Esto ya no es así para la mitad de los rastreadores que merece la pena comprobar.
De los diez rastreadores que conoce el bot de comprobación, cinco realizan la verificación mediante DNS y cinco mediante una lista de direcciones publicada:
- Forward-confirmed reverse DNS: Googlebot, Bingbot, Applebot, YandexBot, Baiduspider
- Rangos de direcciones publicados: DuckDuckBot, GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot
La división discurre casi exactamente a lo largo de la línea que separa los motores de búsqueda clásicos de la generación de rastreadores basados en IA. OpenAI, Perplexity y Anthropic documentan archivos JSON con rangos de direcciones y no incluyen los nombres PTR en su método. Una comprobación realizada el 20 de septiembre de 2026 no encontró ningún PTR Record en 20.171.207.1, dentro del rango que OpenAI publica para GPTBot.
La consecuencia práctica: un verificador que solo conozca el método DNS marcará todos los rastreadores de IA como «sin confirmar», que es el mismo veredicto que otorga a una falsificación. La herramienta distingue entre ambos y indica qué método se aplica al operador en cuestión. Google documenta su propio procedimiento en la guía de verificación de Googlebot.
Por qué el número de informes por sí solo no dice nada sobre una red
A fecha de 20 de septiembre de 2026, la base de datos de la comunidad contenía 766.987 direcciones y 6.933.661 Reports repartidos en 19.827 redes y 225 países. Al clasificar esas redes según el número total de Reports, se obtiene una lista de los mayores proveedores de alojamiento, lo cual es un indicador de su tamaño, pero no de cómo se gestionan.
| Red | Direcciones conocidas | Reports | Por dirección |
|---|---|---|---|
| AS14061 DigitalOcean | 21.444 | 604.109 | 28,2 |
| AS396982 Google Cloud | 36.444 | 387.685 | 10,6 |
| AS174 Cogent | 365 | 238.668 | 653,9 |
| AS47890 Unmanaged Ltd | 260 | 169.449 | 651,7 |
DigitalOcean lidera en cuanto al número total de Reports. Cogent se sitúa dos puestos por debajo, con 365 direcciones conocidas, y cada una de ellas acumula 23 veces más Reports que una dirección de DigitalOcean. Se trata de dos situaciones diferentes, y la columna «Total» oculta esa diferencia.
Por lo tanto, el informe compara cada red con el resto de redes de los datos en dos aspectos: cuántas direcciones se conocen en cada una y cuántos Reports contiene cada una de ellas. Un gran proveedor ocupa un puesto alto en el primer aspecto y bajo en el segundo. Una red concentrada hace lo contrario, y ese es el patrón sobre el que conviene actuar. Bloquear un rango completo es una decisión que la segunda cifra respalda y la primera no.
RDAP devuelve la asignación más restrictiva, no la más amplia
Una denuncia de abuso enviada al bloque equivocado equivale a no presentar ninguna denuncia. Una dirección concreta suele encontrarse dentro de la asignación de un proveedor de alojamiento, que a su vez forma parte de la asignación de un proveedor de tránsito, la cual pertenece a un Registry regional. Solo el operador más interno puede desconectar el equipo de la red.
No existe un directorio central del espacio de direcciones. La IANA publica un archivo de arranque que asocia los prefijos asignados al Registry correspondiente, y su tamaño es menor de lo que sugieren la mayoría de las estimaciones: ipv4.json tenía 5.629 bytes y ipv6.json 1.476 bytes cuando se midió el 20 de septiembre de 2026, por lo que almacenarlo en caché durante un día no supone ningún coste.
Hay dos detalles que determinan si la respuesta es válida. La coincidencia del prefijo debe ser la «coincidencia más larga» y no la «primera coincidencia», ya que un pequeño rango dentro de una antigua asignación de gran tamaño suele pertenecer a un Registry diferente al de su padre. Además, la dirección de abuso debe proceder de la entidad de contacto que ostenta el rol de abuso, y no del primer contacto que aparezca en la respuesta RDAP. La herramienta devuelve el buzón, el bloque de red, el titular, el país y un borrador de informe con los datos conocidos ya rellenados. No se envía nada desde la página.
Qué implica la comprobación del encabezado y por qué «max-age=0» es peor que nada
Las listas de comprobación de encabezados suelen considerar cada encabezado que falta como una marca roja. La ausencia de un encabezado «Permissions-Policy» no supone un problema de la misma gravedad que la ausencia de un «Content-Security-Policy», por lo que la puntuación se pondera de la siguiente manera: CSP 25, HSTS 20, protección contra framing 15, X-Content-Type-Options 15, Referrer-Policy 10, Permissions-Policy 10 y 5 por la divulgación de la versión a través de Server o X-Powered-By.
max-age=0se penaliza más que la ausencia del encabezado HSTS. Es la forma documentada de desactivar HSTS, por lo que todos los visitantes vuelven a utilizar HTTP sin cifrar en su siguiente primera solicitud. Un sitio web que nunca haya enviado el encabezado, al menos, nunca ha prometido nada.frame-ancestorscuenta como protección contra el framing. Es el sustituto especificado de X-Frame-Options, y un sitio web que lo configure correctamente no debería ser penalizado por prescindir del encabezado anterior.- Cada resultado indica la directiva que hay que modificar, no solo el encabezado que falta.
La comprobación del correo electrónico sigue el mismo principio. La autenticación determina si otra persona puede enviar correo en nombre de tu dominio, por lo que DMARC cuenta con 25 puntos, SPF y DKIM con 20 cada uno, DNSSEC con 15, MTA-STS con 12 y TLS-RPT con 8. BIMI obtiene 0 puntos por su propia naturaleza: se trata de un logotipo y no influye en absoluto en la fiabilidad de un mensaje. Encontrarás más detalles en los documentación de integración.
IPv6, límites y qué se almacena
130.865 de las 766.987 direcciones de la base de datos son IPv6, por lo que la comprobación de la Blacklist ahora convierte las direcciones IPv6 al formato de nibble que especifica el RFC 5782. Nueve de las doce listas seleccionadas dan respuesta para IPv6; las otras tres solo se consultan para IPv4 y así lo indican en el resultado, en lugar de mostrar una falta de coincidencia sin aviso.
El DNS Checker realiza comprobaciones en 101 servidores de resolución activos repartidos por 52 países de los 6 continentes. Las diez herramientas comparten un mismo límite diario: 30 comprobaciones para visitantes sin cuenta y 100 para usuarios registrados, contabilizadas por dirección. Las consultas no se almacenan en relación con tu dirección, y ninguna herramienta se pone en contacto con la dirección que consultes.
Preguntas que nos hacen sobre estos cheques
¿El hecho de que falle la confirmación de reenvío significa que el rastreador es falso?
No por sí solo. Significa que el método DNS no ha encontrado nada que lo confirme. Para Googlebot, Bingbot, Applebot, YandexBot y Baiduspider, eso es una señal clara, ya que esos operadores publican nombres PTR. Para GPTBot, PerplexityBot, ClaudeBot y DuckDuckBot es lo esperado, y el método que se aplica es la lista de direcciones.
¿Por qué el contacto de abuso difiere de lo que aparece en WHOIS?
WHOIS devuelve texto libre y, por lo general, la asignación más amplia. RDAP devuelve datos estructurados, y la búsqueda sigue la cadena hasta llegar a la asignación más específica. Normalmente se trata de un bloque más pequeño con un buzón diferente y más cercano.
¿Una red con muchos informes es necesariamente mala?
N.º 2. Dos de las redes más densas de los datos son los servicios de escaneo ONYPHE (226,1 Reports por dirección) y Censys (265,8). Generan Reports porque escanean Internet de forma intencionada, no porque hayan sido comprometidos. Los informes por dirección muestran dónde se concentra el uso indebido; para entender lo que esto significa, es necesario contar con el contexto que aporta el operador.
¿A dónde ir ahora?
- Las diez herramientas gratuitas y no es necesario crear una cuenta
- Cómo sacar una dirección de una lista si eres el destinatario
- API Reference para los mismos datos que se utilizan en las herramientas
Todas las cifras de esta entrada se han calculado en función de la producción del 20 de septiembre de 2026 y se indican con esa fecha para que puedan contrastarse con los datos actuales.