Home › Guide

Monitoraggio delle blacklist: script, API e avvisi via webhook

Pubblicato il 2026-11-03 ／ Aggiornato il 2026-11-03 ／ A cura di Yuki Nakazawa

Monitorare le blacklist significa interrogare a intervalli regolari diverse blocklist DNS (DNSBL) per i vostri IP e domini di invio, generando un avviso solo quando un risultato cambia. Intercettare un listing nel momento in cui avviene, anziché quando i clienti segnalano posta respinta, vi dà il tempo di trovare la causa e richiedere la rimozione prima che il danno si estenda.

Esistono due modi pratici per farlo: eseguire voi stessi un piccolo script con dig e cron, oppure affidare i controlli a un servizio tramite API e webhook. In entrambi i casi, due dettagli determinano se il monitoraggio dice il vero: le query inviate tramite resolver pubblici vengono rifiutate da liste come Spamhaus e producono risposte fuorvianti, e i codici di errore non devono mai essere conteggiati come listing.

Le regole dei gestori di liste citate qui si basano sulle loro pagine ufficiali aggiornate a novembre 2026. Le policy cambiano, quindi verificatele prima di affidarvi a una configurazione. Per le basi sul funzionamento delle DNSBL, vedete che cos'è una DNSBL (RBL).

Decidete che cosa monitorare e quali liste interrogare

Iniziate annotando gli oggetti che dovete effettivamente monitorare.

• Indirizzi IP di invio. Sono gli indirizzi da cui il vostro server di posta o il vostro provider email invia davvero. Il sito web e la posta spesso partono da macchine diverse, quindi confermate l'indirizzo negli header Received di un messaggio che avete inviato. Se inviate su IPv6, monitorate anche quegli indirizzi.
• Domini. Il dominio del vostro indirizzo From e gli eventuali domini che compaiono nei link all'interno dei messaggi. I domini si controllano sulle blocklist di domini, che sono separate dalle liste di IP.

Il formato delle query è definito in RFC 5782. Per IPv4 si invertono gli ottetti e si aggiunge la zona della lista, quindi 192.0.2.99 su una lista diventa 99.2.0.192 seguito dal nome della zona. Per IPv6 l'indirizzo si scrive come 32 nibble esadecimali in ordine inverso. Un dominio viene semplicemente anteposto alla zona. Una voce elencata restituisce un record A, per convenzione in 127.0.0.0/8; una non elencata restituisce NXDOMAIN. La RFC osserva inoltre che le liste dovrebbero pubblicare un record TXT che spieghi il motivo di un listing.

Monitorate più liste anziché una sola, perché i destinatari non usano tutti le stesse. Il significato di ciascun codice di risposta varia a seconda del gestore; la nostra guida ai codici di risposta delle DNSBL tratta quelli più comuni.

Perché i resolver pubblici danno risposte sbagliate

Un errore comune nei sistemi di monitoraggio fatti in casa è inviare le query tramite un resolver pubblico come Google Public DNS (8.8.8.8) o Cloudflare (1.1.1.1). La FAQ ufficiale di Spamhaus sull'uso delle DNSBL spiega che cosa succede:

• L'uso gratuito delle DNSBL di Spamhaus richiede che l'utilizzo sia non commerciale e che le query non provengano da un resolver pubblico o aperto, né da un IP con reverse DNS generico.
• Tramite resolver aperti gratuiti come Google Public DNS, le query nella maggior parte dei casi ricevono una risposta "non elencato" (NXDOMAIN). In altre parole, un IP elencato può sembrare pulito.
• Le query tramite un resolver pubblico possono anche ricevere 127.255.255.254. Si tratta di un codice di errore, non di un listing. Allo stesso modo, 127.255.255.252 indica un errore di battitura nel nome della DNSBL e 127.255.255.255 indica un numero eccessivo di query. Spamhaus afferma che questi codici non devono essere interpretati come indicazione che l'oggetto interrogato sia elencato.
• I resolver che riscrivono le risposte NXDOMAIN restituiscono invece un indirizzo IP, quindi non vedrete mai il corretto NXDOMAIN.

La raccomandazione principale della FAQ è di gestire un proprio resolver DNS. Per chi deve restare su un resolver pubblico, Spamhaus rimanda al proprio Data Query Service (DQS); verificatene le condizioni per sapere che cosa è gratuito. La FAQ suggerisce dig txt whoami.fastly.net per vedere quale resolver state effettivamente usando.

RFC 5782 aggiunge un controllo di coerenza integrato: una lista IPv4 deve contenere una voce per 127.0.0.2 e non deve contenere 127.0.0.1, e i client dovrebbero controllare periodicamente queste voci di test per confermare che la lista funzioni. Nell'esempio di Spamhaus, 2.0.0.127.zen.spamhaus.org restituisce 127.0.0.10, 127.0.0.4 e 127.0.0.2, mentre 1.0.0.127.zen.spamhaus.org restituisce NXDOMAIN. Un sistema di monitoraggio dovrebbe eseguire prima questo test e scartare l'esecuzione se fallisce.

