Come funziona la verifica email: le 8 fasi

In breve#

La verifica email fa passare un indirizzo attraverso una pipeline di controlli sempre più costosi, e si ferma non appena uno di questi è decisivo. I controlli economici e istantanei avvengono in locale (l'indirizzo ha almeno la forma di un'email? il dominio accetta posta?) e solo gli indirizzi che li superano arrivano al passaggio lento, legato alla rete, in cui si chiede davvero al server di posta se la casella esiste. Qualisend esegue otto fasi distinte, e questo articolo le analizza una per una: cosa può dimostrare ciascuna, cosa non può dimostrare e quale esito produce.

L'ordine conta perché ogni fase è un filtro. Non ha senso aprire una connessione SMTP per controllare una casella su un dominio che non ha un server di posta, né cercare i record DNS di quel dominio se all'indirizzo manca la @. Prima le eliminazioni economiche; la domanda costosa per ultima.

Fase 1: sintassi#

Il primo controllo verifica se la stringa è un indirizzo email strutturalmente valido: una sola @, una parte locale sensata, un dominio che sembri un dominio. Questo intercetta gli errori di battitura più banali (virgole finali, spazi, un TLD mancante, due @) ed è istantaneo e gratuito, perché non esce mai dal processo.

La verifica della sintassi è necessaria ma, da sola, debole. definitely-not-real@some-made-up-domain.com ha una sintassi perfettamente valida ed è del tutto non recapitabile. Chi "verifica" con una regex e si ferma qui sta controllando l'ortografia, non la deliverability. Un indirizzo che non supera questa fase restituisce undeliverable con motivo invalid_email.

Fase 2: dominio e record MX#

Poi il sistema di verifica chiede al DNS se il dominio può ricevere posta: si risolve? pubblica record MX (o un record A utilizzabile come ripiego) che puntano a un server di posta? Un dominio senza un percorso per la posta non può accettare posta per nessuno, quindi questa fase elimina interi domini morti con una sola ricerca: nomi di aziende scritti male, domini scaduti e TLD inventati.

Un dominio che non supera questa fase restituisce undeliverable con motivo invalid_domain. Un dominio che la supera ha un percorso per la posta, ma non ha ancora dimostrato che la casella specifica esiste. Per quello mancano ancora quattro fasi.

Fase 3: domini usa e getta#

Alcuni domini esistono solo per distribuire caselle usa e getta: gli indirizzi da dieci minuti che le persone usano per ottenere un codice sconto e non controllano mai più. Qualisend confronta il dominio con una lista aggiornata di provider usa e getta. Una corrispondenza non significa che l'indirizzo oggi non accetti posta; significa che domani non varrà nulla, quindi viene segnalato e penalizzato nel punteggio invece di essere considerato affidabile.

Un indirizzo usa e getta viene riportato come risky con motivo low_quality e un indicatore aggiuntivo "usa e getta". La questione collegata, cioè se inviare o meno a quell'indirizzo, è una decisione a parte, trattata in indirizzi generici, usa e getta e gratuiti.

Fase 4: indirizzi generici#

Un indirizzo generico è una casella condivisa (info@, support@, billing@) letta da un team o da un sistema di ticketing invece che da una persona. Di solito sono indirizzi reali e recapitabili, ma nel marketing si comportano male: nessuna persona ne è titolare, falsano le metriche di engagement e attirano segnalazioni di spam. Per questo il sistema di verifica li individua (senza distinguere maiuscole e minuscole e ignorando un eventuale suffisso +tag) e li segnala invece di trattarli come una casella personale.

Un indirizzo generico resta deliverable ma porta l'indicatore aggiuntivo "indirizzo generico", così puoi decidere se includerlo in un determinato invio. Anche qui, la scelta tra inviare e sopprimere ha la sua guida.

Fase 5: rilevamento degli errori di battitura#

Prima di spendere tempo in uno scambio di rete, il sistema di verifica controlla se il dominio è una variante sbagliata di un provider comune (gmial.com per gmail.com, hotmial.com per hotmail.com) usando la distanza di Damerau-Levenshtein (l'algoritmo che conta inserimenti, cancellazioni, sostituzioni e trasposizioni). Quando trova un probabile errore di battitura propone un suggerimento "Forse intendevi", molto più utile di un semplice rifiuto: in fase di iscrizione ti permette di offrire la correzione in tempo reale e di recuperare l'iscritto invece di perderlo.

Il rilevamento degli errori di battitura è un suggerimento, non un esito a sé, ma è una delle fasi con il maggiore effetto leva, perché intercettare l'errore al punto di acquisizione evita in un colpo solo un hard bounce e un contatto perso.

Fase 6: il test SMTP della casella#

Tutto ciò che abbiamo visto finora è locale e istantaneo. Questa è la fase che ha un costo reale: il sistema di verifica apre una connessione con il server di posta del dominio e avvia la conversazione di consegna (HELO, MAIL FROM, RCPT TO:<address>), poi legge la risposta del server senza mai inviare un messaggio. La risposta a RCPT TO è la cosa più vicina a una risposta reale sull'esistenza della casella:

• 250/251 → il server accetta il destinatario → deliverable, accepted_email
• classe 550 → rifiuto permanente, utente inesistente → undeliverable, rejected_email
• 4xx → un rinvio temporaneo, di solito dovuto al greylisting → nuovo tentativo, poi unknown se persiste
• qualsiasi altra cosa, o un timeout → unknown

Questa fase legge anche il testo e i codici della risposta per individuare due condizioni particolari: un 452/552 o un messaggio "over quota" significa che la casella esiste ma è piena (risky), mentre un messaggio "disabled/suspended" significa che l'account è morto (undeliverable). Per la grammatica completa di queste risposte c'è un riferimento dedicato: i codici di risposta SMTP spiegati.

Fase 7: rilevamento dei catch-all#

Un 250 SMTP ha senso solo se il server avrebbe detto no a un indirizzo inesistente. Per questo, oltre al tuo indirizzo, il sistema di verifica testa una casella volutamente senza senso sullo stesso dominio. Se il server accetta anche quella, il dominio è catch-all (accetta qualsiasi indirizzo) e il 250 per il tuo indirizzo non dimostra nulla. Quell'indirizzo viene riportato come risky con motivo low_deliverability e un indicatore catch-all, e non viene mai arrotondato a recapitabile.

È la fase più travisata dell'intero settore, ed è per questo che ha un approfondimento dedicato. Detto onestamente: una casella dietro un dominio catch-all non è confermabile, e nessun punteggio può cambiare questo fatto.

Fase 8: punteggio ed esito#

L'ultima fase riunisce tutti i segnali (l'esito SMTP, gli indicatori aggiuntivi, la reputazione del dominio, se la casella è su un provider di posta gratuito) in un unico stato (deliverable | risky | undeliverable | unknown), un codice motivo e un punteggio di affidabilità da 0 a 100. Lo stato ti dice cosa fare; il motivo e gli indicatori aggiuntivi ti dicono perché; il punteggio ordina gli indirizzi all'interno di uno stato. Soprattutto, ogni esito arriva con le sue prove (il provider MX, il dettaglio del test), così il numero è verificabile invece di essere una scatola nera.

