1,206 26/03/2026 07/04/2026 10 min

Elenco dei DNSBL aggiornati 2026

Nel 2026 i DNSBL restano uno strumento pratico contro spam e abuso SMTP. Non bastano da soli, ma fanno ancora la differenza su server email seri.

Se gestisci un dominio, un VPS o un relay aziendale, ti serve un elenco pulito e aggiornato. Ti serve anche sapere quali liste usare, come leggerle, e come evitare falsi positivi.

Warning: i DNSBL cambiano politiche, domini e criteri di listing. Prima di attivarli in produzione, verifica sempre la documentazione ufficiale e il tipo di traffico che gestisci.

Note: in ambienti enterprise è meglio usare poche liste ben scelte, non decine di DNSBL a caso. Troppe liste aumentano latenza, complessità e rischio di bloccare mittenti legittimi.

Prerequisiti

Prima di toccare il filtro antispam, prepara questi elementi. Ti evitano test confusi e blocchi inutili.

  • Accesso amministrativo al pannello mail del server o del provider.
  • Possibilità di modificare Postfix, Exim, Rspamd, SpamAssassin o il gateway SMTP.
  • DNS funzionante e stabile sul server.
  • Log mail accessibili da pannello o shell.
  • Un indirizzo di test esterno, meglio se su Gmail, Outlook o un dominio controllato.

Se usi un pannello, cerca prima la sezione mail. In cPanel di solito vai in Email → Spam Filters o nei filtri avanzati. In Plesk controlla Mail → Spam Filter. In molti pannelli hosting puoi anche attivare Rspamd dal menu email.

Se lavori da terminale, i componenti più comuni sono questi:

postconf -n | grep -E 'smtpd_recipient_restrictions|check_policy_service|reject_rbl_client'
rspamc -h 127.0.0.1:11334 stat
spamassassin -D < /dev/null

# Output: impostazioni mail attive, statistiche Rspamd o debug SpamAssassin

Un DNSBL serio non va scelto per fama. Va scelto per reputazione, copertura, aggiornamento e compatibilità con il tuo stack. Un provider con 50.000 email al giorno ha esigenze diverse da un sito vetrina.

Step 1: definisci la strategia prima di caricare le liste

Il primo errore è attivare tutto insieme. Prima decidi se vuoi usare i DNSBL per bloccare, penalizzare o solo segnalare.

Su un server piccolo puoi partire con una soglia morbida. Su un gateway aziendale puoi combinare DNSBL, SPF, DKIM, DMARC e reputation locale.

Se usi un pannello con SpamAssassin o Rspamd, apri la sezione antispam e cerca i controlli di reputazione. In Plesk, per esempio, puoi intervenire su Mail → Spam Filter → Customize. In cPanel puoi agire sui filtri spam del dominio o della casella.

Da terminale, in Postfix la logica tipica si appoggia a reject_rbl_client. Esempio minimale:

smtpd_recipient_restrictions =
  permit_mynetworks,
  reject_unauth_destination,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client bl.spamcop.net

# Output: connessioni SMTP da IP in blacklist respinte durante la sessione

Questo approccio è semplice. Funziona bene se hai poco traffico e vuoi un controllo chiaro sui log. Se il tuo flusso è più complesso, Rspamd è spesso più flessibile.

DNSBL aggiornati 2026: elenco pratico e uso consigliato

Qui sotto trovi un elenco ragionato, orientato all’uso reale nel 2026. Non è un invito a usarli tutti insieme. È una base di lavoro per scegliere con criterio.

  • zen.spamhaus.org — aggregatore molto usato. Copre più segnali. Ottimo come prima lista principale.
  • bl.spamcop.net — utile per traffico spam osservato dalla community. Buono come seconda opinione.
  • dnsbl.sorbs.net — storico, ma va usato con cautela. Politiche ampie e rischio di falsi positivi.
  • psbl.surriel.com — lista semplice e spesso efficace contro IP noti per spam diretto.
  • ubl.unsubscore.com — usata in alcuni stack legacy. Verifica sempre stato e copertura prima di adottarla.
  • ix.dnsbl.manitu.net — lista europea spesso citata in ambienti SMTP regionali.
  • dnsbl-1.uceprotect.net — molto aggressiva. Da valutare solo con policy chiare e test accurati.
  • truncate.gbudb.net — utile in scenari dove serve una reputazione IP ampia, ma controlla la compatibilità con il tuo MTA.
  • rbl.abuse.ro — può essere interessante per controlli supplementari su IP sospetti.
  • blacklist.woody.ch — lista da verificare con attenzione, spesso usata in contesti specifici.

