Free Email Address Validator

What counts as a valid email address

An email address is two parts joined by an `@`: a local-part on the left, a domain on the right. Most people stop there, but the formal grammar in RFC 5322 is more permissive than people expect, and the SMTP envelope grammar in RFC 5321 is stricter. The address you can put in a message header is not always the address you can use in an SMTP `RCPT TO`.

Knowing what the standards actually allow saves time. Half the regex you see in blog posts rejects valid addresses (`'O\'Brien'@example.com` parses fine under 5322). The other half accepts garbage (`foo@@bar` does not). A proper validator follows the grammar instead of guessing.

The two RFCs that matter

RFC 5322 — Internet Message Format

Defines what an address looks like when it appears in a message header (`From:`, `To:`, `Cc:`). Permissive. Allows quoted strings, comments in parentheses, IP-literal domains in square brackets, and the various atom and dot-atom forms for the local-part.

Examples of legal RFC 5322 addresses that look weird but parse fine:

• `"john doe"@example.com` — quoted local-part with a space inside.
• `user+tag@example.com` — plus-addressing for filtering.
• `user@[192.168.1.1]` — IP-literal domain.
• `user.name@example.co.uk` — multi-label domain.
• `user@subdomain.example.com` — subdomain in the domain part.

RFC 5321 — SMTP envelope

Defines what an address looks like inside the SMTP transaction. Stricter than 5322. The envelope grammar disallows some of the rarer header forms. In practice, modern mail servers accept addresses that follow either grammar, but the envelope version is what gets evaluated during delivery.

The constraint that bites most often: local-part length capped at 64 octets, total address capped at 254 octets in the SMTP envelope. Anything longer will get rejected at submission time even if it looks valid.

Internationalised email (EAI / SMTPUTF8)

Until 2012, email addresses were ASCII only. RFCs 6530, 6531, and 6532 introduced Email Address Internationalisation (EAI), allowing UTF-8 characters in both the local-part and the domain. Addresses like `测试@例子.中国` and `владимир@пример.рф` became technically legal.

Support is patchy. The sending server, every relay along the path, and the receiving server all have to advertise the SMTPUTF8 extension. Major providers (Gmail, Outlook, Yandex) accept and deliver to internationalised addresses, but adoption among self-hosted mail servers and corporate gateways is still uneven as of 2026.

For domains, the related standard is Internationalised Domain Names (IDN), defined in RFC 5891. An IDN domain like `münchen.de` gets encoded as Punycode (`xn--mnchen-3ya.de`) at the DNS layer. A good validator either accepts both forms or transparently converts between them.

Common email address mistakes

Patterns that come up repeatedly in form data and imported lists:

• Trailing whitespace or zero-width characters pasted from chat apps. Strip these before validation.
• Leading or trailing dots in the local-part. Disallowed by both 5321 and 5322 in the unquoted form.
• Consecutive dots in the local-part (`john..doe@example.com`). Same issue.
• Spaces in the local-part without quotes. Quoted forms are legal but rarely supported in real mail systems.
• Multiple @ signs without quoting. Easy to catch in syntax validation.
• Single-label domains (`user@localhost`). Legal on internal networks but not for public mail.
• TLDs that look real but are not. `.web`, `.email`, and `.app` are all legitimate; `.con` is not.

Most of these get caught by a proper syntax check. For the rest, a domain lookup and MX query confirm the right side of the address actually resolves to a mail server. Our Email Syntax Checker handles bulk validation against RFC 5322; the full verifier adds DNS and SMTP layers.

Role-based addresses (RFC 2142)

RFC 2142 defines a set of standard role names that domains operating mail are expected to accept. The canonical list:

A validator flags role accounts not because they are invalid (they are perfectly valid) but because they behave differently than personal mailboxes. Multiple people read them, ownership rotates, replies often go nowhere, and recipients did not personally sign up so spam-complaint rates run higher.

Context matters. A B2B prospect at `info@` is often the right contact at a small business. A consumer newsletter signup at `noreply@` is almost certainly a tester or bot.

Disposable email detection

Disposable email services give users a temporary, often anonymous address that exists for minutes or hours before disappearing. The list includes 10minutemail, mailinator, guerrillamail, temp-mail, yopmail, and hundreds of smaller providers. Addresses are syntactically valid, technically deliverable, and almost never read by a real person.

Detection works by maintaining a list of disposable domains and checking the right-hand side of the address against it. Good lists update daily because disposable services constantly rotate domain names to evade blocking. Some validators also detect patterns: throwaway services often use newly-registered domains with no MX history, or domains that share IPs with other disposable services.

Whether to block disposable signups depends on the service. A free trial that gives away product credits should block them. A community forum or blog newsletter usually should not — users have legitimate privacy reasons for using disposable addresses, and blocking them costs sign-ups for marginal abuse reduction.

Plus-addressing and aliasing

Plus-addressing (`user+tag@example.com`) is a Gmail convention adopted by most major providers. The `+` and everything after it up to the `@` is ignored for delivery purposes, so `alice+newsletter@gmail.com` arrives in `alice@gmail.com`. People use it to filter, to track which services leaked their address, and to create per-vendor unique signups without registering new mailboxes.

A validator should accept plus-addressed forms. Stripping the `+tag` before validation is fine if you want to detect duplicates; rejecting them outright is wrong. Some companies block plus-addressing assuming it is a workaround for one-account-per-user limits. That is a usability problem worth pushing back on.

Subaddressing variants

Plus-addressing is the dominant convention but not the only one. Fastmail and a few other providers support `user-tag@example.com` (hyphen as separator). Microsoft has tested `user+tag@outlook.com` and `user.tag@outlook.com` at various points. If you build alias logic, be aware that the separator depends on the receiving server, not the standard.

Length limits

• Local-part: 64 octets maximum (RFC 5321).
• Domain: 255 octets maximum, with each label up to 63 octets (RFC 1035).
• Whole address in SMTP envelope: 254 octets maximum.
• Header forms have their own line-length limits but addresses themselves are capped at the values above.

Most validators enforce these caps. Forms that accept addresses without length checks will sometimes have UI fields that allow more than the SMTP layer can carry, so the address validates client-side and bounces on send. Set the input maxlength to 254 to avoid surprises.

Validating beyond syntax

Format validation is the first layer. To know whether mail will actually reach the address, you need to confirm the domain exists, has MX records, and accepts the specific mailbox over SMTP. Each of those is a separate check with its own latency and reliability profile.

Valid Email Checker runs the full pipeline through the email verifier. For domain-level checks, the MX Record Checker and DNS Lookup tool cover the DNS layer. For the SMTP layer, the verifier opens a real handshake with the recipient mail server and reports back what happened.

When to use a syntax-only check

• Client-side form validation where you want instant feedback without a network round-trip.
• Sanitising a paste of data before further processing. Reject anything that fails syntax before spending budget on SMTP checks.
• Bulk filtering of an exported list to drop obvious garbage before running real verification.
• Educational or debugging purposes — figuring out why a particular address parses or fails.

For everything else, run the full verification. Syntax is necessary but not sufficient. A perfectly formed address at a non-existent domain still bounces.