Verificare un indirizzo non invia alcun messaggio: la sessione SMTP si ferma prima del comando DATA, quello che trasmette il contenuto (RFC 5321, sezione 4.1.1.4). Questo meccanismo, poco noto, spiega la maggior parte dei falsi miti sulla verifica delle email, a cui si attribuiscono poteri eccessivi o intrusioni che non commette.

L’effetto meglio documentato riguarda l’hard bounce: la verifica scarta gli indirizzi inesistenti prima dell’invio. Non incide né sui reclami per spam né sul coinvolgimento. I 9 falsi miti qui sotto si risolvono ciascuno con una soglia pubblicata o con il funzionamento del protocollo SMTP.

Verifica e validazione: i confini in poche righe

La validazione controlla la forma di un indirizzo: una «@», un dominio, una sintassi conforme alla RFC 5322. La verifica interroga poi il dominio, tramite il suo record MX, quindi il server di posta stesso, e segnala gli indirizzi usa e getta. I passaggi sono descritti nell’articolo sulla differenza tra validazione e verifica.

9 falsi miti sulla verifica delle email, messi alla prova

Falsi miti sulla verifica delle email: controllo di una lista di indirizzi prima di un invio

Un indirizzo verificato è un indirizzo senza rischi?

No. Un verificatore ordina gli indirizzi in categorie (valido, non valido, catch-all, a rischio) perché un «valido» non copre tutti i casi. Gli indirizzi usa e getta ne sono un esempio: la casella esiste e risponde il giorno del test, poi viene abbandonata. I servizi li individuano grazie a elenchi di domini temporanei, messi a confronto nell’articolo sugli indirizzi email usa e getta. La spam trap è il caso più insidioso: gestita da un provider di posta o da un ente antispam, accetta la posta. Il test SMTP la vede quindi come una casella qualunque. La documentazione di Amazon SES precisa che queste trappole possono essere vecchi indirizzi validi, abbandonati dopo un lungo periodo di rimbalzi.

Si può verificare una casella senza inviarle un’email?

Sì. Una transazione SMTP comprende 3 comandi: MAIL FROM annuncia il mittente, RCPT TO indica il destinatario, DATA trasmette il contenuto del messaggio (RFC 5321, sezione 3.3). Il server risponde a RCPT TO prima che DATA esista; il verificatore si ferma lì e chiude la connessione. Il codice 250 significa «accettato», il 550 «casella sconosciuta», un codice 4xx un rifiuto temporaneo da ritentare.

Il record MX indica dove porre la domanda. La sezione 5.1 della RFC 5321 prevede che un dominio senza MX sia trattato come se avesse un MX implicito che punta al proprio host. L’assenza di MX resta quindi un segnale da incrociare con il resto. Questo meccanismo ha un punto debole noto, approfondito più avanti: alcuni domini rispondono 250 a tutto.

La verifica è invasiva?

Il contenuto resta fuori portata: nessun messaggio viene trasmesso né letto, perché la sessione si interrompe prima di DATA. Resta la questione del GDPR: un indirizzo nominativo rimane un dato personale. Le regole sulla prospezione le fissa la CNIL, l’autorità francese per la protezione dei dati. Richiede un consenso preventivo in B2C e un diritto di opposizione in B2B. Raccomanda di raccoglierli con una casella non preselezionata (la casella preselezionata è vietata). Ogni sollecitazione deve identificare l’organizzazione mittente e offrire un rifiuto semplice (pagina della CNIL sulla prospezione via posta elettronica, in francese, aggiornata il 10 giugno 2026).

Il catch-all prova che l’indirizzo esiste?

No. Un dominio catch-all accetta la posta indirizzata a qualsiasi nome prima della chiocciola: mario.rossi@ e azertyuiop@ ottengono lo stesso 250 al comando RCPT TO.

Nessun metodo dà una risposta certa: la sorte del messaggio, archiviato in una casella reale o scartato, dipende dalla configurazione del dominio. I servizi seri classificano questi indirizzi come risky («accept-all» presso alcuni), il che esprime un’incertezza reale. Un lotto di prova inviato a questo segmento, con rilevazione dell’hard bounce prima di estendere l’invio, vale più di una selezione alla cieca.

