Free Email Syntax Checker

The anatomy of an email address

Every address has three parts: the local part (what comes before the @ — the mailbox name the receiving server interprets however it likes), the @ separator (exactly one, outside quotes), and the domain (where DNS routes the mail). The domain itself is a chain of dot-separated labels — in mail.example.co.uk the labels are mail, example, co and uk — ending in a top-level domain of at least two letters. Each part has its own character rules and its own length limit, which is why a proper checker tests them separately instead of throwing one regex at the whole string.

What the RFCs allow vs. what servers accept

The specs — RFC 5321 for the SMTP transport and RFC 5322 for the message format — are far more permissive than most people expect. "john doe"@example.com (a quoted local part with a space), user@[192.168.1.1] (an IP-literal domain), and local parts full of !, #, $ and backticks are all grammatically legal. But "legal" and "deliverable" are different questions: most production mail servers, ESPs and signup forms reject quoted locals and IP literals on sight, because in the wild they're almost always malformed input or abuse attempts.

That gap is why the check has a middle verdict. Valid but unusual means the address passes the spec but sits in territory that real-world servers routinely refuse — worth knowing before you build a list or a validator around it. We'd rather tell you that plainly than hide the nuance behind a green check.

The famous "perfect email regex" trap

There's a legendary regex that implements the full RFC 822 address grammar. It runs to thousands of characters, is essentially unreadable, and still doesn't answer the question you actually have — because no regex can check length limits cleanly, convert internationalized domains, or know whether a mailbox exists. Meanwhile the tight "simple" regexes floating around reject perfectly legal addresses (plus signs, newer TLDs, IDNs) and annoy real users.

The pragmatic answer, and the one we recommend: validate format with a small set of explicit rules — one @, allowed characters, dot placement, the 254/64/63 length limits, a plausible TLD — and then verify the address rather than trying to regex your way to certainty. That's exactly the battery the product runs on your address, and it's the first stage of the full verification pipeline.

Length limits, and where they come from

The numbers the check enforces aren't arbitrary. RFC 5321 caps a forward path at 256 characters including the angle brackets, which leaves 254 for the address itself. The same RFC limits the local part to 64 characters. And each domain label is capped at 63 characters by RFC 1035 — a DNS constraint older than the web. Addresses that blow these limits may survive a naive regex, but they'll be refused at the SMTP layer, so the checker fails them with the exact count.

Plus-addressing, IDN and other legal oddities

Plus-addressing — name+tag@gmail.com — is fully valid: + is an ordinary allowed character, and providers like Gmail and Fastmail deliver anything after the + to the base mailbox while letting you filter by the tag. (Gmail's habit of ignoring dots in the local part is a similar story: provider behavior, not the spec.) Internationalized domains like müller.de are valid too — under the hood, mail systems convert them to an ASCII punycode form (xn--mller-kva.de), which the check surfaces so you can see the on-the-wire form. Non-ASCII characters before the @ are shakier ground: they require SMTPUTF8, which plenty of servers still don't support, so the checker warns rather than passes.

Why format validation is only step one

A perfect format score tells you the address could exist — nothing more. ceo@this-domain-was-never-registered.com passes every format rule and will bounce every time. Real deliverability needs the next stages: does the domain resolve in DNS, does it publish an MX record, is it a throwaway domain, and — the only conclusive test — does the SMTP server confirm the mailbox? That's the upside of running the check inside the product: the same free credits cover the full verification pipeline, and the API runs it in real time if you're validating at a form.