Aller au contenu principal

Vérifiez si votre IP figure sur les DNSBL qui bloquent réellement vos e-mails

Inverser les octets, interroger la zone, lire le code 127.0.0.x, sur 8 zones DNSBL sur le Mac, 10 sur iPhone et iPad.

Par Lucas Russo, développeur de SSHive · Mis à jour le

Des messages qui passaient hier rebondissent aujourd'hui. Le journal SMTP affiche un rejet 5.7.1 avec une URL enfouie dedans, ou pire, rien du tout : le serveur distant a accepté le message puis l'a fait disparaître. La première question est toujours la même : l'IP émettrice est-elle sur une liste noire, et si oui, laquelle ? Une DNSBL (liste noire diffusée par DNS, encore souvent appelée RBL) répond en une requête DNS par zone. Aucune API, aucun compte, aucun scraping. On inverse les quatre octets de l'adresse, on y accole le domaine de la zone, on demande un enregistrement A. Un NXDOMAIN signifie « non listée ». Une réponse dans 127.0.0.0/8 signifie « listée », et l'octet de poids faible indique quelle sous-liste vous a attrapé, et pourquoi. Le piège, c'est que la réponse n'a de valeur que si l'on interroge les bonnes zones et que l'on sait lire ce que chacune raconte. Il existe des centaines de listes publiques ; une poignée seulement est réellement consultée par les serveurs de messagerie qui comptent, et parmi les autres, certaines sont agressives, obsolètes ou purement et simplement arrêtées. Un outil qui annonce « listée sur 3 des 100 listes » sans nommer les trois est pire qu'une absence de réponse : il vous envoie remplir des formulaires de retrait pour des zones que personne n'interroge, pendant que le seul listing qui bloque vraiment vos e-mails reste en place. SSHive effectue la vérification lui-même, sur l'appareil que vous avez sous la main. Sur macOS, 8 zones sont interrogées en parallèle et l'enregistrement TXT est récupéré à chaque hit : vous obtenez le motif rédigé par l'opérateur à côté du code de retour. Sur iPhone et iPad, 10 zones sont interrogées et le code 127.0.0.x brut est affiché pour chacune. C'est de l'IPv4 uniquement, le comportement est inchangé dans la version sandboxée du Mac App Store, et c'est gratuit sur toutes les plateformes : sans compte, sans publicité, et sans aucun serveur SSHive sur le trajet.

Ce que fait SSHive

8 zones sur Mac, 10 sur iPhone et iPad, toutes nommées

macOS interroge zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net, dnsbl.sorbs.net, bl.mailspike.net, dnsbl-1.uceprotect.net, psbl.surriel.com et all.s5h.net. iPhone et iPad interrogent le même ensemble sans psbl.surriel.com, mais avec dnsbl-2.uceprotect.net, ix.dnsbl.manitu.net et dnsbl.dronebl.org, dix au total. Les listes diffèrent selon la plateforme, et chaque zone est affichée nommément.

Le motif, pas seulement un drapeau rouge

Sur macOS, chaque hit déclenche une seconde requête TXT sur le même nom : la colonne Motif affiche l'explication rédigée par l'opérateur, avec le plus souvent l'URL de sa page de retrait. Si aucun TXT n'est publié, le code de retour 127.0.0.x brut prend le relais. Sur iPhone et iPad, le TXT n'est pas récupéré : seul le code apparaît sous chaque zone listée.

IP ou nom d'hôte, résolu pour vous

Le champ accepte une IPv4 en notation pointée ou un nom d'hôte. Le nom d'hôte est résolu vers son premier enregistrement A avant toute interrogation de zone : vous pouvez donc coller directement le nom trouvé dans un rapport de non-remise. Attention : résoudre un domaine donne son adresse web, pas ses serveurs de messagerie ; pour un domaine de courrier, passez par la recherche MX.

Fonctionne dans le bac à sable d'Apple

Une requête DNSBL est une simple résolution d'enregistrement A via le résolveur système : pas de socket brut, pas de port privilégié, aucun binaire lancé. C'est pourquoi la vérification de liste noire fonctionne sans changement dans la version sandboxée du Mac App Store, et reste pleinement fonctionnelle sur iPhone et iPad, comme tous les autres outils du panneau.

Chaque serveur MX vérifié automatiquement

Sur Mac, la recherche MX applique ce même moteur DNSBL à ses propres résultats : chaque serveur de messagerie est résolu, résolu en sens inverse, et sa première adresse IPv4 est testée sur les 8 zones, avec une pastille « Non listé » ou « Blacklisté » par ligne. Seule la première IPv4 de chaque serveur est vérifiée, et les serveurs de messagerie uniquement IPv6 ne sont pas couverts.

Gratuit, sur toutes les plateformes, sans compte