Opzione 1: uno script con dig e cron

Ecco uno script minimo che controlla un indirizzo IPv4 su Spamhaus ZEN e SpamCop (bl.spamcop.net, che secondo la documentazione di SpamCop risponde 127.0.0.2 per un IP elencato). Sostituite l'indirizzo e le zone con i vostri.

#!/bin/sh
# Interrogate il vostro resolver ricorsivo (es. unbound sullo stesso host), mai uno pubblico
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
  # Se la voce di test 127.0.0.2 non restituisce un codice di listing, non fidatevi di questa esecuzione
  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
done

Che cosa fa lo script:

• Solo uno stato NXDOMAIN conta come pulito, 127.255.255.x è un errore e qualsiasi altro 127.x è un listing. Tutto ciò che è al di fuori di 127.0.0.0/8 viene trattato come un'anomalia, per esempio un resolver che riscrive le risposte.
• Un timeout fa terminare dig con un codice diverso da zero, mentre SERVFAIL e REFUSED terminano con 0. Nessuno di questi casi viene considerato pulito; lo script registra un errore.
• I codici di risposta sono specifici di ciascuna lista. Alcune liste, per esempio, usano 127.0.0.1 per indicare che una query è stata rifiutata, quindi leggete la documentazione di ogni lista che aggiungete ed estendete l'istruzione case dove necessario.

Poi lasciate che cron confronti ogni esecuzione con la precedente e invii una mail solo quando qualcosa è cambiato:

# Esempio: esecuzione ogni ora, mail solo quando l'output differisce dall'esecuzione precedente
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.prev

L'intervallo orario è solo un esempio. Spamhaus offre accesso gratuito per un uso non commerciale a basso volume, e i client che superano la sua soglia di volume di query hanno bisogno di un'opzione a pagamento; verificate le condizioni di ciascuna lista man mano che cresce il numero di IP monitorati. La FAQ consiglia inoltre di provare i comandi alcune volte per confermare che i risultati restino gli stessi.

Opzione 2: l'API batch e i webhook di DNSBL Checker

Se preferite non mantenere un resolver e regole di interpretazione per ogni lista, potete lasciare che sia un servizio a eseguire i controlli. Di seguito l'API v1 di questo sito, limitata a ciò che l'implementazione del server fa effettivamente. Il riferimento si trova in /en/api-docs e le chiavi vengono rilasciate nella pagina riservata ai membri in /account. Per la registrazione basta un indirizzo email, e l'accesso avviene tramite un link inviato per email.

Autenticazione e limiti

• Le chiavi iniziano con dnsbl_ e vengono mostrate una sola volta, subito dopo il rilascio; viene conservato solo un hash. Il rilascio di una nuova chiave invalida la precedente.
• Inviate la chiave nell'header X-API-Key a ogni richiesta. Solo HTTPS: le richieste http:// vengono reindirizzate a https://, quindi chiamate https:// fin dall'inizio.
• I limiti sono 1.000 controlli al giorno (un target conta come uno), 100 target per batch e 50 registrazioni di monitoraggio. Oltre il limite giornaliero ricevete 429 con daily_limit_exceeded e un timestamp resets_at.

Controlli batch

Inviate un array targets di nomi di dominio o indirizzi IP a 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"]}'

Se qualche target deve ancora essere controllato, la risposta è 202 con un batch_id. Interrogate GET /api/v1/batch/{batch_id} ogni pochi secondi finché status non diventa done (esempio abbreviato; i numeri e il nome della lista sono illustrativi, non un risultato reale):

{
  "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" }
      ]
    }
  ]
}

• verdict è listed se almeno una lista segnala un listing, altrimenti clean. Le liste andate in timeout, o che hanno risposto con un codice di errore come 127.255.255.x, vengono conteggiate in error_count e mai come listing.
• Un batch restituisce un risultato memorizzato se ne esiste uno degli ultimi 30 giorni. Per il monitoraggio programmato, guardate sempre checked_at.
• I target non validi vengono restituiti in rejected con un motivo e non vengono conteggiati. Se passate un URL, viene usato solo il nome host. Gli intervalli riservati alla documentazione, come 192.0.2.0/24, vengono rifiutati, quindi fate i test con un IP di invio reale.

Monitoraggio via webhook

