# Validating email without a regex

An email address takes two steps: a loose regex stops typos, a confirmation message proves the mailbox exists. No regex proves it alone.

> Page: https://ui.eneawork.it/blog/validazione-email-senza-regex
> Markdown: https://ui.eneawork.it/blog/validazione-email-senza-regex.md

*2026-11-01*

Un indirizzo email si controlla in due passi: una regex larga ferma gli errori di battitura, un messaggio di conferma prova che la casella esiste. Nessuna regex da sola dice se l'indirizzo è reale.

Il catalogo EneUI conta 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, letti da /api/stats il 1 novembre 2026. La cifra viene da una query all'endpoint, non da una stima: conta i record pubblicati, non la qualità dei componenti.

## Cosa dice lo standard

La sintassi completa sta nella RFC 5322, e la regex che la copre è lunga e illeggibile. Per un form bastano tre controlli: una chiocciola sola, una parte locale non vuota e un dominio con almeno un punto.

function looksLikeEmail(value) { if (value.length > 254) return false; const at = value.indexOf("@"); if (at < 1 || at !== value.lastIndexOf("@")) return false; const local = value.slice(0, at); const domain = value.slice(at + 1); return local.length <= 64 && /^[^\s@]+$/.test(local) && /^[^\s@]+\.[^\s@]+$/.test(domain); }

I limiti vengono dalla RFC 5321: 254 caratteri in totale e 64 nella parte locale. Sono limiti di trasporto, non una prova che l'indirizzo esista, quindi vanno letti come un tetto e non come una conferma.

## I tre controlli che bastano

## Provarlo in un comando

node -e "const ok = (s) => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(s); console.log(ok('a@b.co'), ok('a@@b.co'), ok('a b@c.co'))"

Il comando stampa true false false: la regex accetta l'indirizzo plausibile e rifiuta chiocciola doppia e spazio. I tre casi vanno verificati prima di fidarsi della regex, perché ognuno copre un errore diverso.

## Record vivi nel catalogo

Tre form di registrazione: full-screen-signup, auth-form e signup-01. Per sfogliare per categoria parti da blocchi signup.

## La limitazione

La regex accetta indirizzi che nessun server consegna e rifiuta casi legali rari, come un dominio con caratteri non latini. La prova che conta è il link o il codice monouso: finché non viene usato, l'indirizzo resta non verificato.

## Dove continuare

La validazione condivisa è in validazione con Server Actions; il form progressivo è in form progressivo; il confronto misurato fra librerie di form è in librerie form React.

## FAQ

### Esiste una regex perfetta per l'email?

No. La RFC 5322 ammette indirizzi che nessun server consegna, quindi una regex completa accetta casi inutili e resta senza prova.

### Quale regex conviene usare?

Una larga: chiocciola singola, parte locale non vuota, dominio con un punto. Ferma gli errori di battitura senza rifiutare indirizzi legali.

### Quanti caratteri può avere un indirizzo?

254 in totale e 64 nella parte locale, secondo la RFC 5321. Oltre quel limite il messaggio viene rifiutato a valle.

### La verifica via email è obbligatoria?

Dipende dal rischio. Per un accesso sì, perché serve a recuperare la password; per una newsletter si può rimandare al primo invio.

### Meglio validare al blur o al submit?

Al blur, così l'errore arriva quando l'utente ha finito il campo. Al submit resta il controllo finale su tutto il form.