Toute la suite d'outils réseau est gratuite sur Mac, iPhone et iPad. Aucun verrou Pro sur la vérification de liste noire, aucune publicité avant l'affichage d'un résultat, aucune inscription. SSHive Pro est un paiement unique distinct (environ 14,99 €, achat universel pour Mac, iPhone et iPad) qui débloque d'autres fonctions, jamais celles-ci.

Comment faire, étape par étape

  1. 1

    Ouvrir les outils réseau

    Sur Mac, cliquez sur l'icône réseau de la barre latérale, ou sur la pastille Outils réseau de l'écran d'accueil : les deux ouvrent un onglet Outils réseau. Sur iPhone, touchez Outils dans la barre d'onglets en bas. Sur iPad, choisissez Outils réseau dans la barre latérale.

  2. 2

    Repérer la carte Vérification DNSBL

    Sur Mac, Vérification DNSBL est la deuxième carte de la section Résolution et réputation, entre Recherche DNS et Recherche MX. Sur iPhone et iPad, Blacklist Check est la deuxième ligne de la section Email & IP, juste sous MX Lookup.

  3. 3

    Saisir une adresse IPv4 ou un nom d'hôte

    Saisissez une adresse en notation pointée comme 203.0.113.25, ou un nom d'hôte (sur Mac, le texte d'exemple indique « ex: 1.2.3.4 ou domaine.com »). Un nom d'hôte est résolu vers son premier enregistrement A avant l'interrogation des zones. Cliquez sur Vérifier les listes noires. Toutes les zones partent en parallèle : un test complet dure à peu près le temps de la résolution DNS la plus lente.

  4. 4

    Lire la synthèse, puis le détail par zone

    Sur Mac, une pastille de synthèse affiche « <n>/8 listes noires », verte à zéro, rouge sinon, au-dessus d'un tableau à trois colonnes : Zone, Statut, Raison. Sur iPhone et iPad, un bouclier vert Propre ou un décompte rouge de listes, puis une section Listé, une section pour les zones qui n'ont pas donné de réponse exploitable, et une section Propre ; chaque ligne listée porte son code de retour 127.0.0.x brut.

  5. 5

    Suivre le motif jusqu'au bon formulaire de retrait

    Sur macOS, la colonne Raison reprend l'enregistrement TXT de la zone, qui contient généralement l'explication de l'opérateur et l'adresse de sa page de retrait. Notez le nom exact de la zone, corrigez d'abord la cause, puis rendez-vous sur le formulaire de cet opérateur. N'utilisez jamais un service groupé promettant un retrait de cent listes d'un coup.

Lire le résultat : quels listings bloquent vraiment le courrier

Toutes les lignes ne pèsent pas le même poids, et les traiter à égalité est l'erreur la plus fréquente. zen.spamhaus.org est celle qui décide si votre courrier arrive. C'est une zone composite, et le code de retour indique quel composant s'est déclenché. 127.0.0.2 et 127.0.0.3 correspondent à SBL et CSS : source de spam connue ou plage de type snowshoe. 127.0.0.4 à 127.0.0.7 correspondent à XBL : machine compromise émettant via un proxy, un bot ou un ver, ce qui signale en général une infection sur votre réseau plutôt qu'une mauvaise configuration. 127.0.0.9, c'est DROP, réservé aux plages détournées ou criminelles. 127.0.0.10 et 127.0.0.11 correspondent à PBL, et PBL n'est pas une accusation de spam : cette liste indique que l'adresse se trouve dans un espace dynamique ou grand public dont l'opérateur réseau a lui-même déclaré qu'il ne devait pas livrer directement aux MX. Une connexion résidentielle ou une instance cloud toute neuve qui touche PBL doit relayer par un smarthost, pas déposer un recours. Aucun code de la plage 127.255.255.0/24 n'est un vrai listing. C'est la zone qui refuse la requête, le plus souvent parce qu'elle est arrivée via un gros résolveur public comme 8.8.8.8 ou 1.1.1.1, et la façon dont cela s'affiche dépend de l'appareil. Le Mac considère comme listée toute réponse commençant par 127. : sur un résolveur public, Spamhaus peut donc apparaître en ligne rouge « Listé » avec le code 127.255.255.254. C'est une requête refusée, pas une inscription : lisez le code, pas la couleur. Le Mac enregistre aussi comme propre une zone qui répond par une erreur DNS : une ligne « Propre » peut donc ne correspondre à aucune réponse. L'iPhone et l'iPad séparent ces deux cas : un code 127.255.255.x ou une requête en échec va dans un groupe à part, celui des zones sans réponse exploitable, compté ni comme listé ni comme propre. Sur l'un comme sur l'autre, refaites le test depuis un réseau utilisant son propre résolveur récursif, ou celui de son FAI, avant de vous fier au résultat. En dessous de Spamhaus, b.barracudacentral.org et bl.spamcop.net sont largement consultées et méritent une action. bl.mailspike.net est un score de réputation, pas un verdict binaire. psbl.surriel.com et ix.dnsbl.manitu.net s'appuient sur des pièges à spam et expirent seules, souvent en quelques heures. dnsbl-1.uceprotect.net liste une IP unique ; dnsbl-2.uceprotect.net, interrogée uniquement sur iPhone et iPad, liste toute une allocation parce qu'un voisin a spammé : un hit niveau 2 isolé au milieu de lignes propres est donc généralement du bruit. dnsbl.sorbs.net est un cas particulier : son opérateur a arrêté le service en 2024, et cette ligne ne dit donc rien de votre réputation, quoi qu'elle affiche. N'y voyez pas un certificat de bonne conduite. Enfin, un balayage entièrement propre ne garantit pas la remise. Gmail, Outlook.com et Yahoo appliquent des systèmes de réputation internes qu'aucune DNSBL publique n'expose.