Cosa le otto fasi non possono comunque dirti#

Una pipeline così accurata potrebbe far pensare di ottenere un sì o un no netto per ogni indirizzo. Non è così, e vale la pena dichiarare apertamente i limiti:

• Un dominio catch-all limita la certezza a "a rischio". Quando la fase 7 trova un server che accetta tutto, il 250 della fase 6 non dice nulla: la casella non è confermabile, a prescindere da quante fasi siano state eseguite. Nessun sistema di verifica risolve questo problema senza inviare un messaggio, e chi sostiene il contrario sta tirando a indovinare.
• Un server che applica greylisting o limiti di frequenza può imporre un unknown. Se nel tempo disponibile la fase 6 riceve solo rinvii 4xx, l'esito onesto è unknown (riprova più tardi), non un valido o non valido inventato.
• La verifica è un'istantanea. Un indirizzo confermato come recapitabile oggi può deteriorarsi domani, quando qualcuno cambia lavoro o abbandona una casella. Ecco perché conta ripulire la lista prima degli invii importanti, e perché un tasso di bounce in lenta crescita è un segnale per verificare di nuovo.
• L'engagement è l'unica cosa che la verifica non può misurare. Un indirizzo recapitabile che non apre mai nulla è un rischio per la deliverability che la pipeline non può vedere. La verifica ti dice che un indirizzo può ricevere posta, non che il suo titolare voglia la tua posta.

Nessuno di questi è un difetto della pipeline: sono i confini di ciò che qualsiasi verifica può sapere. Lo strumento di cui diffidare è quello che finge che questi confini non esistano.

Perché la verifica gratuita si ferma alla fase 5#

La nostra verifica email gratuita esegue le fasi da 1 a 5 (quelle locali) e si ferma volutamente prima del test SMTP. Non è una versione azzoppata del prodotto: è un limite onesto. Le fasi da 1 a 5 possono escludere un indirizzo (sintassi errata, nessun percorso per la posta, usa e getta, errore di battitura evidente), ma non possono confermare una casella né rilevare un catch-all, perché per farlo serve aprire una vera conversazione SMTP da un IP con una buona reputazione. Qualsiasi strumento gratuito nel browser che dichiari di confermare caselle attive o non esegue la fase 6 o non è onesto al riguardo. Il confronto tra verifica completa e gratuita ha un'analisi dedicata.

Domande frequenti#

Verificare un'email invia un messaggio all'indirizzo?#

No. Il test SMTP della fase 6 esegue la conversazione di consegna fino al punto in cui il server accetta o rifiuta il destinatario, poi si disconnette senza inviare il comando DATA che trasmetterebbe un messaggio. Il titolare della casella non vede nulla. Inviare una vera email di "prova" per controllare la validità è esattamente la cattiva pratica che una verifica fatta bene evita.

Perché la verifica non può essere istantanea?#

Le fasi da 1 a 5 sono istantanee perché sono locali. La fase 6 richiede una conversazione in rete con un server di posta di terze parti che non controlli, che può applicarti il greylisting, limitare la frequenza delle tue richieste o rispondere lentamente di proposito. Quello scambio in rete è il prezzo di una risposta reale, ed è per questo che le elaborazioni in blocco vengono eseguite in modo asincrono invece di restare in attesa su ogni indirizzo.

Qual è la differenza tra lo stato e il punteggio?#

Lo stato (deliverable | risky | undeliverable | unknown) è la decisione; il punteggio (da 0 a 100) ordina gli indirizzi all'interno di uno stato, così puoi stabilire le priorità. Un indirizzo recapitabile su un provider di posta gratuito ha un punteggio diverso da uno su un dominio aziendale, ma sono entrambi recapitabili. Usa lo stato per decidere e il punteggio per ordinare.

Quali fasi espone l'API?#

Tutte. Un risultato di verifica restituisce lo stato e il motivo finali, più gli indicatori aggiuntivi (catch-all, usa e getta, indirizzo generico, gratuito, casella piena) e il suggerimento "Forse intendevi", così il tuo codice può agire sulle prove e non solo sull'esito. Consulta la documentazione per sviluppatori e, se stai scegliendo tra più provider, il confronto tra API di verifica email.