Email Validator
Syntax, common domain typos, disposable providers and role accounts, with the plain statement that only a delivered message proves an address works.
Addresses 8
Pass the syntax check 5
Fail it 3
Warnings 2
[email protected] ok
[email protected] syntax ok
warning "gmial.com" looks like a typo for "gmail.com". One character in a famous domain is the most common way an address is lost, because the bounce goes nowhere anybody reads.
[email protected] syntax ok
note "info" is a role address rather than a person. Some mailing list providers reject them, and consent is harder to argue for a shared inbox.
[email protected] syntax ok
note A plus tag, which Gmail and several others use for filtering. It is a valid address; some systems strip it and a few reject it, so do not use it as a uniqueness key.
broken at example.com fails
error No at sign, so this is not an address.
two@@example.com fails
error More than one at sign. A quoted local part can contain one and almost nothing does, so this is a typo or two addresses run together.
no-dot@localhost fails
error The domain "localhost" has no dot. Valid for an internal host and not for public mail.
[email protected] syntax ok
warning "mailinator.com" is a disposable-address provider. Fine for a download, wrong for an account you intend to keep in touch with, and blocking them stops some real people signing up.
Domains
example.com 2
swiftplugins.pro 1
gmial.com 1
gmail.com 1
localhost 1
mailinator.com 1
Syntax is all this can check. Two things prove an address works: a
message that does not bounce, and a link in it that somebody clicks.
Everything sold as verification in between is a guess, including the
services that promise a live check: the SMTP conversation they rely on
is answered dishonestly by most large providers, on purpose, to stop
exactly that.
The pattern is deliberately practical rather than RFC 5322. That grammar
allows quoted local parts, comments in parentheses and IP-address
domains, and the well-known "official" regular expression for it is
thousands of characters long and still wrong. This accepts what real
providers accept and rejects the things that are definitely mistakes.
A typo in a famous domain is the most expensive failure here, because it
is syntactically perfect and the bounce goes nowhere anybody reads.
Checking against a list of common misspellings catches most of them, and
a confirmation step catches the rest.
Blocking disposable domains blocks real people. Somebody using a
throwaway address for a download is behaving sensibly, and the list is
unmaintainable: new providers appear weekly. Flag them, decide per
feature, and do not treat the flag as a verdict.
Store the address as typed and compare case-insensitively. The part
before the at sign is case sensitive by the specification and no
provider enforces it, so lowercasing on save loses information that some
system will eventually want, and comparing case-sensitively creates
duplicate accounts.
For a signup form, the check that matters is a confirmation email. It
proves the address exists, proves the person has access to it, and gives
you the consent record. No amount of syntax checking does any of those.
Output is valid and updates as you type.
Fix the highlighted fields to update the output.
Two things prove an email address works: a message that does not bounce, and a link in it that somebody clicks. Everything in between is a guess, including the services that sell “real-time verification”: the SMTP conversation they rely on is answered dishonestly by most large providers, deliberately, to stop exactly that probing.
So this checks what a check can check. Syntax, first: the mistakes that are definitely mistakes. Then intent: a typo in a famous domain, a disposable provider, a role account, a plus tag. Each of those is a warning rather than a rejection, because each one is sometimes what the person meant.
How to use
- Paste one address or a list, one per line or comma separated.
- Read the errors, which are real problems.
- Read the warnings, which are decisions.
Example
Addresses 8
Pass the syntax check 6
Fail it 2
Warnings 2
[email protected] ok
[email protected] syntax ok
warning "gmial.com" looks like a typo for "gmail.com". One character in a
famous domain is the most common way an address is lost, because the
bounce goes nowhere anybody reads.
[email protected] syntax ok
note "info" is a role address rather than a person.
[email protected] syntax ok
note A plus tag, which Gmail and several others use for filtering.
broken at example.com fails
error No at sign, so this is not an address.
no-dot@localhost fails
error The domain "localhost" has no dot. Valid for an internal host and not
for public mail.[email protected] is the expensive one. It is syntactically perfect, it will never be
delivered, and the bounce goes to a mailbox nobody reads.
Pitfalls
Do not implement RFC 5322 with a regular expression. The grammar allows quoted local parts, comments in parentheses and IP-address domains, and the well-known “official” regex for it is thousands of characters long and still not right. The practical pattern accepts what real providers accept and rejects what is definitely wrong, which is the useful trade.
Blocking disposable domains blocks real people. Somebody using a throwaway address for a download is behaving sensibly. The list is also unmaintainable: new providers appear weekly. Flag them, decide per feature, and do not treat the flag as a verdict.
Store the address as typed. The part before the at sign is case sensitive by the specification and no real provider enforces it. Lowercasing on save loses information some system will eventually want; comparing case-sensitively creates duplicate accounts. Store as typed, compare folded.
Plus tags are valid addresses. [email protected] delivers to [email protected]. Some
systems strip the tag and a few reject it, so it is a poor uniqueness key, and rejecting it
outright annoys exactly the people who are organised about their inbox.
Role addresses are people too, sometimes. info@ and support@ are real mailboxes. Some
mailing list providers refuse them, and consent is harder to argue for a shared inbox, which is
a compliance question rather than a validation one.
A domain with no dot is valid and undeliverable. user@localhost is a legal address
inside a machine and not on the internet.
Nothing here checks the mailbox exists. Not the domain’s MX records either, which needs a DNS lookup a browser cannot make. An address can pass every check here and bounce.
Compatibility
Everything runs in the browser: nothing is uploaded and nothing is stored. That matters: a list of customer email addresses is exactly the sort of thing not to paste into a website you do not control.
The pattern accepts the specials that real providers allow in a local part, including +, _,
-, ' and the !#$%&*/=?^{|}~ set, and enforces the two length limits from the
specification: 64 characters before the at sign and 253 for the domain.
The typo list covers the common misspellings of the six largest consumer providers, which is where nearly all of these mistakes happen. The disposable list is short by design: it is a sample rather than a defence, and a tool that pretended to be exhaustive would be lying.
For a WordPress form, is_email() is the equivalent check and it is deliberately similar in
spirit: practical rather than exhaustive. sanitize_email() strips the characters it does not
allow, which is not the same as validating, and running it on user input silently changes the
address.