Email syntax checker
Check one address against the RFC rules for shape: characters, dot placement, length limits and the DNS label rules on the domain.
Checked against RFC 5321 and 5322 shape rules: character sets, dot placement, the 64-character local part and the DNS label rules.
What a form should and should not reject
Signup forms reject valid addresses constantly, and the reasons are usually inherited from a regular expression someone copied years ago. Plus signs get rejected. Apostrophes in Irish surnames get rejected. Newer top-level domains get rejected because the pattern assumed nothing was longer than four letters.
Every one of those is a real customer turned away at the door. A form is better off accepting anything that could be an address and confirming by sending to it, which is the only test that settles the question anyway.
What a form should catch is the obvious. A missing @, whitespace in the middle, two dots in a row, a domain with no dot at all. Those cannot be addresses under any reading of the spec, and telling someone immediately is kinder than a confirmation mail that never arrives.
The most valuable check is the typo suggestion. One character off a large provider is the most common mistake there is, and asking "did you mean gmail.com?" recovers signups that otherwise vanish silently.
| Address | Legal shape | Why people get it wrong |
|---|---|---|
| name+tag@example.com | Yes | Forms reject the plus by habit |
| o'brien@example.com | Yes | Apostrophes are legal in the local part |
| name@example.technology | Yes | Old patterns assumed short top-level domains |
| "odd name"@example.com | Yes, quoted | Legal and handled badly by a lot of software |
| name..surname@example.com | No | Two dots in a row are not allowed unquoted |
Where syntax sits in a real check
It is the first step and the cheapest. A malformed address needs no DNS query and no connection to anybody's server, so catching it here saves the work of every later stage.
After that comes the domain: does it have mail servers, and do they resolve. Then the SMTP conversation, where the receiving server is asked about the specific recipient and either accepts, rejects, or declines to say.
Most of the difficulty lives in that last step, and none of it is visible from a shape check. A domain that accepts every address gives the same answer for a real mailbox and an invented one, which is why catch-all domains cannot be settled at mailbox level by anyone.
Questions people ask
Why does my regular expression reject valid addresses?
Because the full grammar is far more permissive than almost any pattern written by hand. Quoted strings, unusual characters and long top-level domains are all legal, and most patterns predate several of them.
Are email addresses case sensitive?
The local part is allowed to be, under the spec. In practice every large provider treats it as case-insensitive, and none of them create two mailboxes that differ only by capitals.
Can an address contain non-English characters?
Yes, under the internationalised address standards, and support is uneven. This tool checks the traditional ASCII rules, so an address with accented characters is flagged here while working fine at a provider that supports it.
Is info@ a valid address?
Perfectly valid, and worth knowing about. Role addresses reach a group or nobody, and whoever opens them is more likely than an individual to report the mail as spam.
Shape is step one of five
The rest needs DNS and an SMTP conversation. We run those, and we label what the receiving server refused to settle instead of filling the gap with a guess.