Anatomy of an Email Address
An email address consists of a local part, an @ symbol, and a domain part. The local part (before @) identifies the specific mailbox and can include letters, numbers, and certain special characters including periods, plus signs, hyphens, and underscores, depending on the email service provider's rules.
The domain part (after @) must have at least one period, at least two characters after the final period, and cannot start or end with a hyphen. Domains like example.co.uk are valid because the TLD (top-level domain) is "uk" and "co" is a second-level domain. Subdomains like mail.example.com are valid because each component after a period follows the rules.
The email validator checks these structural rules. It will catch obviously malformed addresses while accepting valid ones, including tricky cases like plus-addressing (user+tag@example.com) which is valid and commonly used for email filtering.
Common Validation Errors
Regex-based email validation often creates problems by being either too strict (rejecting valid emails) or too permissive (accepting invalid ones). Many developers use simplified patterns that miss edge cases or create frustrating rejections for users with legitimate addresses.
Typical mistakes include: rejecting the plus sign (valid and useful for filtering), rejecting hyphens in the domain (valid), requiring at least 2 characters after the last period (some TLDs are single characters like .I or .X), and not handling internationalized domain names or local parts with non-ASCII characters.
Real email addresses that often fail bad validators include anything @icloud.com with plus addressing, emails with underscores in the local part, and addresses on newer or unusual TLDs. If your validation rejects "team+newsletter@company.co" or "john_doe@work.io," users get frustrated and might abandon your form entirely.
Why Format Validation Isn't Enough
A valid-looking email address can still be completely non-functional. Format validation catches syntax errors but cannot determine whether the mailbox exists, whether the domain accepts mail, or whether the user actually controls the address.
Disposable email services (like mailinator.com) have valid syntax but provide temporary inboxes anyone can use. A user signing up with team@mailinator.com is technically using a valid email address format, but it's not their real address and they'll never receive confirmation emails.
Typos in domain names create valid-format but wrong-destination addresses. A user typing "gmal.com" instead of "gmail.com" has a syntactically valid address at a domain that actually exists, even though no email will reach the intended recipient. Double-checking domains against known providers helps catch some of these.
Beyond Basic Validation
The gold standard for email validation is sending a confirmation email with a unique link. The user must click the link to verify they control the address. This has its own problems — confirmation emails can land in spam, legitimate users abandon the process, and transactional email costs add up at scale.
SMTP validation queries the receiving mail server to check if the mailbox exists, without sending an email. This catches typos in local parts and invalid domains. However, some servers deliberately lie (greylisting) to reduce spam, and this method doesn't verify the user controls the address.
A practical approach combines syntax validation (quick, catches obvious errors), DNS checks (domain exists and accepts mail), and optional confirmation emails (verifies user control). For most applications, syntax validation plus a confirmation email strikes the best balance between user experience and validation quality.