Questions fréquentes

La vérification de liste noire est-elle disponible dans la version Mac App Store ?+
Oui, sans rien en moins : toutes les zones, la récupération du motif TXT, aucun garde-fou lié au bac à sable. Une requête DNSBL est une simple résolution d'enregistrement A via le résolveur système : elle ne réclame aucun des privilèges que le bac à sable d'Apple refuse, et le ping et le traceroute non plus, en définitive, puisqu'ils émettent du vrai ICMP depuis la version App Store via un socket datagramme.
Pourquoi mon iPhone teste-t-il 10 listes et mon Mac seulement 8 ?+
Les deux bases de code embarquent des ensembles de zones différents. macOS teste 8 zones ; iPhone et iPad en testent 10 : la même liste sans psbl.surriel.com, mais avec dnsbl-2.uceprotect.net, ix.dnsbl.manitu.net et dnsbl.dronebl.org. Un résultat peut donc légitimement différer entre votre Mac et votre téléphone. Le cas le plus courant est un hit UCEPROTECT niveau 2 visible uniquement sur mobile, qui reflète le voisinage de votre allocation et non votre propre IP.
Puis-je tester une adresse IPv6 ?+
Non. L'outil est IPv4 uniquement sur toutes les plateformes : tout ce qui n'est pas une adresse en notation pointée (ou un nom d'hôte s'y résolvant) est refusé. Le blocage IPv6 impose un encodage en 32 quartets de type ip6.arpa, et la couverture réelle des grandes zones reste très inégale : SSHive préfère refuser la requête plutôt que renvoyer un résultat qu'il ne peut pas assumer. Si votre MTA est en double pile, testez son adresse IPv4 et passez par les outils postmaster des fournisseurs pour la partie v6.
Je suis listé sur le PBL de Spamhaus. Mon serveur a-t-il envoyé du spam ?+
Presque certainement pas. Le PBL (codes 127.0.0.10 et 127.0.0.11 dans la zone composite zen) est une liste de politique, pas une liste d'abus. Il consigne que l'adresse appartient à une plage que l'opérateur réseau a lui-même déclarée comme dynamique ou grand public, et qui ne devrait pas dialoguer directement avec des MX distants. Les déclencheurs habituels sont une connexion résidentielle ou une IP cloud dont le fournisseur n'a pas ouvert le port 25. La solution est de relayer par le smarthost du fournisseur, ou de demander la reclassification de la plage, pas de déposer un recours pour abus.
Toutes les zones affichent « Propre », mais mon courrier rebondit toujours chez Outlook. Pourquoi ?+
Deux raisons, à écarter l'une après l'autre. D'abord, les grands hébergeurs de boîtes aux lettres entretiennent des systèmes de réputation privés qu'aucune DNSBL publique n'expose : un blocage Microsoft ou Google leur appartient et se traite via leurs propres canaux postmaster, pas par un formulaire de retrait. Ensuite, la zone n'a peut-être pas répondu à la question que vous croyez. Quand une liste noire refuse une requête (la plupart le font pour le trafic passant par 8.8.8.8 ou 1.1.1.1), elle répond généralement par un code dans 127.255.255.0/24. Le Mac l'affiche en ligne rouge « Listé » : vérifiez le code avant de croire à une inscription. Et quand elle répond par une erreur DNS, le Mac l'enregistre comme propre, si bien qu'une ligne « Propre » peut n'y correspondre à aucune réponse. L'iPhone et l'iPad classent ces deux cas à part, parmi les zones sans réponse exploitable. Refaites le test depuis un réseau doté de son propre résolveur récursif avant de conclure.
Puis-je tester un domaine au lieu d'une adresse IP ?+
Vous pouvez saisir un nom d'hôte : il est résolu vers son premier enregistrement A avant l'interrogation des zones. Mais soyez conscient de ce que vous testez : pour example.com, vous vérifiez l'IP derrière le site web, qui n'est très souvent pas la machine qui envoie le courrier. Pour tester les machines qui livrent réellement vos e-mails, utilisez MX Lookup : sur macOS, il résout chaque serveur de messagerie et applique automatiquement le même contrôle DNSBL sur 8 zones à la première IPv4 de chacun.
Faut-il SSHive Pro pour lancer une vérification de liste noire ?+
Non. Toute la suite d'outils réseau (vérification DNSBL, recherche MX, recherche DNS, whois, ping et traceroute) est gratuite sur Mac, iPhone et iPad, sans compte et sans publicité. SSHive Pro est un paiement unique optionnel (environ 14,99 €), en achat universel pour Mac, iPhone et iPad, qui débloque d'autres fonctions. Il n'y a pas d'abonnement, et aucun de ces diagnostics n'est derrière un mur payant, sur aucune plateforme.

