Home › Guide

Che cos'è una DNSBL (RBL)? Come funzionano le blacklist DNS

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

Una DNSBL (DNS-based blacklist, detta anche DNS blocklist o RBL) è un elenco di indirizzi IP o nomi di dominio che il gestore della lista considera una fonte di spam o di abusi, pubblicato in modo che chiunque possa consultarlo con una normale interrogazione DNS. I server di posta cercano ogni mittente che si connette in una o più DNSBL e poi rifiutano il messaggio, lo accettano oppure aggiungono il risultato a un punteggio di spam.

Questa guida spiega come funziona una ricerca DNSBL (indirizzi IP invertiti, record A e TXT, formato nibble per IPv6), la differenza tra liste basate sugli IP e liste basate sui domini, come i destinatari usano concretamente le risposte, in che cosa le blacklist differiscono dalle whitelist, perché gli indirizzi vengono elencati e quale ruolo ha un listing quando le vostre email non vengono recapitate. Si basa su RFC 5782 e sulla documentazione ufficiale dei principali gestori di liste aggiornate a novembre 2026.

Che cosa significano DNSBL e RBL

RFC 5782, "DNS Blacklists and Whitelists", usa il termine generico DNSxL per una zona DNS i cui record identificano host presenti in una lista. Una blacklist è una DNSBL; una whitelist è una DNSWL. Le due sono costruite allo stesso modo. Cambia solo il significato che il destinatario attribuisce a una corrispondenza.

RBL sta per Real-time Blackhole List. Secondo la RFC, la prima lista di questo tipo è nata nel 1997 ed è diventata nota con questo nome. In senso stretto, RBL indica quella lista originale e la sua discendente, e la RFC osserva che il termine è un marchio di servizio registrato negli Stati Uniti. Nell'uso quotidiano, però, "RBL" e "DNSBL" sono usati quasi come sinonimi, quindi "che cos'è una RBL" e "che cos'è una DNSBL" sono di fatto la stessa domanda.

RFC 5782 è un documento informativo (Informational), non uno standard Internet. È stato prodotto dall'IRTF Anti-Spam Research Group e rappresenta il consenso di quel gruppo sulle pratiche che migliorano l'interoperabilità tra blacklist e whitelist DNS. Non descrive né raccomanda policy per l'aggiunta o la rimozione degli indirizzi; la RFC prevede che questo aspetto sia trattato in un documento separato. In pratica, ogni gestore stabilisce la propria policy di inserimento e rimozione.

Come funziona una ricerca DNSBL

Una ricerca DNSBL è una normale query DNS, quindi per un controllo manuale non serve alcun software speciale: qualunque strumento in grado di risolvere un nome può interrogare una lista. I gestori delle liste possono però fissare condizioni d'uso. I server pubblici di Spamhaus, per esempio, sono gratuiti solo per un uso non commerciale a basso volume, e le query tramite resolver pubblici non ricevono risposte affidabili (vedete più avanti).

IPv4: invertire l'indirizzo e aggiungere la zona

Per un indirizzo IPv4, scrivete i quattro ottetti in ordine inverso e aggiungete il nome della zona della lista. La struttura è ripresa dal reverse DNS. L'esempio di RFC 5782 controlla 192.0.2.99 su una lista presso bad.example.com cercando:

99.2.0.192.bad.example.com

Il record A dice "elencato", il record TXT dice perché

• Record A. Ogni voce elencata deve avere un record A. Per convenzione il suo valore è 127.0.0.2. Il valore è un segnale, non un indirizzo, e non deve essere usato come tale; le liste usano l'intervallo 127.0.0.0/8 affinché un valore usato per errore non generi traffico di rete indesiderato.
• Non elencato. Se l'indirizzo non è nella lista, non ci sono record per esso, quindi la query normalmente restituisce NXDOMAIN.
• Record TXT. Una DNSBL dovrebbe pubblicare un record TXT che descriva il motivo del listing. I client devono controllare il record A e possono controllare anche il record TXT.
• Valori diversi per sottoliste diverse. Una lista combinata può restituire valori 127.0.0.x diversi per indicare quale sottolista ha dato corrispondenza, oppure più record A contemporaneamente. Il significato è specifico di ciascuna lista, quindi leggete sempre la documentazione del gestore. La nostra guida ai codici di risposta delle DNSBL tratta quelli più comuni.

Da terminale (la zona qui è un segnaposto):

dig +short 99.2.0.192.bad.example.com A
dig +short 99.2.0.192.bad.example.com TXT

Voci di test