Warning: alcune liste hanno politiche severe, copertura regionale o criteri non adatti a mail server condivisi. Non attivarle mai senza test su indirizzi reali e log osservabili.

Per una configurazione prudente nel 2026, la combinazione più comune resta questa: una lista aggregata principale, una lista secondaria, e un sistema di scoring. Così riduci i blocchi secchi.

Step 2: aggiorna la configurazione nel pannello o nel MTA

Qui la strada cambia in base all’ambiente. Se hai un pannello, usa l’interfaccia. Se hai un server gestito da te, modifica la configurazione del mail transfer agent.

In Plesk vai in Mail → Spam Filter → Switch on server-wide spam filtering, poi apri le opzioni avanzate. Inserisci le liste DNSBL supportate dal tuo backend, se il pannello le espone.

In cPanel entra in Email → Spam Filters. Attiva il filtro globale, poi regola soglie e whitelist. Se il server usa Exim, spesso il provider espone anche i parametri di blacklist nel backend di hosting.

Se gestisci Postfix, aggiungi o modifica i parametri nel file di configurazione. Esempio:

postconf -e 'smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net'
postfix reload

# Output: nuova policy caricata senza riavvio completo del servizio

Con Rspamd, la configurazione passa spesso da file YAML. Un esempio minimo:

rules:
  dnsbl:
    enabled: true
    servers:
      - zen.spamhaus.org
      - bl.spamcop.net
    score: 3.0

# Output: controllo DNSBL attivo con punteggio assegnato ai match

Note: alcuni provider mail non permettono modifiche profonde al filtro DNSBL. In quel caso puoi solo regolare sensibilità, whitelist e policy di quarantena dal pannello.

Se usi SpamAssassin, il file tipico è local.cf. Un esempio pratico:

score RCVD_IN_ZEN 3.5
score RCVD_IN_BL_SPAMCOP_NET 2.0
use_bayes 1

# Output: i messaggi che cadono nelle liste ottengono un punteggio più alto

Step 3: scegli le liste in base al rischio reale

Non tutte le mail hanno lo stesso profilo di rischio. Un e-commerce riceve più mail transazionali. Un ufficio legale riceve più allegati e meno volume. Un provider hosting vede molto più rumore.

Per questo l’elenco DNSBL aggiornato 2026 va letto per scenario.

  • Scenario basso rischio: usa una sola lista aggregata e scoring moderato.
  • Scenario medio: usa due liste, più SPF, DKIM e DMARC.
  • Scenario alto volume: usa DNSBL, reputazione interna, greylisting e analisi comportamentale.

Un esempio concreto. Se gestisci un negozio WooCommerce, non vuoi bloccare un cliente vero che scrive da un provider consumer con reputazione ballerina. In quel caso meglio segnare il messaggio come sospetto, non respingerlo subito.

Se invece gestisci un relay interno per ticket e notifiche, puoi essere più aggressivo. Lì il traffico in ingresso è più prevedibile.

Per chi usa un gateway con interfaccia web, la logica è spesso questa: vai in Antispam → DNSBL → Enable, poi aggiungi le liste in una whitelist/blacklist per dominio o IP. Molti pannelli permettono anche regole per paese o ASN.

Warning: non confondere DNSBL e URIBL. I primi filtrano IP o host. I secondi analizzano URL nel contenuto. Servono entrambi, ma risolvono problemi diversi.

Step 4: testa prima in modalità osservazione

La modalità migliore è sempre quella di osservazione. Prima misura, poi blocca. Questo vale ancora di più con DNSBL aggressive.

Se il tuo stack supporta il test, imposta una policy di log-only. In Rspamd puoi alzare il logging. In SpamAssassin puoi analizzare il punteggio senza rifiutare al primo match. In Postfix puoi temporaneamente spostare il reject più in basso o usare un milder action.

Da terminale, controlla una singola lista con dig. Esempio con un IP pubblico invertito:

dig +short 2.0.0.127.zen.spamhaus.org A

# Output: risposta DNS con codice di listing, oppure nessun record se non listato

Per un test reale, invia una mail da un account esterno verso la tua casella. Poi controlla i log.

grep -iE 'rbl|dnsbl|spamhaus|spamcop|reject' /var/log/mail.log

