How to Validate an Email Address Free — Format Checker (2026)

You can validate email addresses and detect common typos in your browser using brevio Email Validator — validation runs entirely client-side with no DNS lookup. No data is sent anywhere.

Email Address Format Rules

A valid email address has the form local-part@domain. The rules come from RFC 5321 (SMTP) and RFC 5322 (message format).

Local Part Rules (before @)

• Maximum 64 characters.
• Allowed characters: letters (a–z, A–Z), digits (0–9), and these special characters: ! # $ % & ' * + - / = ? ^ _ ` { | } ~ .
• Dots are allowed but cannot appear at the start, end, or consecutively (user..name is invalid).
• Quoted strings are technically allowed ("user name"@example.com) but almost universally rejected by mail servers in practice.

Domain Rules (after @)

• Maximum 255 characters total (including the @).
• Must contain at least one dot.
• Each label (segment between dots) is 1–63 characters.
• Labels contain letters, digits, and hyphens — but cannot start or end with a hyphen.
• The TLD (last label) must be at least 2 characters (.io, .com, .museum).

Common Validation Mistakes

• Overly strict regex. Many popular email validation regex patterns reject valid addresses. The “correct” RFC 5322 regex is hundreds of characters long and still does not cover all edge cases. A simple check for an @, a domain with at least one dot, and reasonable character constraints catches 99.9% of invalid addresses without false positives.
• Blocking subaddress suffixes. Many email providers support plus-addressing (user+tag@gmail.com). Stripping the +tag part or rejecting the address is a mistake — the full address is valid and deliverable.
• Rejecting new TLDs. ICANN has added hundreds of new TLDs (.app, .dev, .io, .photography). Validation that checks against a fixed TLD list will incorrectly reject valid addresses.
• Trusting validation as confirmation of delivery. A syntactically valid email address may still not exist or may be undeliverable. Validation only confirms format — it does not confirm the mailbox exists.

Why Client-Side Validation Is Not Enough for Production

Client-side validation catches obviously invalid addresses (missing @, spaces, etc.) and improves user experience by providing immediate feedback. It is not sufficient for production applications because:

• It cannot verify the domain has MX records (mail exchange servers).
• It cannot verify the mailbox exists at that domain.
• It can be bypassed by disabling JavaScript or calling the API directly.
• It does not detect disposable email addresses or known spam domains.

For production, combine client-side format validation with a confirmation email flow (send a link and require the user to click it). For high-value cases, add server-side MX record lookup using a DNS resolution library.

Common Typos to Watch For

The most frequent email typos in production data:

• gamil.com, gmial.com → gmail.com
• yhaoo.com, yahooo.com → yahoo.com
• hotmial.com, hotmal.com → hotmail.com
• outlok.com, outloot.com → outlook.com

The brevio validator checks against these common typos and suggests the corrected domain when detected.

Email Validation in Different Languages

Internationalised domain names (IDN) — domains using non-ASCII characters — are technically valid in email addresses but require Punycode encoding for SMTP transport. For example, user@münchen.de is encoded as user@xn--mnchen-3ya.de for actual delivery. Most validation libraries handle this transparently, but simple regex-based validators will reject IDN addresses.