Stop validating email addresses with regex — just send the verification email

A developer at gitpush—force.com dismantles persistent myths about email address handling, arguing that the only reliable check is the one nearly every system already performs: sending a verification message and letting the user prove ownership. Regex validation, the most common alternative, fails on three fronts — it’s easy to get subtly wrong, regex engines behave inconsistently, and the definition of a ‘valid’ address keeps shifting as standards evolve. A regex copied from a 20-year-old forum post encodes assumptions that are now stale, and bad form validation likely rejects more legitimate users than it saves from typos. If client-side validation is used at all, the author recommends something maximally permissive (essentially ‘something@something’) mirrored identically on the backend.

The deeper point is that real-world email infrastructure routinely diverges from the RFCs in both directions. The author demonstrates receiving mail at an address whose 80-byte local-part flatly violates RFC 5321’s 64-octet limit — both sending and receiving providers accept it without complaint. Meanwhile, features that are formally valid get spotty support: SMTPUTF8 (RFC 6531, from the 2012 internationalization push that finally allowed non-ASCII characters before the @ sign) took years to land in Postfix and still isn’t supported by Dovecot in 2026, while Gmail restricts which characters you can register but will happily send UTF-8 addresses.

The practical takeaway: validation belongs to UX, not security. Sanitize inputs rather than rejecting them, skip the MX-record lookups your mail service already performs, and treat the verification email as the source of truth. For many teams, the right move is deleting validation code, not improving it.