Email Syntax Validation: RFC Rules, Edge Cases, and Best Practices

Email syntax validation is the first stage of email verification — a fast, network-free check that catches structurally invalid addresses before any DNS or SMTP lookup is attempted. It costs nothing to run, requires no external calls, and can eliminate a significant share of bad data at the point of entry. Understanding exactly what the rules are — and where they get complicated — is essential for building validators that are both strict enough to catch garbage and permissive enough to accept legitimate addresses.

The Structure of an Email Address

Every email address has two parts separated by a single @ symbol: the local part on the left and the domain part on the right. The full address must not exceed 254 characters (per RFC 5321), and the local part alone must not exceed 64 characters. The domain part must be a valid hostname — a series of labels separated by dots, each label between 1 and 63 characters, with the full domain not exceeding 253 characters.

RFC 5321 governs the SMTP protocol and defines what mail servers must accept. RFC 5322 governs the message format and defines what is valid in the From and To headers. The two standards overlap but are not identical — RFC 5322 is slightly more permissive in some areas. For practical validation purposes, RFC 5321 is the more relevant standard because it defines what mail servers will actually process.

What RFC 5321 and RFC 5322 Require

In the local part, the following characters are explicitly allowed without quoting: alphanumeric characters (a–z, A–Z, 0–9), and the special characters . ! # $ % & ' * + - / = ? ^ _ ` { | } ~. Dots are allowed but cannot appear at the start, at the end, or consecutively (..). The plus sign (+) and hyphen (-) are valid and widely used for subaddressing and filtering.

The local part can also be a quoted string — the entire local part wrapped in double quotes — which allows spaces, @ signs, and other characters that would otherwise be invalid. Quoted local parts are technically valid per RFC 5321 but are rarely used in practice and many mail servers do not support them.

For the domain part, each label must start and end with an alphanumeric character. Hyphens are allowed in the middle but not at the start or end of a label. The top-level domain (TLD) must be at least two characters. Internationalized domain names (IDN) — domains using non-ASCII characters — are encoded in Punycode for DNS purposes (e.g., münchen.de becomes xn--mnchen-3ya.de). Validators that do not handle Punycode will incorrectly reject valid IDN addresses.

Common Syntax Errors

The most frequent syntax errors fall into a handful of categories:

Edge Cases That Trip Up Most Validators

Several valid address formats are commonly rejected by naive validators:

Plus addressing ([email protected]) is widely used for filtering and tracking. The + character is explicitly allowed in the local part. Many validators incorrectly reject it.

Quoted local parts ("user name"@domain.com) are valid per RFC 5321. The quotes allow spaces and other special characters inside the local part. Most validators do not implement quoted string parsing and will reject these addresses.

IP address domains (user@[192.168.1.1]) are valid per RFC 5321. The domain part can be an IP address literal enclosed in square brackets. These are rare in practice but technically valid.

Long TLDs like .photography, .international, or .technology are valid ICANN-registered TLDs. Validators that only accept two- or three-character TLDs will reject them.

Subdomains ([email protected]) are perfectly valid. The domain part can have any number of labels. Validators that only accept a single dot in the domain will reject these.

Why Regex Is Not Enough

A regex can check whether an address matches a structural pattern, but it cannot determine whether the address is actually deliverable. A syntactically valid address like [email protected] will pass any regex but will bounce immediately because the domain does not exist. Conversely, an overly strict regex will reject valid addresses like [email protected].

Here is a reasonably robust regex pattern that handles the common cases without being so strict that it rejects valid addresses:

// Covers most real-world addresses. Does NOT handle quoted local parts or IP literals.
const EMAIL_REGEX = /^[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])?)*\.[a-zA-Z]{2,}$/

// Caveats:
// - Does not validate local part length (max 64 chars)
// - Does not validate total address length (max 254 chars)
// - Does not handle quoted strings in local part
// - Does not handle IP address domain literals
// - Does not check whether the domain actually exists (use DNS for that)

Syntax validation is only the first step. To know whether an address is actually deliverable, you need to check DNS records and attempt an SMTP handshake. For a complete walkthrough of the full pipeline, see our guide to how email verification works. For an existing file, use Peopledat's bulk verification workflow.

Syntax Validation in Practice

Apply syntax validation at every point where email addresses enter your system: signup forms, CSV imports, API inputs, and webhook payloads. Client-side validation (in the browser) provides immediate feedback to users and reduces server load. Server-side validation is mandatory — client-side checks can always be bypassed.

For signup forms, a lightweight regex check on blur (when the user leaves the field) gives instant feedback without being intrusive. For bulk imports, run syntax validation as the first filter before any network-based checks — it is cheap and eliminates addresses that would fail anyway.

For production sending, syntax validation alone is not sufficient. You should also verify that the domain has valid MX records and that the mailbox accepts connections. The SMTP email verification process covers these deeper checks and provides more evidence for a pre-send decision, without guaranteeing delivery.

Valid and Invalid Examples

The following table illustrates common valid and invalid addresses with explanations: