Dix outils gratuits pour vérifier les adresses IP, les paramètres DNS et les adresses e-mail

Six nouveaux outils gratuits sont désormais disponibles sur ReportedIP.com : la recherche Reverse DNS avec confirmation en amont, un outil de recherche de contacts abuse pour signaler les abus RDAP, une vérification des en-têtes de sécurité HTTP, une vérification des robots d’indexation, un rapport sur les ASN et les réseaux, ainsi que les fonctionnalités MTA-STS, TLS-RPT et BIMI intégrées à l’outil de vérification des e-mails existant. Cela porte à dix le nombre d’outils gratuits, dont aucun ne nécessite de créer un compte.

Ces dix points sont répertoriés sur reportedip.com/tools. La suite de cet article porte sur les quatre vérifications qui les sous-tendent, faciles à mettre en œuvre mais où l’on peut facilement se tromper.

Fonctionnalités des six nouveaux outils

Outil	Saisie	À quoi cela répond-il ?
Reverse DNS	IPv4, IPv6 ou nom d’hôte	The PTR Record survives a forward check.
Contact abuse	Adresse IP ou nom de domaine	Quelle boîte aux lettres correspond à cette adresse ?
En-têtes de sécurité	Nom de domaine ou URL	Quelle directive modifier, en fonction de l’impact
Vérification des bots	Adresse IP, User-Agent facultatif	Ce robot d’indexation qui se présente comme tel est-il le vrai ?
Rapport ASN	Numéro IP ou AS	Le comportement de l’ensemble du réseau, et non celui d’une seule adresse
Vérification de la sécurité des e-mails	Domaine	SPF, DKIM, DMARC, DNSSEC, MTA-STS, TLS-RPT, BIMI

Pourquoi un seul enregistrement « A » ne suffit pas pour le Reverse DNS

Un PTR Record ne prouve rien en soi. Toute personne contrôlant un bloc d’adresses peut y publier n’importe quel nom, y compris mail.yourbank.com. La vérification qui a du poids est celle du Forward-confirmed reverse DNS : résoudre le nom PTR en adresses et vérifier si l’adresse d’origine figure parmi elles.

Une erreur courante lors de la mise en œuvre consiste à ne comparer qu’avec le premier enregistrement de type A. D’après les mesures effectuées le 20 septembre 2026, 8.8.8.8 le nom PTR est dns.google, et ce nom renvoie quatre adresses :

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 -> les quatre mêmes adresses
66.249.66.1  -> crawl-66-249-66-1.googlebot.com -> 66.249.66.1

Un outil qui s’arrête à la première réponse est considéré 8.8.4.4 comme non confirmée, car le DNS a renvoyé 8.8.8.8 en premier. L’ensemble complet des enregistrements A et AAAA doit être comparé, et cette comparaison doit se faire sous forme binaire via inet_pton(), jamais sous forme de chaîne de caractères. 2001:db8::1 et 2001:0db8:0000:0000:0000:0000:0000:0001 correspondent à la même adresse et diffèrent à chaque caractère.

La vérification par les robots d’indexation a évolué avec l’arrivée des bots IA

L’en-tête « User-Agent » est un champ libre. Chaque grand opérateur publie donc une méthode permettant de vérifier ses robots d’indexation, et pendant deux décennies, cette méthode consistait à vérifier la validité du Forward-confirmed reverse DNS. Ce n’est désormais plus le cas pour la moitié des robots d’indexation qu’il convient de vérifier.

Sur les dix robots d’indexation répertoriés par le test de détection de bots, cinq effectuent leur vérification via le DNS et cinq via une liste d’adresses publiée :

Forward-confirmed reverse DNS : Googlebot, Bingbot, Applebot, YandexBot, Baiduspider
Plages d’adresses publiées : DuckDuckBot, GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot

Cette distinction correspond presque exactement à la frontière entre les moteurs de recherche classiques et la nouvelle génération de robots d’indexation basés sur l’IA. OpenAI, Perplexity et Anthropic répertorient des fichiers JSON contenant des plages d’adresses et n’intègrent pas les noms PTR dans leur méthode. Une vérification effectuée le 20 septembre 2026 n’a révélé aucun PTR Record sur 20.171.207.1, dans la plage publiée par OpenAI pour GPTBot.

Conséquence pratique : un vérificateur qui ne connaît que la méthode DNS classera tous les robots d’indexation basés sur l’IA comme « non confirmés », ce qui correspond au même verdict que celui attribué à une contrefaçon. L’outil fait la distinction entre les deux et précise quelle méthode s’applique à l’opérateur en question. Google détaille sa propre procédure dans le guide de vérification de Googlebot.

Pourquoi le nombre de rapports à lui seul ne dit rien sur un réseau

Au 20 septembre 2026, la base de données communautaire comptait 766 987 adresses et 6 933 661 Reports répartis sur 19 827 réseaux et 225 pays. Le classement de ces réseaux en fonction du nombre total de signalements permet d’établir une liste des plus grands hébergeurs, ce qui donne une indication sur leur taille, mais pas sur leur mode de fonctionnement.

Réseau	Adresses connues	Reports	Par adresse
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 arrive en tête en nombre total de Reports. Cogent se classe deux places plus bas, avec 365 adresses répertoriées, chacune d’entre elles faisant l’objet de 23 fois plus de Reports qu’une adresse DigitalOcean. Il s’agit là de deux situations différentes, et la colonne « Total » masque cette différence.

Le rapport compare donc chaque réseau des données à l’aide de deux indicateurs : le nombre d’adresses répertoriées et le nombre de Reports associés à chacune d’entre elles. Un grand fournisseur se classe en tête pour le premier indicateur et en bas du classement pour le second. Un réseau concentré présente l’inverse, et c’est cette tendance qui mérite d’être prise en compte. Le blocage d’une plage entière est une décision que le deuxième chiffre justifie, mais pas le premier.

RDAP renvoie l’allocation la plus étroite, et non la plus large

Un signalement abuse envoyé au mauvais bloc revient à ne pas en envoyer du tout. Une adresse unique se trouve généralement dans l’allocation d’un hébergeur, qui fait elle-même partie de l’allocation d’un fournisseur de transit, laquelle appartient à un Registry régional. Seul l’opérateur le plus en amont peut déconnecter la machine du réseau.

Il n’existe pas de répertoire central de l’espace d’adressage. L’IANA publie un fichier de démarrage qui met en correspondance les préfixes attribués et le Registry compétent ; sa taille est inférieure à ce que la plupart des estimations laissent entendre : ipv4.json il faisait 5 629 octets et ipv6.json 1 476 octets lors des mesures effectuées le 20 septembre 2026 ; sa mise en cache pendant une journée ne coûte donc rien.

Deux détails déterminent si la réponse est exploitable. La correspondance de préfixe doit être la « correspondance la plus longue » plutôt que la « première correspondance », car une petite plage au sein d’une ancienne allocation de grande taille appartient souvent à un Registry différent de celui de son parent. Et l’adresse d’abus doit provenir de l’entité de contact assumant le rôle d’abus, et non du premier contact apparaissant dans la réponse RDAP. L’outil renvoie la boîte aux lettres, le bloc réseau, le titulaire, le pays et un brouillon de rapport dans lequel les faits connus sont déjà renseignés. Aucune information n’est envoyée depuis la page.

Ce que prend en compte la vérification de l’en-tête, et pourquoi « max-age=0 » est pire que rien

Les listes de contrôle des en-têtes ont tendance à considérer chaque en-tête manquant comme une marque rouge. L’absence d’un en-tête « Permissions-Policy » ne constitue pas un problème aussi grave que celle d’un en-tête « Content-Security-Policy » ; le score est donc pondéré : CSP 25, HSTS 20, protection contre le framing 15, X-Content-Type-Options 15, Referrer-Policy 10, Permissions-Policy 10 et 5 pour la divulgation de la version via Server ou X-Powered-By.

max-age=0 est signalé plus sévèrement qu’un en-tête HSTS manquant. Il s’agit de la méthode officielle pour désactiver HSTS ; ainsi, chaque visiteur est redirigé vers le protocole HTTP standard dès sa prochaine première requête. Un site qui n’a jamais envoyé cet en-tête n’a, au moins, jamais fait de promesse.
frame-ancestors est considéré comme une protection contre l’encadrement. Il s’agit du remplacement officiel de l’en-tête X-Frame-Options, et un site qui le configure correctement ne devrait pas être pénalisé pour avoir supprimé l’ancien en-tête.
Chaque résultat indique le nom de la directive à modifier, et pas seulement l’en-tête manquant.

La vérification des e-mails repose sur le même principe. L’authentification détermine si un tiers peut envoyer des e-mails au nom de votre domaine ; ainsi, DMARC rapporte 25 points, SPF et DKIM 20 chacun, DNSSEC 15, MTA-STS 12 et TLS-RPT 8. Le BIMI obtient un score de 0 par nature : il s’agit d’un logo qui n’a aucune incidence sur la fiabilité d’un message. Vous trouverez plus de détails dans les documentation d’intégration.

IPv6, ses limites et les données stockées

Sur les 766 987 adresses de la base de données, 130 865 sont des adresses IPv6 ; c’est pourquoi la vérification par Blacklist convertit désormais les adresses IPv6 au format « nibble » spécifié par la RFC 5782. Neuf des douze listes gérées prennent en charge l’IPv6 ; les trois autres ne sont interrogées que pour l’IPv4 et l’indiquent dans le résultat au lieu de signaler un échec silencieux.

The DNS Checker performs queries against 101 active resolvers distributed in 52 countries on 6 continents. The ten tools share a daily budget: 30 queries for visitors without a account, 100 queries for logged-in users, counted per address. The queries are not stored in association with your address, and no tool contacts the address you consult.

Questions qui nous sont posées au sujet de ces chèques

Une confirmation de transfert échouée signifie-t-elle que le robot d’indexation est un faux ?

Pas en soi. Cela signifie que la méthode DNS n’a rien trouvé qui permette de le confirmer. Pour Googlebot, Bingbot, Applebot, YandexBot et Baiduspider, c’est un signal fort, car ces opérateurs publient des noms PTR. Pour GPTBot, PerplexityBot, ClaudeBot et DuckDuckBot, c’est normal, et la méthode de la liste d’adresses s’applique.

Pourquoi le contact abuse diffère-t-il des coordonnées indiquées dans le WHOIS ?

WHOIS renvoie du texte libre et, en général, l’attribution la plus large. RDAP renvoie des données structurées, et la recherche remonte la chaîne jusqu’à l’attribution la plus spécifique. Il s’agit généralement d’un bloc plus petit associé à une boîte aux lettres différente et plus proche.

Un réseau comportant de nombreux Reports est-il automatiquement considéré comme mauvais ?

Non. Les deux réseaux les plus denses dans les données sont les services d’analyse ONYPHE (226,1 rapports par adresse) et Censys (265,8). Ils génèrent des rapports parce qu’ils analysent Internet de manière intentionnelle, et non parce qu’ils ont été compromis. Le nombre de signalements abuse par adresse indique où se concentrent les abus ; pour en comprendre la signification, il faut toutefois se référer au contexte propre à chaque opérateur.

Où aller ensuite ?

Les dix outils gratuits, sans inscription requise
Comment faire retirer une adresse d’une liste si vous en êtes la cible
API Reference for the same data used by the tools

Tous les chiffres présentés dans cet article ont été calculés par rapport à la production du 20 septembre 2026 et sont accompagnés de cette date afin de pouvoir être recoupés avec les données actuelles.