Pre-flighting bulk email lists before sending to a paid validation service or mass-mailer; catch obvious typos for free and save API credits. Building client-side validation for signup forms that need to reject garbage input at the field level, before submission. Auditing a CSV or database export of contact addresses to find malformed entries, typos, or truncation before import or merge. Checking whether an address that looks suspicious — international TLD, plus-addressing, subdomain routes — is actually permissible under the standards. Debugging email delivery issues by confirming the address is well-formed before investigating server-side or DNS problems. User research: testing whether your application's email acceptance rules match RFC compliance, or identifying where your validation is either too strict or too lenient.

Local-part analysis. Checks character set (ASCII letters, digits, and allowed special chars), enforces dot rules (no leading/trailing/consecutive dots), and verifies length ≤ 64 octets. Domain analysis. Validates label syntax (hyphen rules, length ≤ 63 chars per label), checks TLD shape (must have at least one dot, no all-numeric TLDs), and enforces maximum domain length of 255 octets. Overall length. The full address must not exceed 320 characters (practical limit, though RFC 5321 allows up to 254 for the local part and 255 for the domain). Disposable-domain flagging. Compares the domain against a curated list of known temporary-email providers and notes matches as a hint — not a hard rejection. Character encoding. Runs all checks in ASCII (RFC 5321 conservative mode). Internationalised domains (IDN) are noted as technically valid per RFC 6530 but flagged as unsupported by most SMTP infrastructure.

Valid syntax ≠ deliverable address. user@example.com may pass every structural rule but the mailbox might not exist. This tool is a first-line filter; real verification requires an MX lookup and SMTP dialogue with the receiving server. Disposable-domain detection is incomplete. The flagged list is maintained but never exhaustive. A domain flagged as temporary may still belong to a legitimate user, and unlisted disposable services exist. Treat flags as a hint, not a veto. Plus-addressing is valid and useful. user+tag@gmail.com is syntactically correct and intentional — it routes to user@gmail.com with metadata. Do not strip or reject the plus sign; it's a feature, not a typo. Case sensitivity is technical, not practical. RFC 5321 says the local part is case-sensitive; in reality, every major mail provider treats it as case-insensitive. Never lowercase addresses in storage, but do not reject on case differences. Internationalised email (IDN) is permitted but not universally supported. Addresses like 用户@例.中国 are valid under RFC 6530 but many SMTP systems do not yet handle them. This tool follows conservative ASCII rules; if you need full IDN support, loosen the constraints yourself.

Email Validator

Check whether an email address is syntactically valid (RFC 5322 friendly), with breakdown of local part, domain, and common pitfalls.

Email address

Or paste a list (one per line) below to bulk-check.

Result

Enter input above to see the result.

What is this for?

Most email validators rely on a single regex pattern that either over-accepts (flagging typos as valid) or over-rejects (blocking legitimate edge cases). This tool applies the actual structural rules from RFC 5321 and RFC 5322: character set restrictions on the local part, dot placement rules, label length caps, TLD format constraints, and hard length limits across the entire address. It also flags disposable-domain providers so you can warn users upfront. The result: you get a pass/fail verdict and a detailed breakdown of why an address succeeds or fails — without needing to hit a paid validation API or wait for SMTP probes.

When to use it

Pre-flighting bulk email lists before sending to a paid validation service or mass-mailer; catch obvious typos for free and save API credits.
Building client-side validation for signup forms that need to reject garbage input at the field level, before submission.
Auditing a CSV or database export of contact addresses to find malformed entries, typos, or truncation before import or merge.
Checking whether an address that looks suspicious — international TLD, plus-addressing, subdomain routes — is actually permissible under the standards.
Debugging email delivery issues by confirming the address is well-formed before investigating server-side or DNS problems.
User research: testing whether your application's email acceptance rules match RFC compliance, or identifying where your validation is either too strict or too lenient.

How it works

Local-part analysis. Checks character set (ASCII letters, digits, and allowed special chars), enforces dot rules (no leading/trailing/consecutive dots), and verifies length ≤ 64 octets.
Domain analysis. Validates label syntax (hyphen rules, length ≤ 63 chars per label), checks TLD shape (must have at least one dot, no all-numeric TLDs), and enforces maximum domain length of 255 octets.
Overall length. The full address must not exceed 320 characters (practical limit, though RFC 5321 allows up to 254 for the local part and 255 for the domain).
Disposable-domain flagging. Compares the domain against a curated list of known temporary-email providers and notes matches as a hint — not a hard rejection.
Character encoding. Runs all checks in ASCII (RFC 5321 conservative mode). Internationalised domains (IDN) are noted as technically valid per RFC 6530 but flagged as unsupported by most SMTP infrastructure.

Common gotchas

Valid syntax ≠ deliverable address. user@example.com may pass every structural rule but the mailbox might not exist. This tool is a first-line filter; real verification requires an MX lookup and SMTP dialogue with the receiving server.
Disposable-domain detection is incomplete. The flagged list is maintained but never exhaustive. A domain flagged as temporary may still belong to a legitimate user, and unlisted disposable services exist. Treat flags as a hint, not a veto.
Plus-addressing is valid and useful. user+tag@gmail.com is syntactically correct and intentional — it routes to user@gmail.com with metadata. Do not strip or reject the plus sign; it's a feature, not a typo.
Case sensitivity is technical, not practical. RFC 5321 says the local part is case-sensitive; in reality, every major mail provider treats it as case-insensitive. Never lowercase addresses in storage, but do not reject on case differences.
Internationalised email (IDN) is permitted but not universally supported. Addresses like 用户@例.中国 are valid under RFC 6530 but many SMTP systems do not yet handle them. This tool follows conservative ASCII rules; if you need full IDN support, loosen the constraints yourself.