Valid Email Syntax

Every verification we run starts with the same first question: is this even a well-formed address? Syntax is the cheapest, fastest check in the entire pipeline, and it is also the most misunderstood. A lot of tools treat a passed syntax check as proof an address is good, and a failed one as proof it is not. Neither is true. Syntax describes the shape of the text, nothing about the mailbox behind it.

What email syntax actually requires

The rules come from two internet standards. RFC 5321 defines the envelope address used during an SMTP conversation, and RFC 5322 defines the address format as it appears in message headers. Together they describe three parts: a local part, the @ symbol, and a domain. The local part identifies the mailbox, the domain identifies where that mailbox lives, and the @ is the one character that has to separate them exactly once.

RFC 5321 also sets hard limits that most real mail servers enforce: the local part can run up to 64 characters, and the full address up to 254. The domain itself has to resolve to a legal hostname, which in practice means it needs a dot and a real top-level domain, not just any string of characters after the @.

What a syntax check catches

A syntax validator is a set of deterministic, offline rules, so it runs instantly and catches the most obviously broken input before anything touches the network. The common failures are a missing @, a domain with no dot or an invalid top-level domain like .con, a blank local part, and stray spaces left over from a copy-paste. RFC 5321 also disallows doubled dots inside the local part, so [email protected] fails on syntax alone, not because the mailbox is unreachable, but because the string itself is malformed.

These checks are worth running first precisely because they are cheap. Rejecting a clearly malformed row before it consumes an MX lookup or an SMTP handshake saves time and avoids wasting a network round trip on input that could never have been valid.

Legal addresses that look wrong

The RFCs permit several forms that look suspicious to a hand-rolled validator but are entirely legitimate. A quoted local part, such as “john doe”@example.com, is allowed to contain spaces and otherwise-special characters as long as it is wrapped in quotes. Plus-addressing, where a sender appends a tag like [email protected], is a widely supported convention for filtering mail, not a malformed string. RFC 5321 additionally permits an IP-literal domain in place of a hostname, so user@[192.0.2.1] is valid syntax even though it never appears in ordinary use.

These edge cases are rare enough that most validators never see one in practice, but a strict validator that rejects them anyway is generating a false positive on a technically valid address, not correctly catching a real error.

Why regex validators over-reject

Most of the regex patterns copied around the internet approximate RFC 5321 and RFC 5322 instead of actually implementing them. A pattern loose enough to accept every legal form usually also lets through malformed strings, and a pattern tight enough to block every malformed string usually also blocks some of the legal edge cases above. Chasing a single regex that gets both sides right at once is a losing trade, since the specs were never designed to compress into one expression.

The more reliable approach treats syntax checking as a set of explicit, RFC-aware rules rather than one clever pattern, and errs toward letting an ambiguous-but-legal address through to the next layer of verification instead of rejecting it outright on a guess.

Syntax is layer one, not the whole answer

The address [email protected] is perfectly valid syntax and cannot receive mail. That gap is the entire reason syntax is treated as the first and fastest layer of email verification, never the last one. A real verification pipeline checks syntax, then confirms the domain has an MX record naming servers willing to receive mail for it, then opens a live SMTP conversation with the receiving server to ask whether that specific mailbox exists and accepts mail.

• Syntax checking is the first stage of the same engine behind the free email validator and the verification API, so a malformed address is caught before it ever reaches a network check.
• To see the full pipeline resolve a real address, from syntax through MX and a live SMTP handshake, run one through the free email checker.
• To watch the SMTP layer specifically, in isolation from syntax and MX, open a handshake with the SMTP test.

Treated correctly, a syntax check is a fast, cheap filter for obviously broken input, not a verdict on deliverability. For teams cleaning lists at scale, where the difference between filtering garbage rows and rejecting real customers comes down to exactly this distinction, the volume tiers are on the pricing page.