Perché validare le email con una regex non funziona

Ogni codebase ne ha una: un'espressione regolare, copiata da Stack Overflow, che "valida" gli indirizzi email. Sembra un controllo, ma risponde a una domanda che quasi nessuno si sta davvero ponendo. Una regex può dirti che una stringa ha la forma di un indirizzo email. Non può dirti se l'indirizzo esiste, se accetta posta o se non genererà un hard bounce nella tua prossima campagna, e sono le uniche cose che contano.

In breve#

Una regex valida la sintassi, non la deliverability. definitely-fake@gmail.com è un indirizzo email perfettamente valido per qualsiasi regex mai scritta, e rimbalzerà nell'istante in cui gli invii qualcosa. Peggio ancora, le regex a cui si ricorre di solito o rifiutano indirizzi reali (troppo restrittive) o accettano assurdità (troppo permissive), e quella tecnicamente corretta è lunga migliaia di caratteri e comunque non può confermare l'esistenza di una casella. Usa un semplice controllo di sintassi per intercettare gli errori di battitura già in fase di inserimento, poi verifica la deliverability con un controllo DNS e SMTP, che è un problema di rete, non di pattern matching.

La regex che hai già visto, e cosa lascia passare#

Ecco l'archetipo (una sua variante si trova nella maggior parte dei progetti):

const re = /^[^@\s]+@[^@\s]+\.[^@\s]+$/;
re.test("definitely-fake@gmail.com"); // true  ← will hard-bounce
re.test("typo@gmial.com");            // true  ← typo'd domain, bounces
re.test("info@company-that-folded.com"); // true  ← dead domain

Passano tutti e tre. Tutti e tre sono non recapitabili. La regex ha fatto il suo lavoro alla perfezione e non ti ha detto nulla di utile, perché sintassi e deliverability sono domande diverse. Ogni indirizzo che una regex può vedere è una stringa; che una persona legga davvero la posta a quell'indirizzo è un fatto che riguarda internet, non la stringa.

Il labirinto della RFC 5322#

"Va bene", si pensa, "userò una regex corretta". La grammatica formale di un indirizzo email è definita dalla RFC 5322, e una regex che la implementa davvero è notoriamente mostruosa: migliaia di caratteri, e permette cose che non vorresti mai accettare, come parti locali tra virgolette con spazi ("a b"@example.com) e commenti all'interno dell'indirizzo.

Ne derivano due problemi. Primo, la regex rigorosa accetta più di quanto vorresti, non meno: valida rispetto a una specifica del 2008, non rispetto agli "indirizzi a cui i server di posta reali consegnano davvero". Secondo, anche una corrispondenza perfetta con la RFC 5322 non può dirti se il dominio ha un server di posta o se la casella esiste. Hai fatto uno sforzo enorme per rispondere con più precisione alla domanda facile, mentre quella difficile (la posta arriverà?) resta del tutto senza risposta.

Le tre cose che una regex non può fare, per sua natura#

Nessun pattern, per quanto ingegnoso, può interrogare la rete. Una regex non può:

• Controllare se il dominio può ricevere posta. user@company-that-folded.com ha una sintassi valida su un dominio senza record MX. Solo una ricerca DNS rivela il dominio morto.
• Confermare che la casella esiste. noreply-9f2x@gmail.com ha una sintassi valida per un account mai creato. Solo una conversazione SMTP con Gmail può dirti che non esiste.
• Rilevare un dominio catch-all. Un server catch-all accetta qualsiasi indirizzo, quindi nemmeno un vero controllo SMTP può confermare una casella specifica, e una regex non ha idea che il dominio si comporti così.

Non sono lacune di una regex in particolare: sono al di fuori di ciò che qualsiasi regex può fare, perché sono domande sui server, non sulle stringhe.

Cosa fare davvero: verificare a livelli#

La deliverability è una pipeline di controlli sempre più costosi, e la sintassi è solo la prima fase, quella economica (il quadro completo è in come funziona la verifica email):