RFC 5782 richiede che le liste IPv4 contengano una voce per 127.0.0.2 e non ne contengano una per 127.0.0.1. Ci si aspetta che i client controllino queste voci di test prima di fidarsi di una zona, e che non usino una zona che risponde in modo errato.

IPv6: il formato nibble

Un indirizzo IPv6 si scrive per esteso come 32 cifre esadecimali, poi si inverte una cifra (un nibble) alla volta, con un punto tra ciascuna, seguito dalla zona della lista. L'esempio della RFC, per 2001:db8:1:2:3:4:567:89ab su ugly.example.com:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.com

Le liste IPv6 devono contenere la voce di test ::FFFF:7F00:2 (127.0.0.2 come indirizzo IPv4-mapped) e non devono contenere ::FFFF:7F00:1. Non tutte le liste supportano IPv6, quindi controllate la documentazione del gestore prima di fare affidamento su una ricerca IPv6.

Liste basate sugli IP e liste basate sui domini

Le liste si dividono in due grandi tipi, a seconda di ciò che contengono.

Nell'esempio di dominio di RFC 5782, invalid.edu viene controllato su doms.example.net cercando invalid.edu.doms.example.net. Le liste basate sui domini sono talvolta chiamate RHSBL (right-hand-side blacklist). Le loro voci di test usano nomi riservati: la lista deve contenere TEST e non deve contenere INVALID.

La Spamhaus Domain Blocklist (dbl.spamhaus.org) è un esempio molto diffuso, e la sua documentazione evidenzia alcuni aspetti pratici:

• Contiene solo domini. Interrogarla con un indirizzo IP restituisce sempre un codice "elencato", quindi non deve essere configurata come una generica DNSBL per IP. Spamhaus consiglia ZEN (zen.spamhaus.org) per le ricerche sugli IP.
• Potete interrogare un hostname completo; c'è corrispondenza se il dominio dell'host è elencato.
• Durante la sessione SMTP viene controllata sulla stringa HELO e sul dominio MAIL FROM. Dopo l'accettazione del messaggio, viene controllata sui domini presenti negli header e nel corpo, come URL e indirizzi di contatto.

La conseguenza pratica: un IP di invio pulito non garantisce il recapito. Un dominio mittente elencato, o un dominio elencato linkato nel messaggio, può comunque causare un blocco.

Come i server riceventi usano le DNSBL

RFC 5782 descrive la configurazione tipica. Un server di posta controlla un insieme configurato di DNSxL a ogni connessione SMTP in arrivo. Una corrispondenza in una blacklist lo porta a rifiutare la connessione; una corrispondenza in una whitelist lo porta ad accettarla. In alternativa, i risultati alimentano una funzione di punteggio che li pondera insieme ad altri segnali. I filtri che operano dopo la ricezione del messaggio di solito estraggono gli IP da verificare dai campi header Received o dagli URI nel corpo.

Rifiutare o assegnare un punteggio?

La scelta spetta al destinatario. La FAQ di SpamCop definisce la propria lista uno strumento aggressivo e raccomanda di contrassegnare o deviare lo spam sospetto, oppure di usare la lista come un fattore di un punteggio, anziché rifiutare la posta in modo diretto. Descrive le impostazioni di rifiuto come informazioni per gli amministratori che non possono adottare un approccio più sfumato.

Insidie di cui i destinatari vengono avvertiti

• Delegate il giudizio. Usare una DNSxL significa affidare una parte della gestione del vostro server al gestore della lista. La RFC dice che dovreste assicurarvi che le policy della lista siano coerenti con le vostre.
• Liste dismesse. Un gestore che chiude una lista potrebbe installare un wildcard che elenca tutti gli indirizzi. Le voci di test descritte sopra servono al client per accorgersene.
• Caching. I server possono memorizzare i risultati nella cache, ma devono rispettare i TTL ed eliminare i record scaduti.
• Resolver pubblici. La FAQ di Spamhaus afferma che le query tramite Google Public DNS nella maggior parte dei casi restituiranno "non elencato", quindi i listing reali sfuggono. I codici in 127.255.255.x sono errori, come 127.255.255.254 per una query tramite un resolver pubblico bloccato, e non devono essere interpretati come "elencato". Spamhaus osserva che alcuni server rifiutano per errore tutta la posta a causa di questo e consiglia di gestire un proprio resolver.

Questo è uno dei motivi per cui due strumenti di verifica possono dare risultati diversi sullo stesso indirizzo: potrebbero interrogare tramite resolver diversi.

Blacklist e whitelist a confronto (DNSBL e DNSWL)

