What is the maximum length of a valid email address?

According to RFC 5321, the maximum total length of an email address is 254 characters. The local part (before the @) can be up to 64 characters, and the domain part can be up to 253 characters.

Should I use regex to validate email addresses?

Regex is fine for basic format checks (catching obvious typos like missing @ signs), but it should never be your only validation. A fully RFC-compliant regex is impractical and still cannot verify that an email actually exists. Use regex for quick client-side feedback, then verify with DNS/MX and SMTP checks.

What are the most common email validation mistakes?

The most common mistakes are: rejecting valid addresses with overly strict regex (like blocking + aliases or new TLDs), not checking DNS/MX records, not detecting disposable email providers, and treating catch-all domains as fully valid. A multi-layered approach catches issues that any single check would miss.

How does SMTP verification work without sending an email?

SMTP verification connects to the recipient's mail server and begins the SMTP handshake (HELO, MAIL FROM, RCPT TO) but stops before sending any data. The server's response to the RCPT TO command indicates whether the mailbox exists. This verifies deliverability without actually sending a message.

Email Validation Rules: The Complete Guide to Email Address Verification

From RFC syntax standards to SMTP mailbox checks. Everything you need to validate email addresses correctly.

Contents

Email Address Anatomy Syntax Rules Common Pitfalls 5 Levels of Validation Code Examples FAQ

Email Address Anatomy

Every email address follows the same basic structure defined by RFC 5321 (SMTP) and RFC 5322 (Internet Message Format). Understanding this structure is the foundation of proper validation.

user.name+tag @ example.com

Local Part (max 64 chars) Domain (max 253 chars)

Local Part

The portion before the @ sign. Identifies the mailbox on the mail server. Case sensitivity is technically allowed by RFC but almost never enforced in practice.

Domain Part

The portion after the @ sign. Must be a valid hostname with at least one MX or A record. Follows DNS hostname rules (labels separated by dots, each 1-63 chars).

Syntax Rules

The formal rules for what constitutes a valid email address, based on RFC 5321 and RFC 5322.

Local Part Rules

Rule	Details
Allowed characters	`a-z 0-9 . _ % + -`
Maximum length	64 characters
Dot restrictions	No leading dot, no trailing dot, no consecutive dots (`..`)
Plus addressing	`user+tag@domain` is valid and widely supported (Gmail, Outlook, etc.)
Quoted strings	`"user name"@domain` is valid per RFC but rare in practice

Domain Part Rules

Rule	Details
Format	Valid hostname: labels separated by dots (`example.com`)
Maximum length	253 characters total, each label 1-63 characters
TLD requirement	Must have a valid TLD (including new gTLDs like `.company`, `.email`)
International domains	IDN (Internationalized Domain Names) are valid: `user@example.xn--nxasmq6b`
IP address literal	`user@[192.168.1.1]` is valid per RFC but blocked by most providers

Overall Limits

254 characters maximum total length (per RFC 5321 path limit)
Exactly one @ sign separating local part and domain
Case insensitive domain part (always); local part (in practice, though RFC allows case sensitivity)

Common Validation Pitfalls

Most validation bugs come from being either too strict or too lenient. Here are the mistakes we see most often.

Over-strict regex that rejects valid addresses

Many regex patterns reject perfectly valid addresses like o'brien@example.com or user@new-company.email. The full RFC grammar is too complex for a single regex. Keep your pattern loose and validate further downstream.

Not handling plus addressing

Addresses like user+newsletter@gmail.com are valid and commonly used for filtering. Rejecting the + character blocks legitimate users.

Not supporting new TLDs

Hardcoding a list of known TLDs (.com, .org, .net) or limiting TLD length rejects addresses at domains like .company, .technology, or .email. There are over 1,500 valid TLDs.

Ignoring internationalized domains

IDN (Internationalized Domain Names) allow non-ASCII characters in domain names. Addresses with Unicode domains are increasingly common, especially outside the English-speaking world. Your validation should accept or properly convert them via Punycode.

Best practice

Use a permissive regex for instant client-side feedback (catch missing @ signs and obvious typos), then rely on server-side DNS, MX, and SMTP checks for real validation. This gives fast UX without rejecting legitimate addresses.

Beyond Syntax: The 5 Levels of Email Validation

Checking syntax is just the beginning. A fully valid-looking email can still bounce, belong to a disposable provider, or be a catch-all that accepts anything. Here are the five levels of validation, from basic to comprehensive.

Syntax / Format Check

Validates the string matches the email address format. Catches typos like missing @ signs, double dots, and invalid characters.

Catches: typos, malformed strings Misses: fake domains, nonexistent mailboxes

DNS / MX Record Lookup

Queries DNS for MX records to confirm the domain can receive mail. A domain without MX records cannot accept email.

Catches: fake/nonexistent domains Misses: nonexistent mailboxes on valid domains

SMTP Verification

Connects to the mail server and checks if the specific mailbox exists without sending an actual email. This is the critical differentiator between basic and professional validation.

Catches: nonexistent mailboxes, deactivated accounts Misses: disposable providers, catch-all servers

Disposable Email Detection

Checks the domain against a database of known disposable/temporary email providers (Guerrilla Mail, Mailinator, etc.). These addresses are typically used to bypass signup requirements.

Catches: throwaway signups, fraud attempts

Catch-All Detection

Identifies domains configured to accept mail for any address (catch-all servers). These domains always return "valid" for SMTP checks, so individual mailbox existence cannot be confirmed.

Catches: false positives from catch-all domains

What Each Level Catches

Check	Format Errors	Fake Domains	Dead Mailboxes	Disposable	Catch-All
Syntax
DNS / MX
SMTP
Disposable DB
Catch-All

MailOdds covers all 5 levels

A single API call performs syntax checks, DNS/MX lookups, SMTP mailbox verification, disposable email detection, and catch-all detection. No need to chain multiple services. Learn more

Code Examples

Here is a basic regex approach in JavaScript and Python, followed by how to get comprehensive validation with a single API call.

Basic Regex (JavaScript)

A simple pattern that catches obvious format errors without being overly strict.

JavaScript

function isValidEmail(email) {
  const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return pattern.test(email);
}

// Catches obvious errors
console.log(isValidEmail('user@example.com'));   // true
console.log(isValidEmail('not-an-email'));      // false
console.log(isValidEmail('user+tag@mail.co')); // true (correct!)

Basic Regex (Python)

Python

import re

def is_valid_email(email: str) -> bool:
    pattern = r'^[^\s@]+@[^\s@]+\.[^\s@]+$'
    return bool(re.match(pattern, email))

print(is_valid_email('user@example.com'))   # True
print(is_valid_email('not-an-email'))      # False

Regex only catches format errors

fake@nonexistent-domain-xyz.com passes any regex check. To verify the domain exists and the mailbox is active, you need DNS, MX, and SMTP checks.

Full Validation with MailOdds API

One API call performs all 5 levels of validation: syntax, DNS, SMTP, disposable, and catch-all.

cURL

curl -X POST https://api.mailodds.com/v1/validate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '"email": "user@example.com"'

Response (JSON)

{
  "email": "user@example.com",
  "status": "valid",
  "action": "accept",
  "reason": "Mailbox exists and is deliverable",
  "disposable": false,
  "role_account": false,
  "free_provider": false
}

Frequently Asked Questions

Skip the complexity

One API call performs all 5 levels of email validation. Start with 1,000 free validations. No credit card required.

Start Free Try the Free Validator