The regex is an approximation because RFC #822 states that nested comments are allowed, but matching nested comments using a single regex is not possible. What’s a comment and nested comment? Well, RFC #822 says you can add a comment in your email address by using parenthesis (). The exact example given in the RFC is:

Muhammed.(I am the greatest) Ali @(the)Vegas.WBA

The values I am the greatest and the are comments. A nested comment would be the word champion in this email address:

Muhammed.(I am the greatest (champion)) Ali @(the)Vegas.WBA

While the IETF RFC #822 standard is the right definition of an email address, it’s the wrong way to validate email addresses. No user is ever going have comments (or nested comments) in their email address. In addition, if we were to adhere to the standard, we’d fail the user test because the standard says the following are also valid email addresses:

me@domain - unless your application is built for an intranet, this will not be valid.

me@gmailcom - again, this would work for an intranet, but the user intended me@gmail.com.

As programmers, we tend to research the “correct” way of doing something before doing it. So what is the right way to validate email address? There isn’t one. A better question to ask is:

How can I best ensure that the email address provided by my users is reachable?

We’re solving for reachability because one of the primary purpose of collecting customer emails is to create a communication channel between the customer and the business. In addition, email is often the only contact point one has with the customer. Ensuring the email is reachable is crucial from a UX and product perspective.

There’s many steps you can take to ensure you get the correct email from customers. Below are some.

Validate against a sane regex

While the above regex adheres to RFC #822, it doesn’t take into account very common mistakes. Assuming you’re taking email address for users on the public internet, a sane regex needs to be mindful of the three parts of an email address:

Email: any alphanumeric character, underscore (_), or hyphen (-), interspersed (but not starting or ending) with a period (.) or a plus (+).

The at symbol (@).

Mail domain: any alphanumeric character interspersed (but not starting or ending) with a period . or hyphen -.

The above criteria yields the following regex:

\w+[\-+.\w]+@(?=.*\.)[^_\W]+([-.a-zA-Z])+

This regex will ensure the email covers the most common email form: “myemail@somedomain.someTLD”. You can see this regex in action here.

Send an actual email

Many services force users to verify their email address by sending a verification email with a link to verify the email and user. While this method is the most effective, it’s only possible after the user submits their email, at which point an invalid email address would be difficult to fix. Ideally, a user should be notified of their mistake much earlier.

One could send an email and wait for a bounceback to determine validity, but that approach requires accounting for the different behavior of the many email providers.

Ask the mail server

Using the SMTP protocol, you can telnet to the mail server and ask to send an email to a specific email. The server would then respond letting you know if that email exists. You can find more details about this method here.

However, not all servers allow this behavior given the security issues with allowing it, namely user enumeration.

While the above methods solve a number of use cases, there’s always more that can be done. For example, Mailcheck provides a spellchecker that catches the most common mispellings of emails like gmail.con or hotnail.com. Some services don’t ask for an email at all but instead require the use of single sign on using Facebook or Google eliminating the need to verify a user’s email.

Approaching technical problems from the perspective of the user is an important technique to adopt when building products. If that means you’ll violate a standard, that’s okay because your biggest critics will be your customers and not a standards working group.