Uno strumento gratuito o la semplice sintassi bastano?

No. «gmial.com» rispetta tutte le regole di sintassi. Il controllo successivo, il record MX, elimina i domini inesistenti ma non ferma un dominio reale in cui la casella non esiste. Solo la conversazione SMTP interroga l’indirizzo stesso. Uno strumento gratuito si giudica quindi dalla profondità del controllo: sintassi e dominio da una parte, SMTP con rilevamento del catch-all dall’altra. La sola validazione non dice nulla sullo stato della casella di posta.

Gli indirizzi verificati sono sempre attivi?

No. «Valido» significa accettato dal server al momento del test. Una casella può restare mesi senza un lettore. Può anche saturarsi e restituire soft bounce. Amazon SES raccomanda infatti di smettere di scrivere ai destinatari che non aprono né cliccano: un contatto inattivo non rimbalza, pesa sul coinvolgimento.

Una verifica all’anno basta?

Nessun numero universale fissa il ritmo. Dipende dalla velocità di ricambio della base e dal costo di un rimbalzo (soglie più in basso). Per i contatti a cui non si scrive da tempo, SES consiglia di includerne solo una piccola parte in ogni invio. La pagina sulla frequenza di verifica di una lista email ne descrive il ritmo. Un double opt-in e una verifica al momento dell’iscrizione bloccano alla fonte gli errori di battitura; la pulizia della lista esistente completa queste due protezioni.

La verifica garantisce la deliverability?

No, agisce su una sola riga del bilancio. Per i reclami per spam, Gmail fissa la regola dal 1° febbraio 2024 per tutti i mittenti:

«Mantenete i tassi di spam indicati in Postmaster Tools sotto lo 0,10% ed evitate di raggiungere un tasso di spam dello 0,30% o superiore.»

Questa indicazione figura nelle linee guida di Google per i mittenti, che richiedono SPF o DKIM a tutti i mittenti e aggiungono DMARC oltre i 5.000 messaggi al giorno verso Gmail. Un destinatario perfettamente valido che clicca su «segnala come spam» pesa sulla reputazione del mittente senza che alcuna verifica possa evitarlo; la definizione di spam e gli errori di deliverability coprono questa metà del dossier.

Sul fronte dei rimbalzi, la stessa pagina di Amazon SES offre una scala chiara: sotto il 2% di rimbalzi definitivi per buoni risultati, revisione dell’account dal 5%, sospensione possibile dal 10%. I rimbalzi temporanei, come una casella piena, non rientrano in questo calcolo.

Tutti i servizi di verifica si equivalgono?

No. I servizi divergono sulla sorte degli indirizzi catch-all, sull’aggiornamento dei loro elenchi di domini temporanei e sulla finezza degli stati. Un servizio che restituisce solo «valido» o «non valido» nasconde la categoria più incerta, quella dei catch-all. Il test più eloquente richiede pochi minuti: sottoporre qualche centinaio di indirizzi di cui si conosce già l’esito, poi confrontare gli stati restituiti. Il campione mescola caselle interne attive, indirizzi inventati su domini reali e un dominio catch-all identificato.

Ciò che una lista verificata lascia fuori

Il test non misura né il contenuto del messaggio né il consenso dei destinatari. Non dice nulla nemmeno sulla voglia di leggere. Un campione estratto dal segmento più vecchio e passato in Captain Verify prima della prossima campagna fornisce la quota di indirizzi non validi di quella base, da confrontare con la soglia del 2% di rimbalzi di Amazon SES.

Aggiungi Captain Verify come fonte preferita su Google
Nicolas Forni
Author

Fondatore di Captain Verify, lavoro sulla verifica di email e numeri di cellulare dal 2015. In questo blog scrivo di deliverability, igiene dei database di contatti, regole dei provider di posta e SMS marketing. Articoli concreti, pensati per i team marketing che inviano ogni settimana.