Surveillance des listes noires : scripts, API et alertes webhook
Surveiller les listes noires consiste à interroger régulièrement plusieurs listes de blocage DNS (DNSBL) pour vos IP et domaines d'envoi, et à ne déclencher une alerte que lorsqu'un résultat change. Détecter une inscription au moment où elle se produit, plutôt que lorsque des clients signalent des e-mails rejetés, vous laisse le temps d'en trouver la cause et de demander le retrait avant que les dégâts ne s'étendent.
Il existe deux façons pratiques de procéder : exécuter vous-même un petit script dig et cron, ou confier les vérifications à un service via une API et des webhooks. Dans les deux cas, deux détails déterminent si la surveillance dit vrai : les requêtes envoyées via des résolveurs publics sont refusées par des listes comme Spamhaus et produisent des réponses trompeuses, et les codes d'erreur ne doivent jamais être comptés comme des inscriptions.
Les règles des opérateurs de listes citées ici s'appuient sur leurs pages officielles telles qu'elles se présentaient en novembre 2026. Les règles changent : vérifiez-les avant de vous fier à une configuration. Pour comprendre le fonctionnement des DNSBL, voir qu'est-ce qu'une DNSBL (RBL).
Choisir quoi surveiller et quelles listes interroger
Commencez par noter les objets que vous devez réellement surveiller.
- Les adresses IP d'envoi. Ce sont les adresses depuis lesquelles votre serveur de messagerie ou votre fournisseur d'e-mail envoie réellement. Votre site web et vos e-mails partent souvent de machines différentes : confirmez l'adresse dans les en-têtes Received d'un message que vous avez envoyé. Si vous envoyez en IPv6, surveillez aussi ces adresses.
- Les domaines. Le domaine de votre adresse From et tous les domaines qui apparaissent dans les liens de vos messages. Les domaines sont vérifiés sur des listes de blocage de domaines, distinctes des listes d'IP.
Le format des requêtes est défini dans la RFC 5782. En IPv4, on inverse les octets et on ajoute la zone de la liste : 192.0.2.99 devient ainsi 99.2.0.192 suivi du nom de zone. En IPv6, l'adresse s'écrit sous forme de 32 nibbles hexadécimaux en ordre inverse. Un domaine est simplement placé devant la zone. Une entrée listée renvoie un enregistrement A, par convention dans 127.0.0.0/8 ; une entrée non listée renvoie NXDOMAIN. La RFC note aussi que les listes devraient publier un enregistrement TXT expliquant le motif de l'inscription.
Surveillez plusieurs listes plutôt qu'une seule, car les destinataires n'utilisent pas tous les mêmes. La signification de chaque code de retour varie selon l'opérateur ; notre guide des codes de retour DNSBL présente les plus courants.
Pourquoi les résolveurs publics donnent de fausses réponses
Une erreur fréquente dans les outils de surveillance maison consiste à envoyer les requêtes via un résolveur public comme Google Public DNS (8.8.8.8) ou Cloudflare (1.1.1.1). La FAQ officielle de Spamhaus sur l'utilisation des DNSBL explique ce qui se passe :
- L'utilisation gratuite des DNSBL Spamhaus exige que l'usage soit non commercial et que les requêtes ne proviennent pas d'un résolveur public ou ouvert, ni d'une IP au reverse DNS générique.
- Via des résolveurs ouverts gratuits comme Google Public DNS, les requêtes obtiendront dans la plupart des cas une réponse « non listé » (NXDOMAIN). Autrement dit, une IP listée peut sembler propre.
- Les requêtes passant par un résolveur public peuvent aussi recevoir 127.255.255.254. C'est un code d'erreur, pas une inscription. De même, 127.255.255.252 signale une faute de frappe dans le nom de la DNSBL, et 127.255.255.255 un nombre excessif de requêtes. Spamhaus précise que ces codes ne doivent pas être interprétés comme une inscription de l'objet interrogé.
- Les résolveurs qui réécrivent les réponses NXDOMAIN renvoient une adresse IP à la place : vous ne voyez donc jamais le NXDOMAIN correct.
La principale recommandation de la FAQ est d'exploiter votre propre résolveur DNS. Pour les utilisateurs qui doivent rester sur un résolveur public, Spamhaus renvoie à son Data Query Service (DQS) ; consultez ses conditions pour savoir ce qui est gratuit. La FAQ suggère dig txt whoami.fastly.net pour voir quel résolveur vous utilisez réellement.
La RFC 5782 prévoit un contrôle de cohérence intégré : une liste IPv4 doit contenir une entrée pour 127.0.0.2 et ne doit pas contenir 127.0.0.1, et les clients devraient vérifier périodiquement ces entrées de test pour confirmer que la liste fonctionne. Dans l'exemple de Spamhaus, 2.0.0.127.zen.spamhaus.org renvoie 127.0.0.10, 127.0.0.4 et 127.0.0.2, tandis que 1.0.0.127.zen.spamhaus.org renvoie NXDOMAIN. Un outil de surveillance devrait tester cela en premier et ignorer l'exécution en cas d'échec.
Option 1 : un script dig et cron
Voici un script minimal qui vérifie une adresse IPv4 sur Spamhaus ZEN et SpamCop (bl.spamcop.net, dont SpamCop indique qu'il répond 127.0.0.2 pour une IP listée). Remplacez l'adresse et les zones par les vôtres.
#!/bin/sh
# Interrogez votre propre résolveur récursif (par ex. unbound sur le même hôte), jamais un résolveur public
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')
q() {
out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
case "$out" in
*"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
*"status: NXDOMAIN"*) echo NX ;;
*) echo ERR ;;
esac
}
for Z in $ZONES; do
# Si l'entrée de test 127.0.0.2 ne renvoie pas un code d'inscription, ne pas se fier à cette exécution
case "$(q "2.0.0.127.$Z")" in
127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
127.*) ;;
*) echo "$Z ERROR test-entry"; continue ;;
esac
A=$(q "$REV.$Z")
case "$A" in
NX) echo "$Z CLEAN" ;;
ERR) echo "$Z ERROR no-answer" ;;
127.255.255.*) echo "$Z ERROR $A" ;;
127.*) echo "$Z LISTED $A" ;;
*) echo "$Z ERROR unexpected $A" ;;
esac
doneCe que fait le script :
- Seul un statut NXDOMAIN compte comme propre, 127.255.255.x est une erreur, et tout autre 127.x est une inscription. Toute réponse hors de 127.0.0.0/8 est traitée comme une anomalie, par exemple un résolveur qui réécrit les réponses.
- Un délai dépassé fait sortir dig avec un code non nul, tandis que SERVFAIL et REFUSED sortent avec 0. Aucun de ces cas n'est considéré comme propre ; le script enregistre une erreur.
- Les codes de retour sont propres à chaque liste. Certaines listes utilisent par exemple 127.0.0.1 pour signaler qu'une requête a été refusée : lisez la documentation de chaque liste que vous ajoutez et complétez l'instruction case si nécessaire.
Laissez ensuite cron comparer chaque exécution à la précédente et n'envoyer un e-mail qu'en cas de changement :
# Example: run hourly, send mail only when the output differs from the last run
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prevL'intervalle d'une heure n'est qu'un exemple. Spamhaus propose un accès gratuit pour un usage non commercial à faible volume, et les clients qui dépassent son seuil de volume de requêtes doivent passer à une option payante ; vérifiez les conditions de chaque liste à mesure que le nombre d'IP surveillées augmente. La FAQ conseille aussi d'exécuter les commandes plusieurs fois pour confirmer que les résultats restent identiques.
Option 2 : l'API batch et les webhooks de DNSBL Checker
Si vous préférez ne pas maintenir de résolveur ni de règles d'analyse par liste, vous pouvez confier les vérifications à un service. Voici l'API v1 de ce site, limitée à ce que fait réellement l'implémentation côté serveur. La référence se trouve sur /en/api-docs et les clés sont délivrées sur la page membres, à /account. L'inscription ne demande qu'une adresse e-mail, et vous vous connectez grâce à un lien envoyé par e-mail.
Authentification et limites
- Les clés commencent par
dnsbl_et ne sont affichées qu'une fois, juste après leur émission ; seul un hachage est conservé. Émettre une nouvelle clé invalide la précédente. - Envoyez la clé dans l'en-tête
X-API-Keyà chaque requête. HTTPS uniquement ; http:// est redirigé vers https://, appelez donc directement https://. - Les limites sont de 1 000 vérifications par jour (une cible compte pour une), 100 cibles par batch et 50 enregistrements de surveillance. Au-delà de la limite quotidienne, vous obtenez
429avecdaily_limit_exceededet un horodatageresets_at.
Vérifications par batch
Envoyez un tableau targets de noms de domaine ou d'adresses IP à POST /api/v1/batch :
curl -X POST https://dnsblchecker.com/api/v1/batch \
-H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
-d '{"targets":["example.com"]}'Si une cible au moins reste à vérifier, la réponse est 202 avec un batch_id. Interrogez GET /api/v1/batch/{batch_id} toutes les quelques secondes jusqu'à ce que status vaille done (exemple abrégé ; les chiffres et le nom de liste sont illustratifs et ne constituent pas un résultat réel) :
{
"batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
"results": [
{
"target": "example.com", "type": "domain",
"status": "done", "verdict": "listed",
"checked_at": "2026-11-03 09:12",
"lists_checked": 80, "listed_count": 1, "error_count": 4,
"listed_on": [
{ "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
]
}
]
}verdictvautlistedsi au moins une liste signale une inscription, sinonclean. Les listes qui ont dépassé le délai ou ont répondu par un code d'erreur comme 127.255.255.x sont comptées danserror_count, jamais comme des inscriptions.- Un batch renvoie un résultat enregistré s'il en existe un datant des 30 derniers jours. Pour une surveillance programmée, regardez toujours
checked_at. - Les cibles mal formées sont renvoyées dans
rejectedavec un motif et ne sont pas décomptées. Si vous passez une URL, seul le nom d'hôte est utilisé. Les plages réservées à la documentation comme 192.0.2.0/24 sont rejetées : testez avec une vraie IP d'envoi.
Surveillance par webhook
Enregistrez une target et une callback_url avec POST /api/v1/monitors. Chaque cible enregistrée est ensuite vérifiée une fois par jour sans utiliser le cache (la première vérification a lieu dans un délai d'environ un jour après l'enregistrement), et un POST JSON n'est envoyé à votre URL que lors de la première vérification (monitor.initial) et lorsque le verdict bascule entre listé et propre (monitor.status_changed).
curl -X POST https://dnsblchecker.com/api/v1/monitors \
-H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
-d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'- Le
signing_secretde la réponse n'est affiché qu'une fois. Chaque envoi comporte un en-têteX-DNSBL-Signature: sha256=..., le HMAC-SHA256 du corps brut calculé avec ce secret. Vérifiez-le de votre côté. callback_urldoit être en https sur le port 443 et pointer vers une IP publique ; les redirections ne sont pas suivies et le délai d'attente est de 10 secondes : mettez les traitements lourds en file d'attente et répondez rapidement.- Si votre point de terminaison renvoie autre chose que
2xx, ou si la connexion échoue, l'envoi est retenté lors de la vérification quotidienne suivante. Le motif apparaît danslast_delivery_errordeGET /api/v1/monitors, etDELETE /api/v1/monitors/{monitor_id}supprime une surveillance.
import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))Concevoir les alertes : fréquence, listes multiples, fausses alarmes
Un outil de surveillance n'est utile que si l'on lit encore ses alertes au bout de quelques mois. Celui qui se déclenche sans arrêt finit vite par être ignoré.
Fréquence
- Distinguez la fréquence des requêtes de celle des notifications. Interrogez selon un calendrier, mais ne notifiez qu'en cas de changement d'état. Un message quotidien « tout va bien » noie la seule alerte qui compte.
- La RFC 5782 indique que les TTL d'une liste devraient refléter la vitesse à laquelle elle évolue, et que les listes de sources de spam peuvent utiliser des TTL de quelques minutes. Choisissez votre intervalle en sachant que certaines inscriptions apparaissent et expirent rapidement.
- Des requêtes trop nombreuses peuvent enfreindre les conditions d'utilisation d'une liste ou vous valoir 127.255.255.255 (requêtes excessives) au lieu de vraies réponses.
Plusieurs listes
- Indiquez le nom de la liste dans chaque alerte. Les listes ne sont pas utilisées par le même nombre de destinataires : vous pouvez alerter immédiatement pour celles qui comptent le plus pour vos destinataires et regrouper les autres dans un récapitulatif.
- Le webhook ci-dessus ne se déclenche que lorsque le verdict bascule entre listé et propre. Si une cible est déjà listée puis apparaît sur une deuxième liste, aucun événement n'est envoyé. Surveillez
last_listed_countdansGET /api/v1/monitors, ou lancez un batch et lisezlisted_on, pour détecter ce cas.
Faux positifs et réponses passagères
- Enregistrez les erreurs séparément des inscriptions. Spamhaus met en garde les opérateurs contre le rejet ou le filtrage d'e-mails sur la base de ses codes d'erreur ; la même logique s'applique à la surveillance. Un délai dépassé ou une réponse 127.255.255.x ne doit jamais déclencher une alerte d'inscription.
- Pour éviter de réagir à un résultat isolé et étrange, n'alertez qu'après deux résultats identiques consécutifs, ou interrogez de nouveau quelques minutes plus tard avant d'envoyer quoi que ce soit.
- Si les erreurs persistent, soupçonnez un changement de résolveur ou un changement du côté de la liste, et regardez d'abord le résultat de l'entrée de test.
- Une IP résidentielle dans la Spamhaus PBL est une inscription de politique, pas une accusation : elle signifie que l'adresse ne doit pas envoyer d'e-mails directement. Décidez liste par liste ce qui justifie une alerte (voir le retrait Spamhaus).
Que faire lorsqu'une inscription est détectée
- Confirmez-la. Consultez la page de vérification de l'opérateur et notez le nom de la liste, l'heure et le motif éventuel affiché.
- Corrigez d'abord la cause. Recherchez les comptes compromis, les formulaires web détournés, les machines infectées, les listes de diffusion mal entretenues et les incohérences de reverse DNS (PTR) ou de nom HELO. Demander le retrait alors que la cause persiste conduit généralement à une nouvelle inscription.
- Suivez la procédure de retrait de la liste. La décision de retrait appartient à chaque opérateur de liste, et déposer une demande ne garantit pas la levée de l'inscription. Si vous ne contrôlez pas l'IP, comme en hébergement mutualisé, contactez votre hébergeur ou votre FAI.
- Laissez l'outil de surveillance confirmer le résultat. Les destinataires appliquent aussi leurs propres filtres : continuez à surveiller la distribution une fois le verdict revenu à propre.
Pour une vérification ponctuelle d'une IP ou d'un domaine, utilisez le vérificateur de listes noires. Si la recherche de la cause ou le traitement des demandes dépasse ce que vous pouvez assumer, vous pouvez nous demander de l'aide. Pour la démarche de dépannage complète lorsque des e-mails sont rejetés, voir e-mails bloqués par les listes noires.
Nous vous mettons en relation avec des prestataires qui prennent en charge les demandes de retrait, le conseil et l'accompagnement (à partir de JPY 50,000). Le retrait est décidé par chaque opérateur de liste et ne peut pas être garanti.
Demander de l'aideCe site peut percevoir une commission de la part des prestataires présentés. About
Questions fréquentes
J'ai vérifié via 8.8.8.8 et aucune inscription n'est apparue. Suis-je propre ?
Pas nécessairement. La FAQ de Spamhaus indique que les requêtes passant par des résolveurs ouverts gratuits comme Google Public DNS obtiendront dans la plupart des cas une réponse « non listé » (NXDOMAIN) : une IP listée peut donc sembler propre. Interrogez depuis votre propre résolveur, ou utilisez la page de vérification de l'opérateur.
J'ai obtenu 127.255.255.254. Cela veut-il dire que je suis listé ?
Non. C'est un code d'erreur renvoyé pour les requêtes passant par un résolveur public ou ouvert, et Spamhaus précise qu'il ne signifie pas que l'objet est listé. Enregistrez-le comme une erreur et n'envoyez pas d'alerte d'inscription.
Puis-je simplement appeler l'API batch chaque jour en guise de surveillance ?
Un batch peut renvoyer un résultat enregistré datant de jusqu'à 30 jours : ce n'est donc pas toujours l'état du jour. Vérifiez checked_at, ou utilisez la surveillance par webhook (POST /api/v1/monitors), qui effectue une nouvelle vérification chaque jour.
Faut-il demander le retrait dès qu'une alerte se déclenche ?
Corrigez d'abord la cause. Une demande faite alors que le problème persiste aboutit généralement à une nouvelle inscription. La décision appartient toujours à l'opérateur de la liste.
Pages officielles consultées
Les informations de cet article ont été vérifiées sur les pages officielles ci-dessous à la date de publication. Les politiques et le fonctionnement peuvent changer sans préavis : consultez les pages officielles avant de vous fier à une information importante.
- RFC 5782: DNS Blacklists and Whitelists
- Spamhaus FAQ: DNSBL Usage
- Spamhaus: Using our public mirrors? Check your return codes now
- SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
Guides associés
Lire les codes de retour DNSBL : 127.0.0.2 selon la RFC 5782, codes de Spamhaus, SpamCop et UCEPROTECT, codes d'erreur, NXDOMAIN ou SERVFAIL.
Listé par Spamhaus ? Identifiez la liste concernée (ZEN, PBL, XBL, CSS, SBL, DBL), le sens des codes de retour et la procédure de retrait de chacune.
E-mail bloqué par une liste noire ? Lisez le code de rejet, vérifiez les causes dans l'ordre, repérez les listes qui comptent et demandez le retrait.