In breve#
Il greylisting è una tecnica di filtraggio antispam con cui un server di posta rifiuta temporaneamente i messaggi (e i test di verifica) dei mittenti che non ha mai visto, dando una risposta SMTP del tipo "riprova più tardi" invece di un sì o un no. I server di posta legittimi riprovano qualche minuto dopo e passano; i rudimentali software di spam contro cui è nata la tecnica, storicamente, non lo facevano. Per la verifica email la conseguenza è semplice: la risposta di un server con greylisting è non ancora, quindi un verificatore onesto riprova entro il tempo a sua disposizione oppure segnala l'indirizzo come sconosciuto. Quello che non deve fare è tirare a indovinare.
Come appare il greylisting nella conversazione SMTP#
Il rinvio avviene nello stesso punto della conversazione SMTP in cui un server normale confermerebbe o rifiuterebbe la casella:
> RCPT TO:<jane@example.com>
< 451 4.7.1 Greylisted, please try again later
La prima cifra dice tutto (la grammatica completa è in I codici di risposta SMTP spiegati). Una risposta 5xx (550 5.1.1 user unknown) è permanente: l'indirizzo è morto e l'esito è undeliverable. Una risposta 4xx (421, 450, 451) è temporanea per definizione: il server sta dicendo esplicitamente che la stessa richiesta potrebbe riuscire più tardi. Le implementazioni classiche di greylisting tengono traccia dell'IP del mittente e degli indirizzi from/to, rifiutano il primo tentativo e accettano un nuovo tentativo che arriva dopo qualche minuto: è la prova che dall'altra parte c'è un vero server di posta con una coda di reinvio.
La tecnica risale ai primi anni 2000 e sopravvive perché è economica ed efficace senza far rumore: un server di posta legittimo ha di norma una coda di reinvio, quindi rinviare il primo tentativo costa ai veri mittenti solo qualche minuto, mentre i software di spam del tipo "spara e dimentica" non tornano mai. Le implementazioni tipiche memorizzano la tripletta di IP del mittente, indirizzo from e indirizzo to; quando un nuovo tentativo per quella tripletta riesce, il mittente di solito finisce in whitelist per settimane, quindi il ritardo è un pedaggio una tantum, non una tassa permanente.
Incontrerai il greylisting soprattutto su gateway di posta aziendali, server self-hosted e appliance di sicurezza. I grandi provider consumer fanno per lo più qualcosa di diverso che dall'esterno sembra identico: ne parliamo più avanti, perché la differenza conta per la verifica.
Cosa fa un 4xx a un test di verifica#
Un verificatore che incontra un server con greylisting ha esattamente tre opzioni:
- Aspettare e riprovare. È onesto e spesso efficace, ma costa tempo: la finestra del greylisting è di minuti e un job in blocco non può aspettare all'infinito.
- Segnalare un esito sconosciuto. È onesto, quando riprovare non ha risolto. L'indirizzo non è da scartare: semplicemente il server non ha mai dato una risposta utilizzabile.
- Tirare a indovinare. È disonesto. Qualsiasi strumento che trasforma un
451in un sicuro "valido" o "non valido" sta fabbricando una certezza che il server si è rifiutato di fornire.
Ecco come lo gestisce Qualisend: per un indirizzo in greylisting la verifica viene ritentata entro un tempo limitato e, se allo scadere di quel tempo il server continua a rinviare, l'esito è unknown con motivo timeout e un punteggio di affidabilità intermedio: un indirizzo da ricontrollare più avanti, non un indirizzo morto, ed è esattamente così che dovresti trattarlo.
Una sola eccezione deliberata: quando il server che rinvia appartiene a un grande provider di posta consumer, un 4xx non è quasi mai greylisting classico. È una limitazione di frequenza basata sulla reputazione, e riprovare raramente cambia la risposta. Qualisend riconosce questi casi e li chiude come unknown invece di tenere in ostaggio il tuo job per un nuovo tentativo che non servirebbe: lo stesso esito onesto, senza l'attesa.
Perché il greylisting non può bloccare la tua lista#
Il costo nascosto dei rinvii non è l'accuratezza, ma il tempo. Un verificatore in blocco ingenuo che ritenta diligentemente ogni 4xx può ritrovarsi con un job da 100.000 righe tenuto in ostaggio da una manciata di server ostinati, fermo al "99% completato" per un'ora. Lo abbiamo imparato sul campo, e oggi la pipeline ha diversi livelli di timeout e limiti, così pochi server ostinati non possono bloccare l'intero job:
- ogni conversazione SMTP ha una scadenza rigida: un server che fa tarpitting oltre quel limite diventa un
unknowne il job va avanti; - i nuovi tentativi per greylisting hanno un limite e vengono tracciati per indirizzo, invece di ripetersi in un ciclo;
- se gli ultimi indirizzi di un job smettono di fare progressi, quella coda viene chiusa come
unknowninvece di lasciare che un solo ritardatario blocchi la riga "N−1 su N", con un'ulteriore rete di sicurezza per tutto ciò che resta bloccato per altri motivi.
La nostra posizione di progetto: un unknown onesto ma tardivo batte una risposta puntuale data tirando a indovinare, ma un esito sconosciuto che ottieni in pochi minuti batte entrambi. Comunque un verificatore lo implementi, è una domanda legittima da fare a qualsiasi strumento: cosa succede al tuo job quando un server si rifiuta semplicemente di rispondere?
Il greylisting e i suoi sosia#
Diversi comportamenti dei server finiscono in una risposta che non è proprio una risposta, e corrispondono a esiti diversi:
| Cosa ha fatto il server | Segnale di protocollo | Esito Qualisend |
|---|---|---|
| Greylisting classico | 451 a un mittente sconosciuto, accetta un nuovo tentativo successivo | unknown / timeout dopo il tempo previsto per i nuovi tentativi: verifica di nuovo più avanti |
| Limitazione di frequenza del provider | 4xx da un grande provider consumer | unknown / timeout, chiuso subito: riprovare all'interno di un job non serve |
| Accettazione catch-all | 250 a ogni indirizzo, reale o no | risky / low_deliverability: vedi la
guida ai catch-all |
| Silenzio o connessione interrotta | Nessuna risposta utilizzabile | unknown / timeout o
unavailable_smtp |
| Rifiuto definitivo | Rifiuto di classe 550 | undeliverable / rejected_email |
Il filo conduttore: unknown è un'affermazione sulla conversazione, non sulla casella. risky significa che abbiamo raggiunto il server e abbiamo appreso qualcosa di preoccupante; unknown significa che l'infrastruttura non ha mai risposto in modo conclusivo. I due casi meritano un trattamento diverso sulla tua lista.
Cosa fare con gli esiti sconosciuti#
- Non sopprimere per un solo esito sconosciuto. Dietro server scontrosi vivono caselle reali e attive. Trattare un esito sconosciuto come non valido butta via iscritti solo per far sembrare decisa una dashboard.
- Verifica di nuovo più avanti. Le finestre di greylisting passano e i limiti di frequenza si azzerano: spesso lo stesso indirizzo si risolve senza problemi in una seconda esecuzione ore o giorni dopo. È anche il motivo per cui due verificatori (o due esecuzioni dello stesso) possono non essere d'accordo su un indirizzo senza che nessuno dei due menta: la casella è deterministica, il server no.
- Tieni gli esiti sconosciuti non verificati fuori dagli invii cruciali. Finché un esito sconosciuto non si risolve o non mostra coinvolgimento, trattalo come il segmento catch-all: invii piccoli e limitati, dove un bounce costa poco. Vale lo stesso metodo, esito per esito, della guida alla pulizia su Klaviyo.
- Leggi il tasso di esiti sconosciuti come un dato sui server della tua lista, non come un difetto della verifica. Le liste B2B con molti gateway aziendali avranno sempre più esiti sconosciuti delle liste consumer: non sono peggiorati gli strumenti, è l'infrastruttura a essere diventata più difensiva.
Domande frequenti
01Un esito sconosciuto significa che l'indirizzo è da scartare?
No. Un esito sconosciuto significa che durante la verifica il server di posta non ha mai dato una risposta conclusiva, per greylisting, limitazione di frequenza, timeout o server non raggiungibile. La casella dietro quell'indirizzo può essere in perfetta salute. Considera un esito sconosciuto come "riprova più tardi", non come un modo gentile di dire non valido.
02Perché lo stesso indirizzo ha dato risultati diversi in due esecuzioni?
Perché tra un'esecuzione e l'altra è cambiato il comportamento del server, non la casella. Un server con greylisting rifiuta il primo tentativo e accetta quello successivo; un server con limitazione di frequenza ti rinvia nei momenti di punta e risponde in quelli tranquilli. Un indirizzo che ieri era unknown e oggi è deliverable è il sistema che funziona come previsto.
03Un verificatore può aggirare il greylisting?
L'unico "aggiramento" legittimo è la pazienza: riprovare dopo la finestra del greylisting, cosa che i verificatori fanno entro il tempo a loro disposizione. Nulla garantisce una risposta entro la durata di un job in blocco, ed è proprio per questo che l'insieme degli esiti onesti include unknown. Uno strumento che dichiara di non restituire mai un esito sconosciuto ti sta dicendo che tira a indovinare.
04Quanto devo aspettare prima di verificare di nuovo gli indirizzi con esito sconosciuto?
Più della finestra di greylisting, meno del tempo che manca alla prossima campagna. Il ritardo classico del greylisting è di minuti, quindi qualsiasi momento tra qualche ora e qualche giorno dopo lascia ai server che rinviano tutto il margine per aver già visto il tuo test, mentre gli esiti sconosciuti dovuti a limitazioni di frequenza traggono vantaggio dal capitare semplicemente in un momento più tranquillo. Rieseguire solo il segmento con esito sconosciuto prima di un invio importante è un'assicurazione economica; gli esiti sconosciuti che resistono a diverse riesecuzioni distanziate meritano lo stesso scetticismo di un indirizzo catch-all freddo.
05Il greylisting è ancora diffuso nel 2026?
Sì, anche se in modo disomogeneo. Resta uno strumento standard su gateway aziendali, appliance di sicurezza e server self-hosted, dove è economico ed efficace. I grandi provider consumer sono in gran parte passati a limitazioni di frequenza basate sulla reputazione, che dal punto di vista di un verificatore producono gli stessi rinvii temporanei e la stessa risposta onesta: esito sconosciuto, riprova più tardi.
