RFC 5322 Email Validator

Validate email addresses in bulk against a practical RFC 5322 subset — checking local-part syntax, domain labels, length limits (local ≤ 64, domain ≤ 255, total ≤ 254), and IPv4/IPv6 literals. Each invalid address gets a specific failure reason, not just a boolean.

How to use the RFC 5322 Email Validator

Paste one email address per line into the text area and click Validate. The tool parses each address against a practical RFC 5322 subset and returns a table with three columns: the address, a Valid/Invalid verdict, and — for invalid addresses — a specific reason explaining which rule failed.

The parser splits each address at the last @ sign. The part before is the local-part; the part after is the domain. It accepts two forms of local-part: a dot-atom (printable ASCII atext characters, no leading/trailing/consecutive dots) and a quoted string (anything between double-quotes, with \ as an escape). The domain may be a hostname (dot-separated labels, each 1–63 characters, using letters/digits/hyphens, not starting or ending with a hyphen, with at least one dot forming a TLD) or an IP literal in brackets like [192.0.2.1] or [IPv6:::1].

Length limits are enforced: local-part ≤ 64 characters, domain ≤ 255 characters, whole address ≤ 254 characters. These are the limits from RFC 5321 (SMTP) that complement RFC 5322's format rules. Note that syntax validity does not imply deliverability — a syntactically valid address may still bounce.

RFC 5322 email validation explained

RFC 5322 (Internet Message Format, 2008) defines the syntax for email addresses as used in message headers. It superseded RFC 2822, which superseded RFC 822. The standard is famously complex — the full grammar allows comments in parentheses, folding whitespace, and quoted strings almost anywhere — making a fully conformant parser surprisingly large. In practice, nearly all real-world addresses use the simpler dot-atom form (local@domain) or, less commonly, a quoted local-part ("first last"@domain). This tool implements that practical subset, which covers the vast majority of real addresses while remaining explainable and predictable.

The local-part allows the characters defined as atext in the spec: letters, digits, and the symbols !#$%&'*+/=?^_`{|}~-. Dots are allowed as separators but not at the start, end, or adjacent to each other. The domain portion uses standard DNS label rules: each label is 1–63 characters of letters, digits, and hyphens, must not start or end with a hyphen, and the full domain must contain at least one dot (so it has a TLD). IPv4 literals like [192.0.2.1] and IPv6 literals like [IPv6:2001:db8::1] are also valid domain forms.

Common misconceptions: + is valid in the local-part (Gmail uses it for aliases); consecutive dots are not valid in a dot-atom local-part even though some mail servers accept them; the maximum length of the entire address is 254 characters (not 256 as sometimes stated), per the errata to RFC 3696. Syntax validation is a necessary but not sufficient check — MX record lookup and SMTP probing are needed to confirm deliverability.

Common use cases

• Registration form validation — Implement server-side format checking that catches malformed addresses before an SMTP send attempt.
• CRM import hygiene — Bulk-validate an exported list to identify badly-formatted records before an email campaign.
• API response auditing — Verify that addresses returned by a third-party enrichment API conform to the format your mail stack expects.
• QA test coverage — Generate and validate edge-case addresses (quoted strings, IP literals, long domains) to ensure your own validator handles them correctly.
• Data migration — Scrub email fields during a database migration to a new platform that has stricter address validation.