Lies We Tell Ourselves About Email Addresses | git push --force
Mono Font<br>Lies We Tell Ourselves About Email Addresses
2026-06-06T22:54:55-04:00TL;DR: Don't overthink it, just send a verification email.
Bear with me, because some of these “lies” are going to feel obvious, or like unimportant trivia. In all honesty, that’s not that<br>far from the truth. However, I hope you’ll let me try to build a detailed and fun illustration showing how something as mundane<br>as email can break our expectations in surprising ways.
We’ll cover a lot of edge cases, stumble over some small blocks, and even discover a few technically-correct things that<br>are valid, but not commonly supported even in big systems like Gmail (probably for good reason, to be fair).
Each example isn’t necessarily meant to be a meaningful use-case that you need to go make sure you’re handling<br>correctly. But, all together, they’re meant to gradually build toward one main point: Email addresses are mired in old<br>history, and the definitions of valid and invalid components of the system continue to subtly change over time.
It’s easy to make a common-sense decision that is unexpectedly problematic. On top of that, older devs (and older systems)<br>may have expectations that were correct in the past but don’t work anymore. And without further ado, on to the lies…
“Email addresses can just be validated with a regex”
Let’s get the low-hanging-fruit out of the way. I’m far from<br>the first person<br>to say this online<br>and I certainly won’t be the last. But I feel it’s justified repetition because, even after a thousand blog posts posted,<br>tweets twote, and reddit comments moderated, this antipattern stubbornly persists in 2026.
The regex approach has three main avenues for causing heartache for you, your business, and your customers:
It is relatively expensive to run, for very little-to-no real benefit
To be fair, this point used to hit harder, before we started throwing simple queries at giant clusters of<br>power-hogging GPUs.
Regex is hard, regex wizardry is rare, and regex engine implementations are inconsistent. It’s very, very easy to accidentally get it wrong without realizing it.
We’ll go over a couple of the ways it could go wrong through the rest of this post.
Even if you copypaste one of the “good” regexes, the world is evolving. What’s valid today may be legacy tomorrow,
The internet is littered with advice that was good 20 years ago. It’s also littered with regular expressions that were<br>good 20 years ago, because legacy is forever.
Opinion alert: Input validation is more about helping the user by making it harder to make simple mistakes.<br>It should be restrictive enough to make your user’s life easier, but only just. Don’t rely on input validation to<br>protect you from your users ; use it to protect your users from themselves. In that sense, there’s a valid argument for<br>using regex tests to improve UX, which is worth considering. UX is important and I won’t dismiss that fact. However, to play devil’s advocate for a moment,<br>perhaps the risk outweighs the reward. In the year of our lord 2026, you can reasonably expect your users to know how<br>to type their own email address - or even better, auto-input from their OS, browser, keyboard app, or password manager.
It’s likely that more people out there are being filtered by badly-implemented form validation than there are being<br>filtered by their own need of hand-holding. On that note, then…
Don’t validate email addresses. If you simply must, use a simple client regex to help users avoid common mistakes and typos.
Try to keep it as non-restrictive as possible. Something like ^[^@]+@[^@\s]+$, which only makes sure your user has<br>input “something@something”
If you have validation on the API or form handler, use THE SAME regex, for consistency with the frontend.
This comes back to that “don’t use input validation to protect you from your users” point. By default, protect<br>yourself by sanitizing inputs, not by rejecting them.
Verify the address, don’t worry about validating it.
Send an email, let your user click a verification link or input a verification code.
That’s it. It doesn’t need to be more complicated than that. You don’t need to check the domain’s MX record; your email<br>service does this as part of the whole “sending the email” thing (Also, spoiler alert, but there’s some more MX Record fun below).<br>And you definitely don’t need to do a big regex. In fact you’re probably already sending a verification email anyway!<br>If you are, this might be an excuse to delete code, which is every programmer’s actual favorite thing!
Now with the easy part out of the way, let’s go over some of the specific points that make email handling fun...