# Output: righe di log con il motivo del rifiuto o del punteggio

Se usi un pannello, entra nei log email e cerca il mittente di test. In Plesk e in molti hosting cPanel trovi la cronologia dei messaggi nella sezione Mail Log o nei log del dominio. L’obiettivo è capire se il messaggio è stato respinto, marcato o consegnato con punteggio alto.

Step 5: costruisci whitelist e soglie con criterio

Un DNSBL utile senza whitelist diventa presto un problema operativo. Le whitelist devono coprire servizi di pagamento, CRM, helpdesk, newsletter affidabili e relay interni.

Nel pannello, cerca la sezione Whitelist o Allowed senders. Inserisci domini come @vendor-payments.example o IP dei tuoi provider noti. Se il pannello supporta il dominio completo, meglio ancora.

Con Postfix e access maps puoi fare così:

postmap /etc/postfix/sender_access
postconf -e 'smtpd_sender_restrictions=check_sender_access hash:/etc/postfix/sender_access,reject_unauth_destination'
postfix reload

# Output: whitelist mittenti applicata e configurazione ricaricata

Con Rspamd puoi dare un punteggio negativo a mittenti sicuri o a IP interni.

multimap:
  trusted_senders:
    type: from
    map:
      - 'billing@example.com'
      - '@crm.example.net'
    score: -5.0

# Output: i mittenti fidati abbassano il punteggio spam

Note: le whitelist vanno revisionate. Un fornitore affidabile oggi può cambiare infrastruttura domani. Se aggiorni un contratto o un dominio, controlla anche i record SPF e DKIM.

Verifica finale

La verifica finale non è solo “arriva la mail”. Devi controllare tre cose: punteggio, log e coerenza con il comportamento atteso.

  1. Invia una mail pulita da un account esterno noto.
  2. Invia una mail da un IP o servizio che sai essere in blacklist di test.
  3. Confronta il risultato nel pannello o nei log.
  4. Controlla che i messaggi legittimi non vengano respinti.
  5. Verifica che i messaggi sospetti vengano marcati o messi in quarantena.

Se hai accesso shell, puoi anche controllare la risoluzione DNS e i tempi di risposta. Liste lente o instabili vanno evitate.

time dig +short 2.0.0.127.zen.spamhaus.org A
resolvectl query 2.0.0.127.zen.spamhaus.org

# Output: risposta rapida o, se la lista non è raggiungibile, nessun record e tempi coerenti

Un buon risultato, nel 2026, è questo: pochi match, log leggibili, nessun blocco ai provider legittimi, e una quarantena che intercetta gli abusi evidenti.

Troubleshooting

Errore 1: host zen.spamhaus.org not found: 3(NXDOMAIN)

Causa: il resolver del server non riesce a risolvere il nome della lista oppure la configurazione è sbagliata.

Fix: verifica DNS locali, poi testa il resolver pubblicamente e ricarica il servizio.

cat /etc/resolv.conf
resolvectl status
systemctl restart systemd-resolved || true

# Output: resolver corretti e query DNSBL nuovamente funzionanti

Errore 2: connect to zen.spamhaus.org[...]: Network is unreachable

Causa: il server non ha uscita DNS affidabile o c’è un firewall che blocca le query.

Fix: controlla routing, firewall e policy outbound verso UDP/TCP 53.

nft list ruleset | grep -n '53'
ip route
ufw status verbose

# Output: traffico DNS consentito e route corretta verso Internet

Errore 3: reject_rbl_client rejected recipient

Causa: la lista ha classificato l’IP mittente come malevolo o il match è troppo aggressivo.

Fix: sposta la regola in modalità scoring, aggiungi whitelist o sostituisci la lista con una meno severa.

postconf -e 'smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination'
postfix reload

# Output: il rifiuto diretto viene rimosso e puoi testare una policy più morbida

Warning: se hai falsi positivi su provider grandi, non disattivare tutto subito. Prima isola la lista che causa il problema e misura l’impatto sul traffico reale.

Conclusione

Nel 2026 i DNSBL restano utili, ma solo se li tratti come uno strumento di precisione. Un elenco aggiornato non basta: serve selezione, test e manutenzione continua.

Il passo concreto successivo è questo: scegli due liste affidabili, attivale in osservazione per 48 ore, e confronta i log con i messaggi legittimi ricevuti. Da lì costruisci la tua policy definitiva.