Comment fonctionne une requête DNSBL, et pourquoi l'ordre du retrait compte

Une DNSBL est une base de données publiée intégralement via DNS, et c'est précisément pour cela que l'interroger n'exige aucun privilège, sur aucune des plateformes où SSHive est distribué. Pour tester 203.0.113.25 contre zen.spamhaus.org, le client inverse les quatre octets et demande un enregistrement A à 25.113.0.203.zen.spamhaus.org. L'inversion n'a rien de cosmétique. Le DNS délègue hiérarchiquement de droite à gauche : écrire l'adresse à l'envers permet à l'opérateur de la zone de déléguer par /8, /16 ou /24, exactement comme in-addr.arpa le fait pour les résolutions inverses. NXDOMAIN signifie « non listée ». Toute réponse dans 127.0.0.0/8 signifie « listée », les octets de poids faible encodant la sous-liste concernée. Un enregistrement TXT sur le même nom, lorsque l'opérateur en publie un, porte le motif lisible et l'URL de retrait. SSHive implémente cela deux fois. Sur macOS, le processus principal lance les huit requêtes de zone en parallèle via le résolveur c-ares de Node, chacune interceptée individuellement pour qu'une zone morte ou limitée en débit ne fasse pas échouer l'ensemble ; en cas de hit, une seconde requête TXT sur le même nom récupère le motif. Sur iPhone et iPad, l'implémentation Swift éclate les dix zones dans un groupe de tâches sur une file utilitaire, un getaddrinfo forcé en AF_INET par zone, puis trie les résultats : les listings d'abord, puis les zones sans réponse exploitable, puis par ordre alphabétique. Les deux acceptent une IPv4 littérale ou un nom d'hôte, ce dernier étant résolu vers son premier enregistrement A avant toute interrogation. Comme tout cela se ramène à une résolution d'enregistrement A via le résolveur système, aucun socket brut, aucun port privilégié et aucun binaire lancé ne sont impliqués : la vérification tourne telle quelle dans le bac à sable d'Apple. C'est vrai de tous les outils de ce panneau, ping et traceroute compris : ils émettent du vrai ICMP depuis un socket datagramme qui n'exige aucun privilège, si bien qu'aucune plateforme ne rend ici un diagnostic moins complet qu'ailleurs. Cela signifie aussi que chaque requête part de votre appareil vers les serveurs de noms de la zone, via le résolveur assigné par votre réseau : aucun backend SSHive, aucune API web tierce sur le trajet. Deux limites sont assumées. L'outil est IPv4 uniquement, et il n'interroge que des zones basées sur l'IP : pas de listes par domaine de type URIBL ou SURBL, pas d'horodatage des listings, pas de lien de retrait cliquable. Reste le retrait lui-même, où l'ordre des opérations décide de tout. Corrigez la cause avant de soumettre quoi que ce soit : retirer un listing alors que la source est encore active vous fait relister, souvent avec une pénalité plus longue. Les causes habituelles, par fréquence approximative : un compte SMTP AUTH compromis (cherchez un identifiant unique s'authentifiant depuis de nombreuses IP sources), un formulaire de contact web détourné, un relais ouvert, un poste infecté partageant votre IP publique derrière du NAT, et une liste de diffusion légitime devenue assez obsolète pour toucher des pièges à spam. Vérifiez ensuite les fondamentaux : un reverse DNS confirmé dans les deux sens et cohérent avec votre nom HELO, plus SPF, DKIM et DMARC. Alors seulement, utilisez la page de retrait de chaque opérateur. Spamhaus, Barracuda et SpamCop proposent des formulaires en libre-service ; PSBL, NiX Spam et UCEPROTECT niveau 1 expirent d'eux-mêmes une fois le trafic arrêté. Évitez tout service promettant un retrait de cent listes d'un coup, et attendez-vous à ce que la remise se rétablisse plusieurs jours après la levée du listing.