Controllo blacklist email: cosa non dicono gli strumenti

Un controllo blacklist email confronta l'IP di invio con un insieme di liste DNS pubbliche e restituisce una tabella di righe verdi e rosse. Quella tabella risponde a una domanda stretta: questo indirizzo è presente adesso in una blocklist DNS pubblica? Un controllo blacklist email non dice se Gmail, Outlook o un gateway aziendale accetteranno il prossimo messaggio, e trattare le due cose come se fossero la stessa domanda è dove la maggior parte delle cronologie di incidente va storta.

Questa guida spiega che cosa interroga davvero un controllo, come eseguirlo a mano con dig, quali codici significano "pulito" e quali significano "query rifiutata", e come collegare il tutto al monitoraggio per smettere di farlo a mano alle due di notte.

Un controllo blacklist è una query DNS, nulla di più

Ogni DNS blocklist (DNSBL) funziona allo stesso modo. Si invertono gli ottetti dell'indirizzo IPv4, si aggiunge la zona della lista e si richiede un record A. La RFC 5782 definisce la convenzione: per 192.0.2.99 verificato contro bad.example.com, la query è 99.2.0.192.bad.example.com. Se l'indirizzo è in lista si ottiene una risposta nell'intervallo 127.0.0.0/8. Se non è in lista, non arriva alcun record.

Questo è l'intero meccanismo. Gli strumenti web in cui si incolla un IP eseguono decine di queste ricerche in parallelo e ne formattano le risposte.

# 203.0.113.25 è presente nella lista ZEN di Spamhaus?
dig +short 25.113.0.203.zen.spamhaus.org A

# Una ricerca su una lista basata sui domini funziona allo stesso modo, senza inversione:
dig +short example.com.dbl.spamhaus.org A

Output vuoto significa non in lista. Una risposta 127.x.x.x significa in lista, e gli ultimi ottetti indicano quale sotto-lista ha trovato la corrispondenza. Eseguito da una macchina sotto il proprio controllo, verso il proprio resolver, il comando si può automatizzare, registrare e far generare allarmi.

Controllate l'indirizzo da cui esce la posta, non quello del sito

Il primo errore è verificare l'IP sbagliato. Il sito marketing, le API e il relay di posta in uscita sono di solito tre indirizzi diversi. Quello che conta è l'IP presente nell'header Received di un messaggio realmente consegnato a una casella.

Se si invia tramite un ESP su infrastruttura condivisa, quell'IP non è proprio e non lo è nemmeno l'eventuale iscrizione in lista. Se si invia da un IP dedicato, è interamente proprio, incluso tutto ciò che il precedente utilizzatore di quell'intervallo ha fatto.

Prelevare l'IP di invio da un messaggio consegnato, non da un'impostazione del pannello. Poi verificare tre elementi distinti: l'IP di invio, i domini envelope e From, e ogni dominio presente nei link, inclusi gli host di tracciamento e di disiscrizione. Le liste basate su URI, come URIBL e SURBL, valutano i link nel corpo del messaggio, quindi un IP pulito non protegge un messaggio che punta a un dominio in lista.

Una risposta pulita da un resolver pubblico può essere un rifiuto mascherato

È il guasto di cui le pagine dei controlli generici non parlano mai. Spamhaus non risponde alle query che arrivano tramite resolver pubblici o aperti, e lo segnala con un codice di risposta invece che con un'iscrizione in lista. Spamhaus documenta 127.255.255.254 come codice di errore, non come risultato di reputazione, e precisa che non va mai usato per rifiutare la posta.

Ne derivano due conseguenze. Se lo script interpreta qualsiasi risposta 127.x come "in lista", una query rifiutata da un resolver cloud genererà un allarme per un'iscrizione che non esiste. Se interpreta "nessuna risposta utilizzabile" come "pulito", perderà in silenzio le iscrizioni reali, perché anche il rifiuto può presentarsi come risposta vuota o NXDOMAIN.

La soluzione è eseguire le ricerche da un host con un proprio resolver ricorsivo e un reverse DNS corretto, oppure usare il servizio di query gratuito verso cui Spamhaus indirizza gli utenti dei mirror pubblici. In ogni caso, validare la zona prima di fidarsi dei risultati. La RFC 5782 richiede che le liste IPv4 contengano una voce per 127.0.0.2 e nessuna voce per 127.0.0.1, quindi la configurazione si può testare così:

