Email validation regex: useful checks and common traps
A regular expression can catch obvious input errors, but it cannot verify a mailbox. Treat regex validation as a form-handling decision with a defined compatibility scope, then use server-side checks and confirmation where the application needs more evidence.
Open the relevant free tool →A first-pass pattern examines text only
Define what the form accepts
Before choosing a pattern, decide whether your product supports internationalized addresses, quoted local parts and other less common formats. A short regex usually accepts a practical subset, not every address allowed by every mail standard. Document that choice. A mysterious rejection is frustrating when the user knows their address works elsewhere.
Use a permissive first check
For a basic form, checking for non-whitespace text on both sides of @ and a plausible domain separator can provide helpful feedback. It is a first-pass heuristic. It may accept malformed strings, and it deliberately does not test DNS or mailbox existence. Keep validation messages specific: “Check the address format” is more accurate than “This inbox does not exist.”
Do not reject useful punctuation
Plus signs, dots and some other punctuation can be part of a legitimate local part. A rule that allows only letters and digits can reject real customers. At the same time, blindly stripping punctuation may turn one identifier into another. Preserve the user’s input for review and avoid destructive normalization unless the behaviour is well-defined for that exact provider.
Validate on the server too
Browser checks speed up feedback but can be bypassed. Enforce input type, length and supported syntax on the server before DNS or SMTP work. Do not interpolate an unchecked address into a shell command, HTML result or SMTP command. Render user input with text-safe APIs. Treat the verification endpoint as an untrusted-input boundary even when the normal UI uses type=email.
Test cases before deployment
Create a small set of addresses your product intends to accept and reject. Include a plus tag, a dotted local part, leading and trailing spaces, missing @, consecutive dots and an internationalized example. Keep expected results tied to your chosen assistance policy. Then test the next step separately: a format pass should still allow a DNS failure or an unknown mailbox result without contradiction.
Worked example
A deliberately simple JavaScript first-pass heuristic: /^[^\s@]+@[^\s@]+\.[^\s@]+$/. It is not a complete standards validator and does not establish deliverability.