- Syntax validation, defined
- Syntax validation checks that an address is shaped correctly according to the email specification, and it proves nothing whatsoever about whether the mailbox exists.
A practical check is short: exactly one at-sign, something before it, a domain after it with a dot, no spaces, and a length under 254 characters. That catches what users actually mistype.
The specification is far stranger than most validators assume. "very.unusual.@.unusual.com"@example.com is legal, as is a local part containing !#$%&'*+-/=?^_. Rejecting those is a business decision, not a standards one.
The common failure is the opposite direction: a regex rejecting valid addresses. Plus signs, new top-level domains and hyphens in odd positions all get caught by rules written a decade ago.
Where it genuinely earns its place is in the browser, catching a missing at-sign before the form is submitted. After that, every remaining question needs a network.
How ZapBounce reports it
Syntax is the first stage of our pipeline and the cheapest. A malformed address returns invalid immediately with the reason invalid_syntax, before any DNS query or connection. We never had to ask a mail server anything, so it doesn't cost a credit. Catching the typo in the form is still worth doing, because a shape check only proves the address is well formed.
Seven addresses from one day's form submissions
Go through a realistic batch. The first, jane.doe@gmail,com, has a comma where the dot should be. It's invalid, and a person would want to be told. Next, jane@@example.com has two at-signs and is invalid. After that, jane..doe@example.com has consecutive dots, which the standard forbids in an unquoted local part.
An entry such as jane@example has no dot in the domain. It's legal on a private network and useless on the internet, so reject it. The entry ' jane@example.com' with a leading space is a pasting accident you should repair, not reject.
The last two are the ones clever validators get wrong. o'brien@example.ie is valid, because the apostrophe is an allowed character, and rejecting it insults a real customer. And jane@example.photography is valid, though a rule that expects top-level domains of two to four letters will refuse it. Every false rejection here loses a signup from someone who typed their address correctly.
Clean the input before you judge it
A good share of failures aren't typos at all. People paste from their mail app and you receive Jane Doe <jane@example.com>, or mailto:jane@example.com, or an address with a trailing period carried over from a sentence. Strip the wrapper and outer whitespace first, and then run the check on what remains.
Lowercase the domain, since domains are never case sensitive. Leave the local part as it was typed when you store and send, even though almost no server cares about its case. For duplicate detection, comparing a fully lowercased copy is a reasonable compromise.
Be careful with provider-specific shortcuts. Gmail ignores dots in the local part, so j.doe and jdoe reach the same inbox there. Most other providers don't, and stripping dots everywhere will merge different people into one record. Non-Latin addresses need handling too. A domain in another script is converted to an ASCII form for DNS, and a non-ASCII local part can only be delivered to servers that advertise support for it.
Syntax validation: common questions
Can regex validate an email address?
Only roughly. A regex matching the full specification runs to thousands of characters, and short ones reject valid addresses.
What is the maximum length of an email address?
254 characters overall, with the local part capped at 64. Longer addresses are not deliverable.
Are plus signs valid in an address?
Yes. Plus addressing is standard and widely used, and a validator that rejects it is rejecting real mailboxes.