How to Validate Email Addresses (The Right Way)

Email validation is one of those problems that looks trivial until you actually try to solve it properly. A quick regex check catches obvious typos, but real validation requires understanding the RFC specification, knowing where most developers go wrong, and deciding how strict your checks need to be.

This guide breaks down email validation from format rules to practical implementation. For a quick check on any address, use our Free Email Validator.

What Makes an Email Address Valid?

RFC 5322 defines the official format for internet email addresses. The basic structure is:

local-part@domain

The local part (before the @) can contain:

• Uppercase and lowercase letters (A-Z, a-z)
• Digits (0-9)
• Special characters: . ! # $ % & ' * + / = ? ^ _ { | } ~ -
• Dots (.) as long as they aren’t the first or last character and don’t appear consecutively

The domain part (after the @) must:

• Contain at least one dot separating labels
• Use only letters, digits, and hyphens in each label
• Not start or end a label with a hyphen
• Have a top-level domain (TLD) of at least two characters

Examples of valid addresses that many validators incorrectly reject:

Address	Why It Is Valid
user+tag@example.com	Plus addressing is RFC-compliant
user.name@example.co.uk	Subdomains and country-code TLDs are fine
user@123.123.123.123	IP address literals are technically valid
”john..doe”@example.com	Quoted local parts allow almost anything
user@subdomain.example.com	Multiple domain levels are common

Common Email Validation Mistakes

Mistake 1: Requiring a Specific TLD Length

Many validators reject addresses where the TLD is longer than three characters. This breaks validation for .info, .museum, .technology, and hundreds of newer TLDs like .photography or .international. TLDs now range from 2 to 63 characters.

Mistake 2: Blocking the Plus Sign

The + character is valid in the local part. Gmail and other providers use it for sub-addressing: jane+newsletters@gmail.com delivers to jane@gmail.com. Blocking plus signs frustrates users who rely on this feature to organize their inbox.

Mistake 3: Checking for MX Records Only

An MX record lookup confirms that a domain can receive mail, but the absence of an MX record doesn’t mean the address is invalid. Per RFC 5321, if no MX record exists, the sender should fall back to the domain’s A record. Some legitimate mail servers are configured this way.

Mistake 4: Overly Strict Regex

A regex that tries to cover every edge case in RFC 5322 can run to thousands of characters and still miss corner cases. The practical approach is a regex that handles 99.9% of real-world addresses combined with a confirmation email for actual verification.

Mistake 5: Case-Sensitive Local Parts

While RFC 5321 states that the local part is technically case-sensitive, virtually no mail server enforces this. Treating User@example.com and user@example.com as different addresses creates duplicate accounts and user confusion. Normalize to lowercase for comparisons.

A Practical Regex Pattern

Here is a regex that balances strictness with real-world compatibility:

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$

What this pattern checks:

1. Local part contains only allowed characters
2. Domain starts and ends with an alphanumeric character
3. Domain labels are separated by dots
4. No label exceeds 63 characters

What this pattern doesn’t check:

• Whether the domain actually exists
• Whether the mailbox is active
• Consecutive dots in the local part (a minor trade-off for simplicity)

For production systems, pair regex validation with DNS lookup and a confirmation email.

Disposable Email Detection

Disposable email services (Mailinator, Guerrilla Mail, Temp Mail, and hundreds more) let users create throwaway addresses. If your application requires a real email for account recovery or communication, you need to detect and block these.

Detection strategies:

1. Domain blocklist: Maintain a list of known disposable email domains. Open-source lists track 10,000+ domains, but new ones appear daily.

2. DNS pattern matching: Many disposable services use newly registered domains with minimal DNS history. Checking domain age and MX record patterns can flag suspicious addresses.

3. API services: Third-party APIs like Kickbox, ZeroBounce, and NeverBounce maintain real-time databases of disposable domains and can verify deliverability.

4. Catch-all detection: Some disposable services accept mail for any address at their domain. Detecting catch-all configurations helps identify these providers.

No single method is foolproof. Combine a domain blocklist with DNS checks for the best balance of accuracy and speed.

Why Email Validation Matters for Businesses

Bad email data costs real money. Here is what happens when validation is skipped:

Bounce rates climb. Email service providers (Mailchimp, SendGrid, Amazon SES) monitor your bounce rate. Exceed 2-5% and your sending reputation drops, pushing legitimate emails to spam folders.

Deliverability suffers. ISPs use sender reputation to decide inbox placement. A list full of invalid addresses signals poor list hygiene, and your emails to valid subscribers start landing in junk.

Costs increase. Most email platforms charge by subscriber count or send volume. Invalid addresses inflate both numbers without generating any value.

Analytics become unreliable. Open rates and click rates are meaningless if a significant portion of your list can’t receive mail. You end up making marketing decisions based on skewed data.

Fraud prevention. In e-commerce and SaaS, fake email addresses are a signal of fraudulent signups. Validating email format and domain reduces bot registrations and abuse.

Multi-Step Validation Workflow

For applications where email quality matters, implement validation in layers:

1. Format check (instant): Regex validation catches typos and obviously malformed addresses. Run this on form submission.

2. Domain check (fast): DNS lookup confirms the domain exists and has MX or A records. This catches misspelled domains like gmial.com or yaho.com.

3. Disposable check (fast): Compare the domain against a blocklist of known disposable email services.

4. Typo suggestion (instant): Common misspellings like @gnail.com, @hotmal.com, or @yaho.com can be detected and corrected with a “Did you mean…?” prompt.

5. Confirmation email (async): Send a verification link. This is the only way to confirm that a real person controls the address.

Each layer catches different problems. Format checks alone miss invalid domains. Domain checks alone miss nonexistent mailboxes. Confirmation emails alone let garbage data into your system before cleanup.

Validate Addresses Instantly

Our Email Validator runs format checks, domain analysis, and disposable email detection in one step. Paste any address and get a detailed breakdown of what passed and what failed.

Frequently Asked Questions

Can an email address contain spaces?

Only inside a quoted local part, like "john doe"@example.com. In practice, no major email provider issues addresses with spaces, and most forms should reject them. If you encounter a quoted local part with spaces, it’s technically valid per RFC 5322 but almost certainly a data entry error.

What is the maximum length of an email address?

The total address can’t exceed 254 characters (RFC 5321). The local part is limited to 64 characters, and the domain part is limited to 253 characters. In practice, most real email addresses are under 50 characters, so hitting these limits is rare.

Should I validate emails on the client side or server side?

Both. Client-side validation (JavaScript regex) gives instant feedback and prevents unnecessary server requests. Server-side validation catches anything that bypasses the client, performs DNS lookups, and checks disposable email lists. Never rely on client-side validation alone because it can be bypassed by disabling JavaScript or submitting requests directly to your API.

Are email addresses case-sensitive?

Technically, the local part (before the @) is case-sensitive per RFC 5321, but almost no mail server enforces this. The domain part is always case-insensitive. In practice, treat the entire address as case-insensitive to avoid creating duplicate accounts. Store addresses in lowercase for consistency.

How often should I re-validate my email list?

Email addresses decay at a rate of roughly 22-30% per year as people change jobs, switch providers, and abandon accounts. Re-validate your list every 3-6 months, and always validate before a major campaign. Remove hard bounces immediately and soft bounces after 3-5 consecutive failures.