dig +short 2.0.0.127.zen.spamhaus.org A   # deve restituire una risposta 127.x
dig +short 1.0.0.127.zen.spamhaus.org A   # non deve restituire nulla

Se entrambe restituiscono un risultato vuoto, il percorso del resolver è interrotto o rifiutato. Va sistemato prima di leggere qualsiasi risultato da quel percorso.

La maggior parte degli incidenti di consegna non sono incidenti da blocklist

In una revisione dei bounce, la prima domanda da porsi prima di qualsiasi ricerca è che cosa ha effettivamente risposto il server ricevente. Un'iscrizione in lista produce un rifiuto specifico. I problemi di reputazione presso un provider di posta producono un rifiuto diverso, che nessuna lista pubblica mostra.

La documentazione di Google per i mittenti è esplicita. Una risposta 550 5.7.1 può indicare che l'IP di invio è in una lista di sospensione, spesso per una cattiva reputazione di un IP condiviso, mentre 5.7.26 segnala un'autenticazione fallita. Per i mittenti in volume Google richiede SPF, DKIM e DMARC, record DNS diretto e inverso validi per l'IP di invio, TLS e un tasso di spam inferiore allo 0.30% in Postmaster Tools. I requisiti per i mittenti Gmail indicano lo 0.10% come obiettivo raccomandato.

Va letto come un ordine di operazioni. Se il testo del bounce nomina una zona o un URL DNSBL, il problema è una iscrizione in lista su quella lista specifica. Se parla di reputazione, autenticazione o limiti di frequenza, una ricerca in blocklist tornerà pulita e si sarà persa un'ora a confermarlo.

• Il testo nomina una zona o un URL DNSBL: il messaggio è in lista su quella lista. Eseguire la ricerca, poi usare la pagina di rimozione dell'operatore.

• 550 5.7.1 con riferimento alla reputazione dell'IP: reputazione lato provider, spesso su un IP condiviso. Controllare Postmaster Tools e l'andamento di volumi e reclami.

• 5.7.26: autenticazione fallita. Verificare l'allineamento di SPF, DKIM e DMARC.

• 4.7.28 o testo sui limiti di frequenza: si invia troppo in fretta per la reputazione attuale. Rallentare, poi risalire gradualmente.

Smettere di usare il controllo web una tantum come monitoraggio

Una verifica isolata descrive lo stato nel momento in cui si preme invio. Le iscrizioni in lista sono spesso transitorie e molte compaiono dopo un picco che si è causato da soli: un import a freddo, un nuovo invio di conferma dei consensi, un modulo compromesso usato per inoltrare spam.

Gli strumenti che si fanno pagare per "rimuoverti da 100 blacklist" vendono un servizio per un problema che la maggior parte di quelle liste non ha. Molte delle liste presenti in un controllo multiplo tipico hanno un impatto trascurabile sui principali provider di posta, e la rimozione è di solito gratuita e self-service sulla pagina dell'operatore. Inseguire ogni riga rossa sottrae tempo a quelle due o tre liste che i destinatari consultano davvero.

Classificare le liste in base al traffico che si invia. Osservare quali destinatari compaiono nei bounce, individuare le liste che quei destinatari usano pubblicamente e monitorare quelle. Tutte le altre sono rumore da rivedere una volta al mese.

Trasformare il controllo in un job programmato con una soglia di allarme

Ecco la versione minima che regge. Gira da un host con un resolver reale, valida la zona prima di tutto e distingue i tre esiti: in lista, non in lista e query rifiutata.

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 "not_listed"
    if answer.startswith("127.255.255."):
        return "refused"   # codice di errore, non un risultato di reputazione
    return f"listed:{answer}"

# Verificare la zona prima di fidarsi (voci di test RFC 5782)
assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listed")
assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "not_listed"

Eseguire il controllo ogni 15-60 minuti, per IP di invio e per dominio di invio, registrare ogni risultato con il timestamp e generare un allarme solo alla transizione da not_listed a listed. Generare un allarme separato per refused, perché significa che il monitoraggio è cieco, non che la reputazione è cambiata.

