Email Validator

How to use?

Type the email address into the field above. Validation follows the RFC rules, splits the address into its parts (local, domain and TLD) and flags the common typing slips that tend to go unnoticed.

How email validation actually works

An email address has two parts separated by a single @: the local-part (before the @) and the domain (after). The syntax is defined by RFC 5321 (SMTP) and RFC 5322 (message format). Per RFC 5321 §4.5.3.1, the local-part is limited to 64 octets and the domain to 255 octets, but the full forward-path including angle brackets cannot exceed 256 octets — so the practical address limit is 254 characters, not the 320 that the individual limits naively suggest.

This tool checks structural validity only — exactly one @, a non-empty local-part built from the ASCII characters the RFC allows, a domain whose labels are letters, digits and hyphens ending in a TLD of two letters or more, and the two ceilings above — 64 octets for the local-part, 254 characters for the whole address. Dots have to obey the RFC 5322 dot-atom rule, so they may sit between atoms but never lead, trail or double up: [email protected], [email protected] and [email protected] are all rejected. It does not confirm that the mailbox exists. Mailbox existence requires a DNS MX lookup followed by an SMTP RCPT TO handshake against the receiving server, and even that is increasingly unreliable: most providers answer "OK" for any address and then silently bounce, to prevent enumeration attacks.

Levels of validation

There are three practical tiers. Syntactic validation (what this page does) catches typos like a missing @, a second one, illegal characters, a misplaced or doubled dot, a domain with no dot at all, or a TLD shorter than two letters. DNS validation goes one step further and confirms the domain has MX or A records — this catches users who typed gmial.com by accident. SMTP verification opens a TCP connection to the MX server and tries a RCPT TO without sending the message; modern anti-spam policies (Google, Outlook, Apple) make this approach unreliable and it can also get your IP flagged.

The local-part is actually allowed to contain a surprisingly broad set of characters under RFC 5321 — including +, ., -, _, and quoted strings with spaces. Many regexes you find on Stack Overflow reject perfectly valid addresses. The HTML5 spec actually defines a deliberately stricter pattern that rejects some valid RFC addresses in exchange for catching real-world typos.

FAQ

Why does my address pass here but get rejected by a website? Many sites apply tighter rules than the RFC — they may forbid the + sign, require a generic TLD, or block disposable-email domains. Validity is not the same as acceptance.

Is [email protected] a real address? Yes — the +tag suffix is valid per RFC and Gmail (along with Outlook and Fastmail) routes it to the base mailbox while preserving the tag, so you can filter or detect leaks.

Does this tool send any email? No. Validation runs entirely in your browser — nothing is uploaded to a server or to a third-party API.

What about internationalized addresses (EAI)? RFC 6531 allows Unicode in both the local-part and the domain (josé@niño.es). Support across providers has improved a lot since 2020 but remains uneven — many legacy mail systems still reject non-ASCII.