As far as I know, that literally is the only way to validate an email address, universally speaking, beyond an internal whitespace check.

But I think if you take "local" out of the equation, as you would for customer emails, you can validate a bit more. You might be able to validate on a single @ being in there somewhere, with something before and after it, maybe look for a period after the @ for "[email protected]" as I think every external address needs a dotted domain.

That's about as far as I think you can safely go. Anything else is legal.

Well, maybe not a single @. At least one @ maybe. There's a set of special characters that aren't permitted in the local part of an email address including @... unless they're quoted. So "@"@example.com is a valid address.

Oof, thanks. I forgot you could quote the @ and thought it was the one universally illegal character. Also forgot there were others, oops.

I usually just recommend people don't validate email addys and let the email verification message do the job for you. This is pretty much why.

Domains labels are fairly strictly defined, so you check that a bit more stringently.

> as I think every external address needs a dotted domain.

Something like example@com is technically a valid email address; although I don't know if there are any TLDs which accept emails.

That's true, I didn't think about that case.

I don't think I've ever seen a bare TLD in real life like that though--maybe very early on as DNS became a thing? Not since the web though.

Yep, I agree. On frontend, use a very simple validation such as /.+@.+\..+/ (better to use string splits IMHO, but you see the idea) just to give users some feedbacks in case of a clearly invalid email.

On the backend send an email and let the user confirms.

Sometimes you need to harvest email addresses and want to distinguish them from junk data. If you're actually developing the algorithm in the face of real data, you'll get a good validator.