Regex per la Validazione Email: Pattern che Funzionano Davvero

La validazione email è uno dei casi d'uso regex più comuni — e uno dei più fraintesi. La specifica RFC 5321 per gli indirizzi email è sorprendentemente complessa, e nessuna singola regex può validarla completamente. Ma pattern pratici che coprono il 99,9% degli indirizzi email reali sono sia realizzabili che utili.

Il Pattern Semplice (Sufficientemente Buono)

Per la maggior parte delle applicazioni, questo pattern funziona bene:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Cosa corrisponde: Uno o più caratteri consentiti, seguiti da @, seguiti da un dominio con almeno un punto e un TLD di 2+ lettere.

JavaScript:

const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
emailRegex.test('user@example.com');  // true
emailRegex.test('user@.com');          // false

Testa questo pattern con il nostro Regex Tester.

Perché la Validazione Regex Perfetta è Impossibile

La specifica email (RFC 5321/5322) consente strutture che sono valide ma essenzialmente mai usate in pratica:

"john..doe"@example.com           // Parte locale quotata con punti consecutivi
user@[192.168.1.1]                // Indirizzo IP come dominio
"very.(),:;<>[]".VERY."very@\ "very".unusual"@strange.example.com

Una regex che gestisca tutti gli indirizzi RFC-validi è lunga migliaia di caratteri e potrebbe comunque non coprire ogni caso limite. L'approccio pratico: usa una regex semplice per la validazione del formato di base, poi verifica che l'email esista davvero inviando una conferma.

Analisi del Pattern

Parte Locale (prima della @)

[a-zA-Z0-9._%+-]+

• Lettere (maiuscole e minuscole)
• Cifre
• Punti, underscore, percento, più, trattino
• Uno o più caratteri

Errori comuni:

• Permettere punti all'inizio o alla fine (tecnicamente non valido)
• Permettere punti consecutivi (tecnicamente non valido senza quoting)
• Essere troppo restrittivi (bloccare caratteri validi come + usato negli alias Gmail)

Parte Dominio (dopo la @)

[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

• Caratteri alfanumerici, punti, trattini
• Almeno un punto
• TLD di 2+ caratteri alfabetici

Errori comuni:

• Limitare la lunghezza del TLD a 3-4 caratteri (.museum, .photography esistono)
• Non permettere trattini nei nomi di dominio
• Non gestire i sottodomini (user@mail.example.co.uk)

Pattern Migliori

Standard HTML5

La specifica HTML5 definisce questo pattern per <input type="email">:

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$

Questo è più permissivo nella parte locale e più rigoroso sulla lunghezza delle etichette di dominio.

Pattern Pratico Raccomandato

^[^\s@]+@[^\s@]+\.[^\s@]{2,}$

Questo pattern minimale semplicemente assicura: niente spazi, una @, almeno un punto dopo @, TLD di 2+ caratteri. È intenzionalmente permissivo — intercetta input ovviamente errati senza rifiutare indirizzi insoliti ma validi.

Implementazione per Linguaggio

JavaScript

function isValidEmail(email) {
  // Controllo regex di base
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/;
  if (!regex.test(email)) return false;
  
  // Controlli aggiuntivi
  if (email.length > 254) return false;  // Limite RFC 5321
  const [local] = email.split('@');
  if (local.length > 64) return false;   // Limite RFC 5321
  
  return true;
}

Python

import re

def is_valid_email(email: str) -> bool:
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    if not re.match(pattern, email):
        return False
    if len(email) > 254:
        return False
    local, domain = email.rsplit('@', 1)
    if len(local) > 64:
        return False
    return True

Oltre le Regex: Validazione Email Corretta

Le regex sono solo la prima linea di difesa. Una strategia di validazione completa:

1. Controllo formato (regex): Rifiuta formati ovviamente non validi
2. Controllo lunghezza: Parte locale ≤ 64 caratteri, totale ≤ 254 caratteri
3. Controllo DNS: Verifica che il dominio abbia record MX
4. Rilevamento email usa e getta: Blocca servizi email temporanei se necessario
5. Email di conferma: L'unico modo per verificare davvero un'email — invia un messaggio e conferma che l'utente lo riceva

// DNS MX record check (Node.js)
const dns = require('dns');
const [, domain] = email.split('@');
dns.resolveMx(domain, (err, addresses) => {
  if (err || !addresses.length) {
    console.log('Domain has no email server');
  }
});

Errori Comuni da Evitare

1. Pattern troppo restrittivi: Bloccare user+tag@gmail.com (plus addressing) o user@subdomain.example.com
2. Case sensitivity: Le parti locali delle email possono essere case-sensitive secondo RFC, ma in pratica trattale come case-insensitive
3. Trimming: Rimuovi sempre gli spazi bianchi prima della validazione — " user@example.com " dovrebbe passare
4. Domini internazionali: .münchen e 用户@例え.jp sono validi nell'email internazionalizzata

Per più pattern regex, consulta il nostro Regex Cheat Sheet.

FAQ

Dovrei validare le email con regex sul client o sul server?

Entrambi. La validazione lato client fornisce feedback istantaneo (migliore UX). La validazione lato server è obbligatoria per la sicurezza (i controlli client possono essere bypassati). Non fidarti mai della sola validazione lato client.

Perché alcuni siti web rifiutano il mio indirizzo email valido?

Pattern regex troppo restrittivi sono la causa usuale. Indirizzi con + (alias Gmail), TLD lunghi (.technology) o sottodomini vengono spesso rifiutati da validazioni scadenti. Se gestisci un sito web, usa regex permissive e verifica con un'email di conferma invece.

Risorse Correlate

• Regex Tester — Testa pattern di validazione email in tempo reale
• Regex Cheat Sheet — Riferimento completo ai pattern regex
• Validazione JSON Schema — Valida campi email in JSON con format: email