Abbinarlo ai segnali che le blocklist seguono con ritardo. Il tasso di reclami dalle dashboard Postmaster, il tasso di bounce per dominio ricevente e il tasso di differimento per ora si muovono prima che compaia un'iscrizione, e sono i numeri che dicono se mettere in pausa un invio. Se si inviano già log e metriche a uno stack di monitoraggio, il risultato della ricerca è solo un'altra serie temporale.

Quattro strumenti si adattano a questo flusso, a seconda di dove si trova il problema.

Postmark è solo transazionale, quindi i reset password non condividono il percorso di invio con la newsletter di qualcun altro. Se le iscrizioni risalgono sempre a un vicino su infrastruttura condivisa, separare l'invio transazionale da quello marketing è la correzione strutturale.

Resend è l'opzione orientata agli sviluppatori, con un'API pulita e una superficie ridotta da strumentare. Vale la pena quando il team scriverà comunque i propri controlli di deliverability.

SendGrid ha la storia più lunga a grandi volumi e offre IP dedicati, il che significa che la reputazione, e quindi l'esposizione alle blocklist, è interamente di chi invia. Da evitare se non si può dedicare personale al warm-up e al monitoraggio che gli IP dedicati richiedono.

Better Stack copre il lato dei job programmati: controlli in stile uptime, allerte e instradamento on-call per lo script sopra, così una nuova iscrizione arriva a una persona invece che a un file di log.

Quando si è in lista, correggere la causa prima di chiedere la rimozione

Chiedere la rimozione senza una causa radice compra solo pochi giorni. L'operatore di una lista che vede lo stesso indirizzo tornare con lo stesso comportamento lo inserirà di nuovo, e alcuni operatori inaspriscono le misure con le iscrizioni ripetute.

Procedere in quest'ordine:

1. Fermare o rallentare l'invio dall'IP in lista. Il traffico scorretto che continua allunga l'iscrizione e ne aggiunge di nuove.

2. Leggere il registro dell'iscrizione presso l'operatore della lista. Molti indicano la prova: un hit su trappola per spam, un picco, una segnalazione di relay abusivo.

3. Trovare la fonte. Controllare gli endpoint dei moduli per un abuso di open relay, guardare gli import recenti delle liste e verificare ogni nuova integrazione partita negli ultimi sette giorni.

4. Correggere la causa, poi usare il processo di rimozione dell'operatore. Alcune liste scadono automaticamente dopo un periodo di silenzio.

5. Riprendere a volume ridotto, verso i destinatari più coinvolti per primi, e monitorare tasso di reclami e differimenti per una settimana.

Un reverse DNS mancante è una causa ricorrente. Google include i record PTR validi tra i requisiti per i mittenti, e un IP di invio senza PTR appare poco affidabile a molti destinatari prima ancora che il contenuto venga valutato.

Costruire il flusso lifecycle attorno al segnale, non alla lista

Se il prodotto invia email di attivazione, fatturazione o sicurezza, un'iscrizione in lista è un incidente di disponibilità per quei flussi, e va trattata come tale. Instradare la posta transazionale su un percorso isolato dal volume marketing, e fare in modo che il livello dei trigger conosca lo stato della consegna, così un'email di attivazione bloccata ricade su un suggerimento in-app.

Customer.io è il livello a eventi che molti abbinano a un provider di consegna separato proprio per questo motivo: i trigger comportamentali e la logica dei messaggi stanno in un solo posto, la consegna in un altro, e la consegna si può sostituire o dividere senza riscrivere i flussi. Il compromesso è un sistema in più da tenere osservabile.

Questa separazione è la parte da copiare anche scegliendo fornitori diversi. Un evento di blocklist dovrebbe cambiare dove va un messaggio, non se la logica lifecycle funziona.

Cosa mettere in piedi questa settimana

Tre cose, in ordine di resa. Primo, un controllo programmato con validazione della zona e uno stato distinto refused, eseguito da un host con un proprio resolver. Secondo, la ripartizione dei bounce per dominio ricevente, così si sa quali liste contano per il proprio traffico. Terzo, un runbook scritto che parte dal testo del bounce e termina con il passo di rimozione, perché chi è in turno non debba improvvisare.

Quale dominio di invio passerebbe inosservato se finisse in lista per un giorno?