Yes, in one narrow sense: a regex can check the shape of an address, and shape is all it can check. Regex email validation tells you that a string looks like an email address. It says nothing about whether the domain accepts mail, whether the mailbox exists, or whether anyone reads it.
A regex (short for regular expression) is a pattern-matching rule that code applies to text. Almost every signup form on the web has one sitting behind the email field, usually copied from a forum answer somebody posted years ago.
So the interesting question is not whether to use one. It is how strict to make it, and what to run after it.
What the email standard actually allows
Address syntax comes from RFC 5322, the Internet Message Format standard. Its core rule is one line: an address is local-part "@" domain. The local part is everything before the @ sign, and it is far more permissive than most people assume.
The standard gives the local part two legal forms, obsolete shapes aside. The common one is a dot-atom: runs of ordinary characters separated by single dots. The punctuation allowed in those runs includes ! # $ % & ' * + - / = ? ^ _ { | } ~ and the backtick. The plus sign is right there in the list, which makes [email protected] perfectly legal, and a form that blocks plus signs wrong rather than strict.
The second form is a quoted string. Wrap the local part in double quotes and a space becomes legal inside it, so "jane smith"@example.com fits the grammar. Rare in the wild. Still valid.
The domain side allows the familiar example.com shape or a domain literal: a bracketed IP address such as [192.0.2.1]. The grammar even permits comments and whitespace around the @, although the standard says they should not be used there.
None of this says a word about delivery. RFC 5322 defines how an address is written. Whether mail arrives is a question for DNS and the receiving mail server, and the standard makes no claim either way.
That gap explains a well-known piece of programming folklore: a regex accepting everything RFC 5322 permits and rejecting everything it forbids runs to thousands of characters and is effectively unmaintainable. Versions circulate online. Almost nobody runs one in production.
What your browser already enforces
If your form uses an input type="email" field, a validation rule is running before your code sees anything. The HTML Standard defines its own idea of a valid e-mail address and openly calls that definition a “willful violation” of RFC 5322.
The spec explains why: for web forms, RFC 5322 syntax is at once too strict on the left of the @, too vague on the right of it, and too permissive overall, allowing comments, whitespace and quoted strings that no signup form has any use for. The simplification is deliberate.
The grammar fits on one line: email = 1*( atext / "." ) "@" label *( "." label ). In plain terms, one or more ordinary characters or dots, an @, then a hostname made of dot-separated labels.
The spec also publishes a regular expression that implements the grammar exactly. Its local part is the character class [a-zA-Z0-9.!#$%&'*+/=?^_{|}~-]+, with the backtick in the class as well, and each domain label is a-zA-Z0-9?. That label rule is the real DNS shape: 63 characters maximum, no leading or trailing hyphen.
Two consequences are worth knowing. Quoted local parts fail browser validation even though RFC 5322 allows them. And jane@localhost passes, because the grammar needs only a single label with no dot after it.
A practical regex email validation pattern for forms
For a signup form, this is usually enough:
^[^\s@]+@[^\s@]+\.[^\s@]+$
Read it left to right: one or more characters that are neither whitespace nor an @, then a single @, then more of the same, then a dot, then more. That is the whole pattern.
It accepts [email protected], [email protected], and every new top-level domain (the TLD is the last piece of a domain name: .com, .io, .agency). It rejects jane@, jane example.com, jane@example with no dot, and jane@@example.com. It catches fat-finger mistakes while the visitor is still looking at the field, which is the entire job.
It will also let through strings that are not addresses, such as [email protected]. That is a deliberate trade. A form pattern that is slightly too generous costs nothing, because a real check runs behind it. A slightly too strict one costs you a signup, silently, from somebody who will not email support to complain.
One easy extra guard: compare the domain against a list of common typos and suggest a fix instead of showing an error.
Where regex gets it wrong, in both directions
Patterns fail in two ways at once, and the second way is the expensive one.
Real addresses a pattern throws away
- Quoted local parts. Legal since forever, rejected by nearly every pattern in the wild, the browser’s included.
- New TLDs. Patterns written a decade ago often end in
[a-z]{2,4}, which quietly rejects.agency,.marketingand.photography. - Internationalized addresses. Non-ASCII local parts and non-ASCII domain names are in use and growing. An ASCII-only character class refuses them all.
- Plus addressing. Over-strict forms block the
+, which breaks the tagged addresses people use to sort their own mail and turns a willing customer into an error message.
Each of these is somebody who wanted to hand you their address and could not.
Dead addresses every pattern waves through
[email protected]. The typo domain is registered, as typo domains usually are, and the spelling is flawless. No pattern will ever notice.- An address at a domain that resolves but publishes no mail servers. The website loads. Mail has nowhere to land.
- The address of a Jane who left the company two years ago. Mailbox gone, text fine.
signup@a disposable domain, one of thousands that exist specifically to expire.[email protected], where the typo lands in the local part instead of the domain. Structurally identical to the real thing.
This second group is what damages a list. These addresses look healthy, sit quietly until your next campaign, then bounce in a batch. They also fill trials with accounts nobody owns, which is a problem with its own playbook.
So what does prove an address is real
Layers, in order of cost. Each one answers a question the layer before it could not.
- Shape. The regex, in the browser. Instant, free, catches typing mistakes while they are still fixable.
- Domain and MX. A DNS lookup asks whether the domain exists and whether it publishes MX records (mail exchanger records, the entries that name the servers accepting mail for a domain). No MX records, no delivery.
- Mailbox. A verifier opens the beginning of a normal SMTP conversation (SMTP is the protocol mail servers use to hand messages to each other), asks whether that exact address exists, then disconnects without sending anything. How that happens without the owner seeing a message is worth reading once if the idea sounds intrusive.
- Risk flags. Existing is not enough. Disposable domains, role addresses (
info@,sales@, owned by a team), catch-all domains and known spam traps all need separating out before you send.
The line between step 1 and the rest has a name worth getting straight: validation versus verification walks through each layer in more detail than there is room for here. In practice you do not build steps 2 through 4 yourself. A verification API runs all of them in one request and hands back a status while the visitor is still on the page.
The four checks side by side
| Check | What it catches | What it misses | Cost |
|---|---|---|---|
| Regex in the form | Missing @, stray spaces, no dot in the domain | Everything about the real mailbox | Free, runs in the browser |
| DNS and MX lookup | Domains that do not exist or accept no mail | Dead mailboxes at healthy domains | Effectively free, one lookup |
| SMTP mailbox check | Addresses with no mailbox behind them | Catch-all domains, which answer yes to any name | Paid per address |
| Disposable and role detection | Throwaway inboxes, shared team addresses, known traps | Real mailboxes nobody reads | Bundled into verification |
Where each check goes
- Run the loose pattern as the visitor types, and put the message next to the field instead of waiting for submit.
- Trim whitespace and lowercase the domain first. A surprising share of “invalid” addresses are just a trailing space.
- On submit, call a verification API. Block the clear failures, accept the safe ones, and write your own policy for catch-all and unknown.
- Never let the form depend on that call succeeding. If the API times out, take the signup and verify it in the background.
- Re-verify the whole list in bulk before big sends. Addresses rot on their own schedule.
If you are weighing where an API earns its place beyond the signup form, these use cases cover the usual ones, and the API documentation shows the request and the response fields.
What none of this can tell you
Worth being straight about the ceiling. A verified address means a mailbox exists and accepts mail today. It does not mean a person reads that mailbox or wants your email. Catch-all domains stay ambiguous by design, some servers refuse to answer at all, and a verifier that returns a confident result for those is guessing. Consent and list hygiene do the rest.
Reoon Email Verifier runs the domain, MX, mailbox and risk checks in a single API call, quick enough to sit inside a form submit, and labels the ambiguous cases as ambiguous. To find out what your current pattern has been letting through, run a sample of your existing list: a free account comes with free daily credits and needs no card.
FAQ
Can a regex fully validate an email address?
No. A regex confirms that a string is shaped like an address, and that is the limit of what pattern matching can do. It cannot look up the domain, contact a mail server, or find out whether a mailbox exists. A misspelled domain, an abandoned account and a throwaway inbox all match a good pattern easily.
What is the best email regex pattern to use?
For a form, something deliberately loose: ^[^\s@]+@[^\s@]+\.[^\s@]+$ catches obvious mistakes without rejecting real people. For a stricter option with a standards body behind it, use the regular expression published in the HTML Standard, which is the rule browsers already apply. Put a verification check behind whichever you pick.
Why does my form reject a valid email address?
Usually the pattern is older than the address. Regexes written before the wave of new top-level domains allow only two to four letters at the end, so .agency and .marketing fail. Other common causes: blocking the plus sign, refusing hyphens inside domain labels, and rejecting non-ASCII characters in internationalized addresses.
Is the browser’s built-in email validation enough on its own?
It catches typing mistakes, which is what it was designed for. It will not notice a misspelled domain, a domain with no mail servers, or a mailbox deleted last year. Treat it as the first filter and keep server-side checks behind it, since anything posting straight to your endpoint bypasses it.
