What this validator checks
Addresses are validated against the Mailbox syntax of RFC 5321 (the rules SMTP servers apply), including quoted local parts, address literals such as [192.0.2.1] and the length limits of 64 characters for the local part and 254 for the whole address.
Internationalized addresses are supported: non-ASCII local parts (RFC 6531, SMTPUTF8) are flagged because not every system accepts them, and Unicode domains are converted to their ASCII form (Punycode). We also suggest corrections for common typos in popular mailbox domains.
Optionally, you can check the domain’s DNS to see whether it accepts mail at all (MX records, implicit MX or null MX).
Limitations
- A valid format does not mean the mailbox exists. Only the receiving server knows that, and probing it over SMTP is unreliable (catch-all domains, greylisting) and gets your IP address blocked, so we do not do it.
- Syntax validation runs in your browser; addresses are not sent anywhere. The optional domain check sends only the domain part.
Frequently asked questions
If an address is valid here, will email to it be delivered?
Not necessarily. Valid syntax means the address can exist. The mailbox may still be missing, full or disabled, and the domain may not accept mail. Use the domain check for the latter; only a real message (or a confirmation email) proves the former.
Why don’t you check mailboxes over SMTP?
Many servers accept every recipient (catch-all) or delay unknown senders, so the answer is often wrong. Repeated probing also looks like a directory harvest attack and gets the probing server blocked. A double opt-in confirmation is the reliable method.
Are quoted addresses and IP literals real?
They are valid under the standard, for example "john smith"@example.com or user@[192.0.2.1], but rare. Many websites and services reject them, so we accept them with a warning.
Can an email address contain non-English letters?
Yes. Domains can use Unicode (IDN) everywhere. Local parts with non-ASCII characters require SMTPUTF8 support (RFC 6531) on every server involved, which is common at large providers but not universal.
Is the part before the @ case-sensitive?
The standard allows servers to treat it as case-sensitive, but virtually all providers ignore case. Store addresses as entered and compare them case-insensitively.