Validating email addresses: what a syntax check can and cannot tell you

What it is

An address is local-part@domain. RFC 5321 limits the local-part to 64 octets, a domain name to 255 octets and a whole forward or reverse path to 256, and says the local-part must be treated as case-sensitive while exploiting that is discouraged. The RFC 5322 grammar additionally allows quoted local-parts, comments and folding whitespace that almost nobody uses. The HTML standard deliberately defines a simpler grammar for <input type=email>: a run of atext characters and dots, @, then dot-separated labels of at most 63 characters; it calls this a willful violation of RFC 5322, whose syntax it describes as simultaneously too strict before the @, too vague after it and too lax overall for forms. Internationalised addresses with non-ASCII local-parts are defined by RFC 6531 (the SMTPUTF8 extension) and only work when every server on the path supports it.

Why it matters

No regular expression can tell whether a mailbox exists, whether its owner typed it, or whether it will accept your mail. Over-strict checks reject real people (plus-addressing, apostrophes, newer top-level domains); over-lax checks admit user@localhost and typos, which later turn into bounces and reputation damage.

How to apply

• Validate syntax with the HTML standard's definition (or the browser's built-in check) plus the length limits; for public sites, require a dot in the domain.
• Normalise minimally: trim whitespace, lower-case the domain, keep the local-part as typed.
• Check at signup that the domain has an MX record (or an A/AAAA fallback); treat a lookup failure as "please check this address", not as a hard rejection, because DNS can be temporarily unavailable.
• Prove ownership with a confirmation link or code; SMTP-level probing of the recipient server is unreliable and looks like abuse.
• Decide explicitly whether to accept SMTPUTF8 addresses. If the sending provider does not support them, reject with a clear message at signup instead of failing at send time.
• Suggest corrections for common domain typos, but never apply them automatically.

Pitfalls

Rejecting + in the local-part or a top-level domain because it is longer than four characters. Lower-casing the local-part, which changes a case-sensitive identifier. Treating disposable-domain lists as a security control. Using the address as the primary key: people change addresses, and two people can share one.

The null MX record

RFC 7505 lets a domain declare that it accepts no mail by publishing a single MX 0 . record. A lookup that only checks whether an MX record exists therefore accepts precisely the domains that have opted out, so the signup check needs one more branch: resolve MX; if the only answer is 0 ., reject with a message that the domain does not accept mail; if there are ordinary MX records, accept; if there are none, fall back to A or AAAA as RFC 5321 permits; and treat resolver errors as "please check this address" rather than as a rejection. The same rule belongs in the sending pipeline, where a null MX is a permanent failure that should never enter the retry queue.