Validazione SMTP spiegata: come funzionano davvero gli Email Validator

La maggior parte dei controllori di email dichiara di essere accurata. Pochi spiegano come verificano davvero un indirizzo.

Ecco questa spiegazione.

Cos'è SMTP?

SMTP = Simple Mail Transfer Protocol
È il linguaggio che i server di posta utilizzano per inviare e ricevere email.

Quando invii un'email:
1. Il tuo client si connette a un server SMTP
2. Invia MAIL FROM: you@yourcompany.com
3. Invia RCPT TO: recipient@their.com
4. Il server risponde 250 OK (yes, we accept it) or 550 Reject (no, we don't)
5. Il client invia il corpo del messaggio

Validazione SMTP: il controllo reale

Convalida SMTP simula i passaggi 1–4 senza inviare l'email vera e propria.

Per questo è l'unico modo per sapere se una casella di posta esiste davvero.

L'handshake SMTP

→ Client: EHLO posta.validatore.com
← Server: 250 OK ESMTP

→ Client: MAIL FROM:<validatore@mail.validatore.com>
← Server: 250 OK

→ Client: RCPT TO:<test@gmail.com>
← Server: 250 OK
     (era esiste e accetta posta)

→ Client: QUIT
← Server: 221 Bye

Se il RCPT TO returns 250, l'indirizzo è Valido.
Se restituisce 550, l'indirizzo è Non valide.
Se il server non risponde, è Rischiosi o Sconosciuto.

Perché Gli Altri Metodi Non Funzionano

❌ Solo Controllo della Sintassi

test@example.com ✅ (sembra good)
test.12345@example.com ❌ (potrebbe non esiste)

La sintassi è corretta ma non sappiamo se la casella di posta esiste.

❌ Solo Controllo dei Record MX

Dominio: gmail.com → MX: aspmx.l.google.com (sì, esiste)
Ma: fa test@gmail.com effettivamente esiste? Sconosciuto.

✅ Validazione SMTP

Connetti a gmail SMTP → RCPT TO test@gmail.com
← 550 No tali user
Risultato: NON VALIDA (era non't esiste)

La Sfida: Domini Catch-All

Alcuni server (soprattutto quelli più datati) rispondono "sì" a a ogni indirizzo:

→ RCPT TO: realuser@company.com
← 250 OK

→ RCPT TO: fakeuser123456789@company.com
← 250 OK (anche accettato!)

Questi sono domini catch-all. Il controllo SMTP da solo non può dire se sono reali.

Avanzato: punteggio + rilevamento catch-all

I validatori migliori combinano SMTP e altri segnali:

• Reputazione del dominio — il server di posta è noto per i rimbalzi?
• Attività recente — il dominio è stato attivo negli ultimi 90 giorni?
• Controlli honeypot — è una trappola antispam nota?
• Flag rischioso + catch-all — "Valido via SMTP ma potrebbe essere catch-all"

Punteggio 0–10 = livello di affidabilità, non solo superato/non superato.

Velocità vs precisione

Perché la validazione SMTP è importante

✅ Protegge la reputazione del mittente — verifica prima di inviare
✅ Riduce i tassi di rimbalzo — SMTP individua gli indirizzi non validi prima dell'invio
✅ Fai risparmiare crediti — non pagare il tuo ESP per le email respinte
✅ Migliora la deliverability — i provider premiano l'invio pulito

Come verificare da soli (solo per sviluppatori)

import smtplib

dominio = "gmail.com"
try:
    smtp = smtplib.SMTP(f"mx.{dominio}")
    smtp.posta("test@validator.com")
    code, msg = smtp.rcpt("recipient@gmail.com")
    if code == 250:
        print("Valid")
    else:
        print("Invalid")
    smtp.quit()
except:
    print("Risky/Unknown")

Ma in produzione, usa un servizio. La validazione SMTP su larga scala è complessa (firewall, limiti di frequenza, ritardi).

SMTP in dettaglio

SMTP è un protocollo di testo. Una sessione è una breve conversazione composta da una sequenza di comandi e risposte numeriche. Ai fini della verifica conta solo la prima metà, cioè la parte che precede l'invio del corpo del messaggio.

Porte e TLS

• 25 — la classica porta da server a server. Spesso bloccata dai provider di hosting per contrastare lo spam, motivo per cui i servizi di verifica utilizzano infrastrutture dedicate.
• 465 — TLS implicito (SMTPS).
• 587 — porta di invio con STARTTLS, utilizzata dai client di posta.

Un validatore ha bisogno di raggiungere la porta 25 dell'MX del destinatario. Se il tuo server non riesce a raggiungere la porta 25, non puoi eseguire controlli SMTP affidabili in autonomia: è il motivo più comune per cui i team esternalizzano la verifica.

EHLO, MAIL FROM, RCPT TO

→ EHLO validatore.example.com
← 250-posta.example.com
← 250-PIPELINING
← 250 SIZE 35882577

→ MAIL FROM:<verifica@validator.example.com>
← 250 OK

→ RCPT TO:<person@example.com>
← 250 OK

EHLO opens the session and asks which extensions the server supports. MAIL FROM declares the envelope sender. RCPT TO is the actual test: the server accepts or rejects the recipient. QUIT ends the session.

Il punto chiave: RCPT TO riceve risposta prima che venga inviato qualsiasi dato del messaggio. È questo che rende possibile la verifica senza recapitare la posta.

Lettura dei codici di risposta SMTP

Un validatore che considera "non valido" ogni risposta diversa da 250 è sbagliato: i codici 4xx sono temporanei e spesso si risolvono al nuovo tentativo.

Perché i controlli di sintassi e MX non bastano

Entrambi sono economici e utili come primo filtro, ma nessuno dei due può rispondere alla sola domanda che conta: questa casella accetta posta?

• Sintassi indica che la stringa ha l'aspetto di un indirizzo. Non può vedere che l'azienda ha chiuso.
• MX indica che il dominio dispone di un server di posta. Non può vedere che person@ was never created.
• SMTP dialoga con quel server e chiede informazioni su quello specifico destinatario. Solo questo passaggio restituisce una risposta reale.

La conseguenza pratica: una lista che supera i controlli di sintassi e MX può comunque generare rimbalzi per il 20–30%. Per questo gli strumenti "controllo email gratuito" che si limitano a regex sono molto diffusi ma inutili per il lavoro sulla recapitabilità.

Domini catch-all in dettaglio

Un server catch-all è configurato per accettare posta per qualsiasi parte locale. Si tratta di una configurazione legittima — le aziende la usano perché un errore di battitura nell'indirizzo di un prospect non vada perso in silenzio — ma compromette la validazione SMTP.

Come gestire i catch-all:

1. Individuarli. Invia una sonda a una parte locale casuale e palesemente falsa. Se anch'essa restituisce 250, il dominio è catch-all.
2. Segnalare, non eliminare. I catch-all spesso appartengono a persone reali. Eliminarli può costare il 5–15% di una lista B2B.
3. Invia in piccoli lotti e misura aperture e rimbalzi. Se un segmento catch-all funziona, mantienilo.
4. Usa segnali aggiuntivi — reputazione del dominio, storico di interazione e analisi dei pattern — per ordinare gli indirizzi catch-all.

Greylisting, limiti di frequenza e protezione dal harvesting

I server di posta reali non sono banchi di prova. Aspettati:

• Greylisting — il server rifiuta temporaneamente i mittenti alla prima comparsa con un codice 4xx e si aspetta un nuovo tentativo. I servizi di validazione ritentano automaticamente.
• Rate limiting — troppe connessioni da un unico IP vengono rallentate. I provider validi distribuiscono i controlli su più IP e nel tempo.
• Anti-harvesting — alcuni server rispondono deliberatamente in modo ambiguo a chi sonda molti indirizzi.
• Honeypot — indirizzi che esistono solo per intercettare i mittenti massivi. Un buon validatore li segnala.

Per questo gli script fai-da-te per la validazione funzionano con dieci indirizzi e crollano con diecimila.

Tempo reale vs batch e il pattern asincrono

• Tempo reale è la scelta giusta per moduli di registrazione e checkout: un indirizzo, una risposta immediata, con un timeout rigoroso affinché l'utente non attenda mai più di uno o due secondi.
• Batch è la scelta giusta per le liste: migliaia di indirizzi, nuovi tentativi e un file dei risultati che puoi segmentare.
• Asincrono è il pattern di produzione per entrambi: accoda l'indirizzo, restituisci subito una risposta, esegui la verifica in background e aggiorna il record quando arriva il risultato.

Non bloccare mai il thread della richiesta in attesa di un handshake SMTP remoto. Un server lento o ostile può tenere aperta la connessione per 30 secondi o più.

Un esempio Python migliore

import smtplib
import dns.resolver

def verifica(dominio: str, fisico: str, timeout: int = 10) -> str:
    try:
        mx = str(dns.resolver.resolve(dominio, "MX")[0].exchange).rstrip(".")
        with smtplib.SMTP(mx, 25, timeout=timeout) as smtp:
            smtp.ehlo_or_helo_if_needed()
            smtp.posta("check@validator.example.com")
            code, _ = smtp.rcpt(fisico)
            if code in (250, 251):
                return "valid"
            if code in (450, 451, 452, 552):
                return "risky"
            if code in (550, 551, 553):
                return "invalid"
            return "unknown"
    except Eccezione:
        return "unknown"

Anche questa versione semplificata presenta problemi su larga scala: ignora il greylisting, non rileva i catch-all, usa un solo IP e verrà bloccata dai provider che limitano la frequenza delle richieste. È uno strumento didattico, non un validatore per la produzione.

Limiti ed etica

Nessun validatore può garantire la consegna. Le caselle di posta possono chiudersi tra la verifica e l'invio; i server possono cambiare politica; un indirizzo "valido" può comunque essere abbandonato. Usa la verifica per eliminare i fallimenti prevedibili, non per promettere una campagna con zero rimbalzi.

Dal punto di vista etico, valida solo gli indirizzi che hai una base giuridica legittima per contattare. Il probing SMTP è un'operazione tecnica, ma non crea il consenso, e usare la validazione per ripulire un elenco acquistato non rende legittimo l'invio.

Ciò che la validazione non può vedere

• Coinvolgimento — un indirizzo valido potrebbe non aprire mai la tua email.
• Intento — una persona reale potrebbe non voler ricevere la tua offerta.
• Consenso — un indirizzo recapitabile non costituisce una base giuridica.
• Stato futuro — una casella di posta potrebbe essere chiusa il giorno dopo la verifica.

La verifica elimina l'incertezza tecnica. Tutto il resto è ancora marketing.

Prima testa il tuo dominio

Prima di validare un elenco, valida il tuo dominio di invio:

• Invia un test a una casella che controlli su Gmail, Outlook e a un dominio aziendale.
• Verifica l'allineamento di SPF, DKIM e DMARC.
• Monitora attentamente i primi 200 invii di ogni nuovo dominio; il riscaldamento conta più di qualsiasi singola verifica.

Un elenco pulito inviato da un dominio con l'autenticazione non funzionante finisce comunque nello spam.

Domande frequenti

La validazione SMTP invia un'email?
No. Si ferma a RCPT TO, before any message body is transmitted.

Perché alcuni indirizzi validi risultano come rischiosi?
Greylisting, errori temporanei del server o politiche anti-harvesting. Riprova dopo 24–48 ore.

Posso validare dal mio server?
Solo se riesce a raggiungere la porta 25 e non è soggetto a limiti di frequenza o inserito in blacklist. La maggior parte degli hosting condivisi la blocca.

La rilevazione catch-all è affidabile?
Indica in modo affidabile che il dominio è catch-all. Non può dirti se una specifica casella di posta esiste.

Quale accuratezza dovrei aspettarmi?
Un buon validatore basato su SMTP è corretto circa il 95–99% delle volte; la restante incertezza è dovuta soprattutto ai catch-all e agli errori temporanei.

SPF, DKIM e DMARC in un paragrafo ciascuno

• SPF elenca i server autorizzati a inviare posta per il tuo dominio. È un record TXT del DNS e si interrompe quando superi il limite di 10 ricerche.
• DKIM aggiunge una firma crittografica a ogni messaggio, così il destinatario può verificare che non sia stato alterato. Ruota le chiavi periodicamente.
• DMARC indica ai destinatari cosa fare quando SPF o DKIM falliscono (none, quarantine, reject) e ti invia dei report. Inizia con p=none, read the reports, then tighten.

La validazione SMTP verifica il destinatario; SPF, DKIM e DMARC determinano se la tua posta in uscita è considerata attendibile. Una lista verificata inviata da un dominio con un'autenticazione non funzionante continua a fallire. Configura il reporting DMARC prima di aumentare il volume di una campagna: i report sono il modo per individuare i mittenti che avevi dimenticato.

Inizia a validare

Inizia gratis →

100 validazioni SMTP al mese, senza carta di credito.