# Vérifier blacklist email : ce que les lookups ne disent pas URL: https://notificationharbor.com/fr/journal/verifier-blacklist-email Type: blog Locale: fr Published: 2026-11-10 Updated: 2026-11-11 --- > Une vérification de blacklist est une requête DNS à trois issues, dont la plupart des outils masquent une. Voici comment la lancer, la scripter et lire correctement les codes de rebond. Pour vérifier blacklist email sur votre IP d'envoi, vous lancez un lookup multi-listes et obtenez un tableau de lignes vertes et rouges. Ce tableau répond à une question étroite : cette adresse figure-t-elle, maintenant, dans une série de blacklists DNS publiques ? Une vérification de blacklist email ne dit pas si Gmail, Outlook ou une passerelle d'entreprise acceptera votre prochain message. Confondre les deux questions est précisément ce qui allonge la plupart des chronologies d'incident. Ce guide explique ce que la vérification interroge réellement, comment la lancer vous-même avec `dig`, quels codes signifient « propre » et lesquels signifient « votre requête a été refusée », et comment brancher le tout sur une supervision pour arrêter de le faire à la main à 2 h du matin. ## Une vérification de blacklist est une requête DNS, rien de plus Chaque DNSBL (DNS blocklist) fonctionne de la même manière. On inverse les octets de l'adresse IPv4, on ajoute la zone de la liste, puis on demande un enregistrement A. La [RFC 5782](https://datatracker.ietf.org/doc/html/rfc5782) définit la convention : pour 192.0.2.99 interrogé contre `bad.example.com`, la requête devient `99.2.0.192.bad.example.com`. Si l'adresse est listée, la réponse se situe dans la plage 127.0.0.0/8. Sinon, aucun enregistrement n'est renvoyé. Le mécanisme tient en une phrase. Les outils web dans lesquels vous collez une IP lancent des dizaines de ces requêtes en parallèle, puis mettent les réponses en forme. `# Est-ce que 203.0.113.25 est listée sur Spamhaus ZEN ? dig +short 25.113.0.203.zen.spamhaus.org A # Une recherche sur une liste basée sur les domaines fonctionne de la même manière, sans inversion : dig +short example.com.dbl.spamhaus.org A`Une sortie vide signifie non listé. Une réponse 127.x.x.x signifie listé, et les derniers octets indiquent quelle sous-liste a correspondu. Lancez la requête depuis une machine que vous contrôlez, avec votre propre résolveur, et vous pouvez la scripter, la journaliser et déclencher une alerte. ![Ordinateur portable affichant une fenêtre de terminal sombre à côté d'un carnet avec un schéma réseau dessiné à la main](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/0692d5-inline1.webp) ## Vérifiez l'adresse par laquelle part votre courrier, pas celle de votre site La première erreur consiste à interroger la mauvaise IP. Votre site marketing, votre API et votre relais d'envoi sont en général trois adresses différentes. Celle qui compte est l'IP présente dans l'en-tête `Received` d'un message réellement arrivé dans une boîte de réception. Si vous envoyez via un ESP sur une infrastructure partagée, cette IP ne vous appartient pas, et le listing non plus. Si vous envoyez depuis une IP dédiée, elle est entièrement à vous, y compris ce qu'a fait le précédent occupant de la plage. Récupérez l'IP d'envoi sur un message livré, et non dans un réglage de tableau de bord. Vérifiez ensuite trois choses distinctes : l'IP d'envoi, les domaines d'enveloppe et de From, et chaque domaine présent dans vos liens, y compris les hôtes de suivi et de désinscription. Les listes basées sur les URI, comme URIBL et SURBL, notent les liens du corps du message. Une IP propre ne protège donc pas un message qui pointe vers un domaine listé. ## Un résultat propre venant d'un résolveur public peut être un refus déguisé C'est le mode de défaillance que les pages de vérification génériques ne mentionnent jamais. Spamhaus ne répond pas aux requêtes qui arrivent par des résolveurs publics ou ouverts. Il le signale par un code de retour plutôt que par un listing. [Spamhaus documente 127.255.255.254 comme un code d'erreur](https://www.spamhaus.org/resource-hub/dnsbl/using-our-public-mirrors-check-your-return-codes-now/), et non comme un résultat de réputation, et précise qu'il ne doit jamais servir à rejeter du courrier. Deux conséquences en découlent. Si votre script lit n'importe quelle réponse 127.x comme « listé », une requête refusée depuis un résolveur cloud vous alertera pour un listing qui n'existe pas. Si votre script lit « pas de réponse exploitable » comme « propre », vous raterez silencieusement de vrais listings, car le refus peut aussi apparaître sous forme de réponse vide ou de NXDOMAIN. La solution consiste à lancer les requêtes depuis un hôte disposant de son propre résolveur récursif et d'un DNS inverse correct, ou à utiliser le service de requête gratuit vers lequel Spamhaus oriente les utilisateurs des miroirs publics. Validez ensuite la zone avant de lui faire confiance. La RFC 5782 impose que les listes IPv4 contiennent une entrée pour 127.0.0.2 et n'en contiennent aucune pour 127.0.0.1. Vous pouvez tester votre installation ainsi : `dig +short 2.0.0.127.zen.spamhaus.org A # doit renvoyer une réponse 127.x dig +short 1.0.0.127.zen.spamhaus.org A # ne doit rien renvoyer`Si les deux requêtes ne renvoient rien, votre chemin de résolution est cassé ou refusé. Corrigez cela avant de lire le moindre résultat qui en provient. ![Panneau de brassage avec des câbles Ethernet bleus et un seul câble rouge qui se détache](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/2357cf-inline2.webp) ## La plupart des incidents de délivrabilité ne sont pas des incidents de blacklist Lors d'une revue de rebonds, la première question est toujours la même : que dit exactement le serveur destinataire ? Un listing produit un rejet précis. Un problème de réputation chez un fournisseur de boîtes produit un rejet différent, et aucune liste publique ne le montre. La documentation d'expédition de Google est claire sur ce point. Une réponse `550 5.7.1` peut signifier que l'IP d'envoi figure sur une liste de suspension, souvent à cause d'une mauvaise réputation d'IP partagée. `5.7.26` pointe vers une authentification en échec. Pour les expéditeurs en volume, Google exige SPF, DKIM et DMARC, des DNS direct et inverse valides sur l'IP d'envoi, TLS, et un taux de spam inférieur à 0,30 % dans Postmaster Tools. Les [exigences d'expédition Gmail](https://support.google.com/a/answer/81126) recommandent une cible de 0,10 %. Traitez cela comme un ordre de priorité. Si le texte du rebond nomme une zone DNSBL, vous avez un problème de listing. S'il parle de réputation, d'authentification ou de limite de débit, une vérification de blacklist reviendra propre, et vous aurez perdu une heure à le confirmer. - **Le rebond nomme une zone ou une URL DNSBL :** vous êtes listé sur cette liste précise. Lancez la vérification, puis utilisez la page de retrait de la liste. - **`550 5.7.1` avec une formulation sur la réputation de l'IP :** réputation côté fournisseur, souvent sur une IP partagée. Consultez Postmaster Tools ainsi que la tendance des volumes et des plaintes. - **`5.7.26` :** l'authentification a échoué. Vérifiez l'alignement SPF, DKIM et DMARC. - **`4.7.28` ou une formulation liée au débit :** vous envoyez trop vite pour votre réputation actuelle. Ralentissez, puis remontez progressivement. ## Abandonnez le contrôle ponctuel en ligne comme supervision Une vérification ponctuelle décrit l'état au moment où vous appuyez sur Entrée. Les listings sont souvent transitoires, et beaucoup apparaissent après un pic que vous avez déjà causé : un import à froid, un envoi massif de re-permission, un formulaire compromis que quelqu'un utilise pour relayer du spam. Les services qui font payer pour vous « retirer de 100 blacklists » vendent une solution à un problème que la plupart de ces listes ne posent pas. Beaucoup de listes présentes dans un multi-check typique ont un impact négligeable sur les grands fournisseurs de boîtes, et le retrait est en général gratuit et en libre-service, sur la page de l'opérateur. Courir après chaque ligne rouge fait perdre du temps qui devrait aller aux deux ou trois listes que vos destinataires consultent réellement. Classez les listes selon le trafic que vous envoyez. Regardez quels destinataires apparaissent dans vos rebonds, identifiez les listes que ces destinataires consultent publiquement, et surveillez celles-là. Le reste est du bruit, à revoir une fois par mois. ![Trois notes autocollantes reliées par des flèches au marqueur sur un tableau blanc, esquissant un flux de supervision](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/55886e-inline3.webp) ## Transformez la vérification en tâche planifiée avec un seuil d'alerte Voici la version minimale, qui tient la route. Elle tourne depuis un hôte doté d'un vrai résolveur, valide la zone d'abord, et distingue les trois issues : listé, non listé et requête refusée. `import socket def dnsbl(ip: str, zone: str) -> str: rev = ".".join(reversed(ip.split("."))) try: answer = socket.gethostbyname(f"{rev}.{zone}") except socket.gaierror: return "non_liste" if answer.startswith("127.255.255."): return "refuse" # code d'erreur, pas un résultat de réputation return f"liste:{answer}" # Vérifier la zone avant de lui faire confiance (entrées de test RFC 5782) assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("liste") assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "non_liste"`Lancez-la toutes les 15 à 60 minutes par IP d'envoi et par domaine d'envoi, journalisez chaque résultat avec son horodatage, et n'alertez que sur une transition de `non_liste` vers `liste`. Alertez séparément sur `refuse`, car cela signifie que votre supervision est aveugle, et non que votre réputation a changé. Associez-la aux signaux que les blacklists accusent toujours en retard : taux de plaintes des tableaux de bord Postmaster, taux de rebonds par domaine destinataire, taux de différés par heure. Ces indicateurs bougent avant qu'un listing n'apparaisse, et ce sont eux qui vous disent s'il faut suspendre un envoi. Si vous envoyez déjà vos logs et vos métriques vers une pile de supervision, le résultat du lookup n'est qu'une série temporelle de plus. Quatre outils correspondent à ce flux, selon l'endroit où le problème fait mal. Postmark est un service exclusivement transactionnel : vos réinitialisations de mot de passe ne partagent donc pas leur chemin d'envoi avec la campagne de quelqu'un d'autre. Si vos listings remontent sans cesse à un voisin sur une infrastructure partagée, séparer le transactionnel du marketing est la correction structurelle. Resend est l'option orientée développeurs si vous voulez une API propre et une surface réduite à instrumenter. Cela vaut le coup quand votre équipe scriptera de toute façon ses propres vérifications de délivrabilité. SendGrid a le plus long historique en volume et propose des IP dédiées, ce qui signifie que la réputation, et donc l'exposition aux blacklists, est à vous seul. Passez votre chemin si vous ne pouvez pas assurer le préchauffage et la supervision que les IP dédiées exigent. Better Stack est la pièce qui manquait côté tâche planifiée : contrôles de disponibilité, alertes et astreinte pour le script ci-dessus, pour qu'un nouveau listing parvienne à un humain plutôt qu'à un fichier de logs. ## Quand vous êtes listé, corrigez la cause avant de demander le retrait Un retrait sans cause identifiée ne vous achète que quelques jours. L'opérateur d'une liste qui voit la même adresse revenir avec le même comportement la relistera, et certains opérateurs durcissent les sanctions en cas de récidive. Procédez dans cet ordre : - Stoppez ou ralentissez l'envoi depuis l'IP listée. Chaque nouveau flux défavorable prolonge le listing et en ajoute d'autres. - Lisez la fiche de listing de l'opérateur. Beaucoup y indiquent la preuve : un passage sur un piège à spam, un pic, un signalement d'abus de relais. - Trouvez la source. Vérifiez les endpoints de formulaire pour un relais ouvert, examinez les imports de listes récents et passez en revue toute nouvelle intégration qui a commencé à envoyer la semaine passée. - Corrigez la cause, puis utilisez la procédure de retrait de l'opérateur. Certaines listes expirent automatiquement les listings après une période calme. - Reprenez à volume réduit, en commençant par vos destinataires les plus engagés, et surveillez le taux de plaintes et les différés pendant une semaine. Un DNS inverse absent contribue souvent au problème. Google fait figurer les enregistrements PTR valides parmi ses exigences d'expéditeur, et une IP d'envoi sans PTR paraît peu fiable à de nombreux destinataires, avant même que le contenu soit évalué. ### Construisez le flux de cycle de vie autour du signal, pas autour de la liste Si votre produit envoie des emails d'activation, de facturation ou de sécurité, un listing est un incident de disponibilité pour ces flux. Traitez-le comme tel : faites passer les messages transactionnels par un chemin isolé du volume marketing, et rendez la couche de déclenchement consciente de l'état de livraison, pour qu'un email d'activation bloqué bascule vers une invite dans l'application. Customer.io est la couche événementielle que les équipes associent souvent à un fournisseur de livraison distinct pour cette raison : les déclencheurs comportementaux et la logique des messages vivent à un endroit, la livraison à un autre, et vous pouvez changer ou scinder la livraison sans réécrire les flux. Le compromis est un système de plus à garder observable. C'est cette séparation qui mérite d'être copiée, même si vous choisissez d'autres fournisseurs. Un événement de blacklist doit changer le chemin d'un message, et non la capacité de votre logique de cycle de vie à fonctionner. ## Ce que nous mettrions en place cette semaine Trois choses, par ordre de rendement. D'abord, une vérification planifiée avec validation de zone et un état `refuse` distinct, lancée depuis un hôte doté de son propre résolveur. Ensuite, la ventilation des rebonds par domaine destinataire, pour savoir quelles listes comptent pour votre trafic. Enfin, un runbook écrit qui part du texte du rebond et finit à l'étape de retrait, pour que la personne d'astreinte n'improvise pas. Lequel de vos domaines d'envoi ne remarqueriez-vous pas s'il était listé pendant une journée ? ## FAQ ### Comment lancer une vérification de blacklist email sur mon IP ? Inversez les octets de l'IP, ajoutez une zone DNSBL et demandez un enregistrement A. Pour 203.0.113.25 sur Spamhaus ZEN, lancez dig +short 25.113.0.203.zen.spamhaus.org A. Une sortie vide signifie non listé, une réponse 127.x signifie listé. ### Pourquoi mon IP apparaît propre alors que mes emails sont toujours rejetés ? Une vérification ne couvre que les listes interrogées. Les rejets viennent souvent de la réputation chez le fournisseur de boîte, d'un échec SPF, DKIM ou DMARC, ou de limites de débit, rien de tout cela n'apparaît sur une blacklist publique. Lisez d'abord le texte du rebond. ### Que signifie le code Spamhaus 127.255.255.254 ? C'est un code d'erreur, pas un résultat de réputation. Spamhaus l'utilise lorsqu'une requête arrive par un résolveur public ou ouvert. Il ne dit rien de votre IP et ne doit pas être traité comme un listing. ### Faut-il vérifier mon domaine en plus de mon IP d'envoi ? Oui. La réputation de l'IP et celle du domaine sont deux signaux distincts. Vérifiez aussi les domaines des liens de vos messages, y compris les hôtes de suivi et de désinscription, car les listes d'URI notent les liens présents dans le corps du message. ### À quelle fréquence surveiller les blacklists ? Toutes les 15 à 60 minutes par IP d'envoi et par domaine suffisent pour la plupart des équipes. Alertez lors d'un passage de non listé à listé, et alertez séparément quand les requêtes sont refusées, car cela signifie que votre supervision est aveugle. ### Vaut-il la peine de payer un service pour me retirer des blacklists ? En général non. Le retrait est en principe gratuit sur la page de chaque opérateur de liste, et beaucoup de listes d'un multi-check large comptent peu pour les grands fournisseurs de boîtes. Corrigez d'abord la cause, puis demandez le retrait.