Una DNSBL e una DNSWL si interrogano allo stesso modo, ma una corrispondenza ha il significato opposto. Secondo RFC 5782, chi gestisce le reti usa tipicamente le DNSBL per bloccare il traffico e le DNSWL per accettarlo in via preferenziale. La stessa lista può persino fungere da blacklist in un contesto e da whitelist in un altro.

dnswl.org (list.dnswl.org) è un esempio di whitelist. La sua documentazione indica che le risposte hanno la forma 127.0.x.y, dove x è una categoria e y un livello di fiducia da 0 (nessuno) a 3 (alto). Suggerisce di consentire agli host elencati di saltare il greylisting e i controlli sulle blacklist, di consentire agli host con fiducia media e alta di saltare il filtro antispam e di non saltare mai la scansione antivirus. Quanto una voce in whitelist esenti dai controlli resta comunque una decisione del destinatario.

Motivi comuni per cui un IP o un dominio viene elencato

Ogni gestore stabilisce i propri criteri, e molti mantengono riservati i fattori scatenanti esatti. I motivi seguenti provengono dalla documentazione pubblicata dai gestori.

• Segnalazioni di spam e spam trap. La SpamCop Blocking List contiene gli IP che hanno inviato posta segnalata dagli utenti di SpamCop, con un peso maggiore per la posta inviata a spam trap (indirizzi raccolti o creati dagli spammer). La sua FAQ afferma che, in assenza di ulteriori segnalazioni, un listing dura solo 24 ore, e gli indirizzi vengono rimossi automaticamente quando le segnalazioni cessano.
• Dispositivi infetti o compromessi. La Spamhaus XBL elenca automaticamente gli IP sulla base di prove come malware, app di "VPN gratuita" che instradano traffico di terzi attraverso il dispositivo, partecipazione ad attacchi brute force o tentativi di inoltrare posta con credenziali rubate. Se la causa persiste, l'IP viene elencato di nuovo alla connessione successiva.
• Configurazione errata e scarsa igiene delle liste. La Spamhaus CSS cita nomi HELO che non corrispondono al DNS diretto, siti web e installazioni CMS compromessi, configurazioni non sicure e mailing list mal gestite. Afferma che la causa deve essere individuata e corretta prima della rimozione.
• Listing di policy. La Spamhaus PBL copre spazi di indirizzi, spesso di banda larga residenziale, che non dovrebbero inviare posta direttamente. Spamhaus afferma che un listing PBL non deriva da nulla che l'utente finale abbia fatto; ci si aspetta che la posta da questi intervalli esca tramite un server SMTP autenticato.
• Infrastruttura condivisa. Su un hosting condiviso, gli invii di un altro cliente possono influire sull'IP che usate. Vedete che cosa fare quando l'IP di un hosting condiviso è in blacklist.

Il ruolo delle DNSBL quando le email non vengono recapitate

Un listing in una DNSBL è una possibile causa della mancata consegna, non l'unica. Anche indirizzi errati, caselle piene, problemi lato destinatario e autenticazione mancante possono causare bounce. Quando è coinvolta una lista, il messaggio di bounce spesso la nomina o include un URL di verifica.

1. Leggete il bounce. Annotate il codice di risposta e l'eventuale nome della lista o URL nel testo.
2. Individuate l'IP e il dominio di invio. Usate le righe Received negli header, oppure chiedete a chi gestisce il server.
3. Controllate le principali liste in una volta. Usate il blacklist checker, poi confermate ogni corrispondenza sulla pagina di verifica del gestore.
4. Eliminate la causa. Esaminate le cause elencate sopra. Le richieste presentate prima di aver eliminato la causa di solito si concludono con un nuovo listing.
5. Seguite la procedura di quel gestore. Alcune liste scadono da sole, alcune accettano una richiesta di rimozione e alcune accettano richieste solo dal proprietario della rete. La decisione sulla rimozione spetta sempre al gestore della lista, e una richiesta non è una promessa di rimozione.

I destinatari applicano anche i propri filtri, quindi la posta potrebbe non tornare a fluire nel momento esatto in cui un listing termina. Per la sequenza completa di risoluzione dei problemi, vedete email in blacklist: come leggere il bounce, e per l'autenticazione, configurazione di SPF, DKIM e DMARC. Se non riuscite a individuare la causa da soli, potete chiederci aiuto.

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: Domain Blocklist (DBL)
• Spamhaus: Exploits Blocklist (XBL)
• Spamhaus: Combined Spam Sources (CSS)
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• dnswl.org: Return codes and recommended usage

Guide correlate

Tutte le guide →