Registrate un target e un callback_url con POST /api/v1/monitors. Ogni target registrato viene poi controllato una volta al giorno senza usare la cache (il primo controllo avviene entro circa un giorno dalla registrazione), e una POST JSON viene inviata al vostro URL solo al primo controllo (monitor.initial) e quando il verdetto passa da listed a clean o viceversa (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"}'

• Il signing_secret nella risposta viene mostrato una sola volta. Ogni consegna include un header X-DNSBL-Signature: sha256=..., l'HMAC-SHA256 del corpo grezzo calcolato con quel segreto come chiave. Verificatelo dal vostro lato.
• callback_url deve essere https sulla porta 443 e risolvere verso un IP pubblico; i redirect non vengono seguiti e il timeout è di 10 secondi, quindi mettete in coda le elaborazioni pesanti e rispondete rapidamente.
• Se il vostro endpoint restituisce qualcosa di diverso da 2xx, o la connessione fallisce, la consegna viene ritentata al controllo giornaliero successivo. Il motivo compare come last_delivery_error in GET /api/v1/monitors, e DELETE /api/v1/monitors/{monitor_id} elimina un monitoraggio.

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", ""))

Progettare gli avvisi: frequenza, più liste e falsi allarmi

Un sistema di monitoraggio è utile solo se le persone continuano a leggerne gli avvisi dopo qualche mese. Uno che scatta di continuo finisce presto per essere ignorato.

Frequenza

• Separate la frequenza delle query dalla frequenza delle notifiche. Interrogate secondo una pianificazione, ma notificate solo quando cambia lo stato. Un messaggio quotidiano di "tutto a posto" seppellisce l'unico avviso che conta.
• RFC 5782 afferma che i TTL delle liste dovrebbero riflettere la velocità con cui la lista cambia, e che le liste di fonti di spam possono usare TTL di pochi minuti. Scegliete l'intervallo sapendo che alcuni listing compaiono e scadono rapidamente.
• Un numero elevato di query può violare le condizioni d'uso di una lista o farvi ricevere 127.255.255.255 (query eccessive) anziché risposte reali.

Più liste

• Includete il nome della lista in ogni avviso. Le liste differiscono per il numero di destinatari che le usano, quindi potreste inviare subito un avviso per le liste più importanti per i vostri destinatari e raggruppare le altre in un riepilogo.
• Il webhook descritto sopra scatta solo quando il verdetto passa da listed a clean o viceversa. Se un target è già elencato e poi compare in una seconda lista, non viene inviato alcun evento. Tenete d'occhio last_listed_count in GET /api/v1/monitors, oppure eseguite un batch e leggete listed_on, per intercettare questo caso.

Falsi positivi e risposte transitorie

• Registrate gli errori separatamente dai listing. Spamhaus avverte gli operatori di non rifiutare né filtrare la posta sulla base dei suoi codici di errore; la stessa logica vale per il monitoraggio. Un timeout o una risposta 127.255.255.x non dovrebbero mai far scattare un avviso di listing.
• Per evitare di reagire a un singolo risultato anomalo, inviate un avviso solo dopo due risultati identici consecutivi, oppure ripetete la query qualche minuto dopo prima di inviare qualsiasi cosa.
• Se gli errori persistono, sospettate un cambio di resolver o una modifica dal lato della lista, e guardate prima il risultato della voce di test.
• Un IP residenziale nella Spamhaus PBL è un listing di policy, non un'accusa: significa che l'indirizzo non dovrebbe inviare posta direttamente. Decidete lista per lista che cosa costituisce un avviso (vedete la rimozione da Spamhaus).

Che cosa fare quando viene rilevato un listing

1. Confermatelo. Controllate la pagina di verifica del gestore e annotate il nome della lista, l'ora e l'eventuale motivo indicato.
2. Eliminate prima la causa. Cercate account compromessi, moduli web abusati, macchine infette, scarsa igiene delle liste e reverse DNS (PTR) o nomi HELO non coerenti. Richiedere la rimozione mentre la causa persiste di solito porta a un nuovo listing.
3. Seguite la procedura di rimozione di quella lista. La decisione sulla rimozione spetta a ciascun gestore di lista, e presentare una richiesta non garantisce che il listing venga revocato. Se non controllate l'IP, come nel caso dell'hosting condiviso, contattate il vostro provider di hosting o ISP.
4. Lasciate che il monitoraggio confermi il risultato. I destinatari applicano anche filtri propri, quindi tenete d'occhio il recapito dopo che il verdetto è tornato clean.

Per una verifica una tantum di un IP o di un dominio, usate il blacklist checker. Se individuare la causa o gestire le richieste è più di quanto possiate affrontare, potete chiederci aiuto. Per il percorso completo di risoluzione dei problemi quando la posta viene respinta, vedete email bloccate dalle blacklist.

Domande frequenti

Pagine ufficiali consultate

Le informazioni di questo articolo sono state verificate sulle pagine ufficiali indicate di seguito al momento della pubblicazione. Le policy e il funzionamento possono cambiare senza preavviso: prima di fare affidamento su un'informazione importante, consulti le pagine ufficiali.

• 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?

Guide correlate

Tutte le guide →