Why this is not an RFC-compliant validator
RFC 5322 permits far more than any mail provider will issue. Quoted local parts can contain spaces, at-signs and control characters. Comments in parentheses are legal in the middle of an address. Domain literals let you write an IP address in brackets instead of a hostname. Attempts to express all of that as one regular expression run to several thousand characters, and there is a well-known one that people paste into projects without ever testing.
Doing so is a mistake in both directions. It accepts addresses that Gmail, Outlook and every corporate mail system would reject at signup, and — because the monster regex is difficult to reason about — it tends to be wrong in ways nobody notices. The checks here are the practical set: a local part of letters, digits and . _ % + -, a domain shaped like a hostname, a real TLD on the end. That is what the signup forms of large providers enforce, so it is the boundary that matters in practice.
The typo is in the domain, and no regex will catch it
Look at where signup failures actually come from and it is not malformed syntax; it is gmial.com, gmai.com, hotmial.com, yaho.com, outlok.com. Every one is perfectly well-formed. Every one bounces. The user then waits for a confirmation email that will never arrive and concludes your service is broken.
The detection here is Levenshtein distance — the number of single-character insertions, deletions or substitutions needed to turn one string into another — against a list of the domains that appear most often. Within two edits of a very common domain, and not on the list itself, gets a suggestion. It is a suggestion and nothing more, because real domains do live near popular ones. Offer it, never apply it silently, and let the user say no.
Address verification is a solved problem, and the solution is sending mail
There was a period when you could open an SMTP session, issue RCPT TO, and read the response to learn whether a mailbox existed. Spammers used it to harvest live addresses, so mail operators closed it. Modern servers commonly accept every recipient at SMTP time and generate a bounce later, or run catch-all configurations where nothing is ever rejected, or greylist an unfamiliar connection outright. Probing also gets your IP onto reputation blocklists, which is a slow, expensive way to break your own outbound mail.
The paid verification services that still advertise this are working from historical bounce data and pattern heuristics, and they will tell you so if you read the small print about accuracy. The one method that gives a definite answer is delivering a message with a unique link and waiting for the click. That is the whole reason double opt-in exists, and it is why syntax checking should be a fast client-side nicety in front of that process rather than a substitute for it.
Plus addressing, dots and case
Gmail treats [email protected] as mail for [email protected], and ignores dots in the local part entirely, so [email protected] is the same mailbox again. Many other providers support the plus convention; the dot-folding is largely a Gmail behaviour. Systems that block + at signup, on the theory that it is used to evade limits, break a legitimate and widely used habit — and it is trivially worked around anyway, so the block costs more than it earns.
Case is the one worth stating precisely: domains are case-insensitive, local parts are technically case-sensitive, and in practice every provider you will encounter treats them as insensitive too. Store what the user typed, compare lowercased, and do not surprise someone who capitalised their own name by telling them the account does not exist.
Questions people ask
The address passes — will my email arrive?
Unknown, and this page cannot narrow it down. Passing means the string is shaped like an address. The mailbox may not exist, may be full, may be an alias pointed at nothing, or may route your message straight to spam. The only test is to send something and see what comes back, which is exactly why confirmation emails exist.
Why is a valid but unusual address rejected here?
Because the checks match what mail providers accept rather than what the RFC permits. Quoted local parts, embedded comments and bracketed IP domain literals are all legal on paper and all refused by real signup forms. If you have an address that fails here and demonstrably receives mail, the checks are wrong for your case and the fix in your own code is to loosen them, not to write the thousand-character regex.
Is the address I type stored or sent anywhere?
No. The page is static HTML and the checking runs in JavaScript on your machine. There is no request to any server when you type, which the network tab of your dev tools will confirm, and nothing persists after you close the tab.
Should I block disposable domains at signup?
Usually not worth the effort. Any list goes stale within days because the services rotate domains continuously, so you get false confidence plus false positives on legitimate privacy-forward providers. If disposable signups are genuinely costing you, address the incentive — require a confirmed address before the valuable action, rather than trying to enumerate every throwaway domain in existence.