Email Validator

What this validates

Format only, does the email match RFC 5321/5322 syntax rules? It does NOT check whether the email exists, accepts mail, or has valid DNS. For deliverability validation, use a service like NeverBounce, ZeroBounce, or Verifalia.

What the validator catches:

• Missing or misplaced @: foo, @gmail.com, foo@
• Empty local or domain: @gmail.com, foo@
• Length violations: local part >64 chars, total >254 chars
• Invalid characters: spaces, brackets, control chars in unquoted form
• Edge dots: [email protected], [email protected], [email protected]
• No TLD: foo@bar
• Malformed domain: trailing hyphens, consecutive dots, etc.

Typo suggestions

For valid-format emails with suspicious domains, the validator suggests corrections. The most common typos:

• gmial.com → gmail.com
• gmal.com → gmail.com
• yaho.com → yahoo.com
• hotmial.com → hotmail.com
• outlok.com → outlook.com
• iclou.com / icould.com → icloud.com
• gmail.con → gmail.com (.con typo)

The suggestion uses Levenshtein distance against a list of the 10 most common email providers. If the user’s domain is within 2 character edits of a common one, the validator suggests the correction.

Bulk mode

The textarea accepts emails one-per-line OR comma-separated. The validator processes each independently and shows a colored dot (green = valid, red = invalid) plus the failure reason or typo suggestion.

The summary at the top counts valid vs invalid for quick scanning of large lists.

What this doesn’t catch

• Domains that don’t exist: [email protected] looks valid but isn’t deliverable. Format-only validation can’t detect this.
• Disposable email addresses: [email protected] is valid format. To filter throwaway emails, you need a database of known disposable domains.
• Mailbox exists checks: requires actually pinging the SMTP server, out of scope here.
• Unicode email addresses: RFC 6531 internationalized email isn’t validated by this tool. Most ASCII addresses pass through fine.

When to use this

• Form-input validation during data entry. Catches typos before they hit your database.
• Cleaning email lists before importing into a CRM or marketing tool.
• Deduplication input check: format-validate before normalizing case for dedup.
• API request validation: check before billing a verification API call.

For high-stakes use cases (avoiding bounce-back, paying for verified emails), pair this with a real-time deliverability check service.

Frequently asked questions

Why does my email say “invalid characters” but it works fine? RFC 5321 is strict; real-world email is permissive. Some providers accept addresses with unusual characters (apostrophes, plus-tagged addresses with weird local parts). The validator follows the strict spec, emails it rejects might still work in production.

What’s a “typo suggestion” doing if my email is valid? Format-valid emails can still be typos. [email protected] is RFC-valid but probably the user meant gmail.com. The suggestion catches this.

Can I validate against my own domain whitelist? Not in this version. For domain restrictions (only accept @yourcompany.com), filter the validation results manually after the format check.

Why doesn’t the validator check MX records? MX checks require DNS lookups, which aren’t possible from a browser tool. Use a server-side validator or a paid API for that level of verification.