Email validation without annoying people

A regular expression that fully implements the address syntax in the email specification runs to thousands of characters. It exists, people have written it, and nobody sensible deploys it.

That fact is the most useful thing to know about email validation. The formal grammar permits quoted strings, comments, and characters almost nobody has ever used in an address, which means a truly correct validator accepts things you would swear were invalid.

Meanwhile the practical problem is not exotic syntax at all. It is somebody typing gmail.con.

So the right approach is not to implement the specification. It is to catch the mistakes people actually make, without rejecting the addresses that merely look unusual.

Those two goals pull in opposite directions, which is why this field generates so much bad advice. Every rule that catches more typos also rejects more real addresses, and the only way out is to stop treating it as a single pass or fail decision.

A syntax check proves the address is shaped like an address. That is all.

It cannot prove the domain exists, that the mailbox exists, that anyone reads it, or that the person typing it owns it. Treating a passing format check as evidence of a working address is the most common misunderstanding in this area.

A domain check goes one step further and is genuinely useful: if the domain has no mail configuration at all, the address cannot receive anything and something is wrong.

Beyond that, the only real proof is sending a message and seeing whether it is accepted, which is what makes bounce data the actual verification step rather than anything that happens at submission.

Four layers, in increasing order of intrusiveness, and most sites should stop after two.

First, a permissive format check: something before an at sign, something after it, a dot in the domain, no spaces. This catches genuine nonsense and rejects almost nothing real.

Second, a typo hint on the page. If the domain closely resembles a common one, suggest the correction rather than blocking. Did you mean gmail.com, offered as a question, catches a real share of mistakes and irritates nobody.

Third, a domain check on the server for whether the domain can receive mail at all. Fourth, confirmation by email, which is appropriate for a mailing list and disproportionate for a contact form.

Of all the interventions available, suggesting a correction for a near-miss domain has by far the best ratio of leads saved to friction added.

The errors it catches are the ones that genuinely lose customers: a transposed letter in a common consumer domain produces an address that is syntactically perfect and completely undeliverable.

It works because it is a suggestion rather than a gate. The visitor who genuinely does use an unusual domain clicks past it. The visitor who mistyped fixes it in one click and never thinks about it again.

Any rule that blocks would have to be certain, and certainty is not available. A suggestion does not need it.

Plenty of valid addresses trip naive validators.

Plus addressing, where someone writes their address with a suffix before the at sign, is a standard and widely used feature that some forms reject outright. Long or unusual top-level domains are valid and increasingly common. Addresses with several dots in the local part are fine. Non-ASCII characters are permitted in modern internationalised addresses.

Rejecting any of these means turning away a technically literate customer while telling them their own address is invalid, which is a memorable experience for the wrong reason.

When in doubt, accept and let the downstream screening or the eventual bounce sort it out.

Blocking throwaway domains is not validation, it is policy, and it should be a deliberate decision rather than a side effect of a validation library.

Some disposable addresses are automated junk. Others are cautious buyers evaluating you quietly who do not want a sales sequence. Blocking both means turning away the second group entirely.

For a contact form the better handling is to accept, mark, and let a person decide. For a form that grants access to something valuable, blocking is more defensible because the incentive to abuse is higher.

Either way, the lists are never complete and new domains appear constantly, so treat it as a signal rather than a gate.

The check in the browser exists to help the person: fast feedback, a suggestion, a chance to fix a mistake before submitting.

The check on the server exists to protect your data, because anything in the browser can be bypassed. It should be permissive but present, because a submission with no address at all in the address field is worth catching.

Neither should be strict. The client check should never block an address the server would accept, or you get the maddening case where the form refuses something that would have worked.

And the server check should never silently modify the value. Trimming whitespace is fine; anything more is a surprise nobody asked for.

When you do reject, the message must say what is wrong specifically. Please enter a valid email address is useless, because the person believes theirs is valid, which is why they typed it.

This address is missing an at sign is actionable. This domain does not look like it can receive email is actionable. Did you mean gmail.com is best of all.

Place the message beside the field rather than at the top of the page, and never clear the value when showing it.

These are the same principles as error handling generally, and the address field is where they get violated most often.

For a newsletter, sending a confirmation before adding someone is standard, protects your sending reputation, and doubles as consent evidence.

For a contact form it is close to always wrong. You are asking a person who wants to talk to you to complete an extra step before you will even read their message, and a meaningful number will not.

The exception is when responding is expensive, such as a service that reserves scarce capacity per enquiry. There the extra step filters usefully.

For an ordinary enquiry, accept the address, reply to it, and treat a bounce as the verification you were looking for.

A permissive client-side format check with an inline typo suggestion. A permissive server-side check with the same rules. Domain deliverability checked where you can. Disposable domains flagged rather than blocked. Specific error messages beside the field. Bounces recorded against the lead.

That combination catches nearly every real mistake, rejects nothing genuine, and produces a column of addresses that are actually usable.

It also fails safe. When it is wrong, it is wrong in the direction of accepting a lead you can screen later, rather than turning one away at the door. Every part of the design should be checked against that standard, because a validator that fails closed is indistinguishable, from the outside, from a form that is broken.

That direction of failure is the whole design principle, and it is the same one behind holding doubtful submissions for review rather than rejecting them. An unwanted row costs a second of your attention. A rejected customer costs the sale and never tells you it happened.

Should I use a strict regular expression?

Does a format check prove the address works?

What single check gives the most value?

Are plus signs in addresses valid?

Should I block disposable email domains?

Do I need a confirmation email?

Where should validation live?

What should the error message say?