1. Sintassi: un semplice controllo in fase di inserimento per intercettare gli errori di battitura evidenti. È l'unico livello in cui ha senso una regex.
2. Dominio e MX: una ricerca DNS per confermare che il dominio possa ricevere posta. Vedi le guide per Node.js e Python per codice funzionante.
3. Test SMTP della casella: la conversazione di consegna che conferma davvero la casella, più il rilevamento dei catch-all. Servono un server di posta con un IP dalla reputazione pulita e un'attenta gestione dei limiti di frequenza, ed è per questo che la maggior parte dei team si affida a un'API di verifica invece di costruirlo da sé.

Il controllo di sintassi che vale la pena tenere#

Per il livello 1, non implementare a mano la RFC 5322. La soluzione pragmatica è l'input email HTML5 nel browser (che applica gratis il pattern del living standard WHATWG) e un controllo breve e permissivo sul server:

// Pragmatic: rejects fat-finger errors, accepts the addresses real
// mail servers actually deliver to. Not a deliverability check.
const SYNTAX = /^[^\s@"]+(?:\.[^\s@"]+)*@[^\s@.]+(?:\.[^\s@.]+)+$/;

SYNTAX.test("jane@example.com"); // true
SYNTAX.test("not-an-email");     // false
SYNTAX.test("a@@b.com");         // false

Usalo per dare un feedback immediato mentre l'utente digita, niente di più. Considera un risultato positivo come "da controllare per bene", mai come "valido".

Fare il resto della strada#

Una volta superato il controllo di sintassi, la vera verifica è un lavoro di rete. Puoi costruire da te i livelli DNS e SMTP (le guide per i vari linguaggi citate sopra mostrano fin dove puoi arrivare), ma confermare caselle attive su larga scala si scontra con la porta 25 bloccata dalla maggior parte dei provider di hosting, con la reputazione degli IP e con il greylisting, ed è lì che un'API gestita si guadagna il suo posto. POST /verify di Qualisend esegue l'intera pipeline e restituisce un esito a quattro valori (deliverable | risky | undeliverable | unknown) con un codice motivo, così il tuo codice agisce in base all'esistenza della casella invece che alla presenza di una @ nella stringa.

Domande frequenti#

Esiste una regex corretta per la validazione delle email?#

Non nel senso che si vorrebbe. Esiste una regex che implementa la RFC 5322, ma è lunga migliaia di caratteri, accetta forme esotiche che non vorresti mai e comunque non può confermare che l'indirizzo sia recapitabile. Per l'uso pratico, un pattern breve e permissivo (o l'input HTML5 type="email") per intercettare gli errori di battitura è la giusta dose di regex: il resto è un problema di DNS e SMTP.

Perché la mia regex rifiuta indirizzi email validi?#

Perché i pattern rigorosi codificano presupposti che non sono veri: che i domini di primo livello abbiano 2 o 3 lettere (non è così: .email, .io, .marketing), che il segno più o i punti non siano ammessi nella parte locale (lo sono) o che i nuovi gTLD non esistano. Una regex troppo rigida è una causa comune di iscrizioni perse. Usa un controllo di sintassi permissivo e verifica la deliverability a parte.

La validazione email HTML5 controlla se l'indirizzo è reale?#

No. La validazione type="email" del browser è un controllo di sintassi, una versione più comoda e standardizzata dello stesso pattern matching. Intercetta le @ mancanti e le malformazioni evidenti in fase di inserimento, ma non contatta mai il server di posta, quindi non può dirti se il dominio o la casella esistono.

Cosa usare al posto di una regex per validare le email?#

Procedi a livelli: un controllo di sintassi permissivo per un feedback immediato, una ricerca DNS/MX per escludere i domini morti e un test SMTP della casella per confermare la consegna. I primi due puoi costruirli da te; per il livello SMTP usa un'API di verifica, perché farlo in modo affidabile richiede una reputazione degli IP di invio e una gestione dei limiti di frequenza che una regex non potrebbe mai offrire.

Vuoi vedere la differenza tra "sintassi valida" e "verrà davvero recapitato"? Il piano Free include 100 crediti di verifica che eseguono l'intera pipeline (sintassi, DNS e test SMTP della casella), così puoi vedere un indirizzo approvato dalla regex tornare undeliverable. Il riferimento API ha esempi pronti da copiare in sette linguaggi.