Pre-flighting a list of email addresses before piping it into a paid validation API or mass-mailer (catches typos for free, saves credits). Building a signup form that rejects obvious garbage at the field level. Auditing a CSV of contacts to find typos before importing. Checking whether an address that "looks weird" (international TLD, plus-addressing, sub-addressing) is actually allowed.

Syntactically valid ≠ deliverable. does-not-exist@gmail.com passes every structural check. Real verification needs the MX server's response. Use this as a first-line filter, not a confidence signal. Plus addressing is allowed. name+tag@gmail.com is valid and routes to name@gmail.com — don't strip it; it's a feature. Internationalised email (IDN). 用户@例.中国 is technically valid per RFC 6530 but not yet broadly supported by SMTP servers. This tool follows the conservative ASCII rules; loosen if you genuinely need IDN. Disposable-domain detection is hint-only. The list is necessarily incomplete and any flagged domain might still be a real user. Don't reject case differences. Local parts are technically case-sensitive per RFC 5321; in practice every modern provider treats them as case-insensitive. Don't lowercase in storage.

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" are a one-line regex that approves not@an.email and rejects edge@case.io. This tool runs the structural checks RFC 5321 / 5322 actually require — local part charset, dot rules, label lengths, TLD shape, hard length limits — plus a disposable-domain hint. It tells you whether an address is well-formed; it doesn't tell you whether the mailbox exists (that needs a server-side MX/SMTP probe).

When to use it

Pre-flighting a list of email addresses before piping it into a paid validation API or mass-mailer (catches typos for free, saves credits).
Building a signup form that rejects obvious garbage at the field level.
Auditing a CSV of contacts to find typos before importing.
Checking whether an address that "looks weird" (international TLD, plus-addressing, sub-addressing) is actually allowed.

Common gotchas

Syntactically valid ≠ deliverable. does-not-exist@gmail.com passes every structural check. Real verification needs the MX server's response. Use this as a first-line filter, not a confidence signal.
Plus addressing is allowed. name+tag@gmail.com is valid and routes to name@gmail.com — don't strip it; it's a feature.
Internationalised email (IDN). 用户@例.中国 is technically valid per RFC 6530 but not yet broadly supported by SMTP servers. This tool follows the conservative ASCII rules; loosen if you genuinely need IDN.
Disposable-domain detection is hint-only. The list is necessarily incomplete and any flagged domain might still be a real user.
Don't reject case differences. Local parts are technically case-sensitive per RFC 5321; in practice every modern provider treats them as case-insensitive. Don't lowercase in storage.