Free Email Syntax Checker

What email syntax validation actually checks

Email syntax validation is the structural check on an address: does the format match what an email address is allowed to look like? Think of it as the spell-check for emails — it catches things like `kevin@@gmail.com` (two @ signs), `kevin..smith@x.com` (consecutive dots), and `kevin@gmail.con` (`.con` is not a real TLD) before they reach your mail server or your CRM.

Syntax validation does NOT check whether the mailbox exists, whether mail will actually deliver, or whether someone is reading it. For that, you need our email verifier — it opens a real SMTP conversation with the recipient mail server. Syntax checking is the cheap, fast first pass. Verification is the expensive but conclusive second pass.

Why a one-line regex isn't enough

You'll find code snippets all over Stack Overflow that look like this:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

That regex accepts `kevin@@gmail.com` (passes — has @ and a dot), accepts `kevin@gmail.con` (passes — looks fine structurally), and accepts `@gmail.com` (only fails some implementations). It's good enough for a quick sanity check, but it misses the actual errors users make.

Real validation needs to handle: local part length limits (64 chars max per RFC 5321), domain length limits (253 chars), specific character rules per provider (Gmail allows only dots, Outlook allows three separators), and edge cases like quoted local parts (`"hello world"@x.com` — technically valid, almost never used).

The four strictness levels, explained

Different use cases need different rules. The dropdown lets you switch between four:

HTML5 (browser-default)

Matches the validation that `<input type="email">` does in Chrome, Firefox, Safari. The most permissive of the four. Use this when you want your tool to flag exactly what a typical signup form would flag — no more, no less.

RFC 5322 practical (recommended)

What real mail servers accept in everyday operation. Slightly stricter than HTML5 — for example, it doesn't accept the exotic characters HTML5 allows like `!#$%&'`. The right choice when you want to know whether an address will actually work in practice.

RFC 5322 strict

Full RFC 5322 grammar. Accepts quoted local parts (`"with spaces"@x.com`) and IP-literal domains (`user@[192.168.1.1]`). These are technically valid but almost never seen in the wild. Use this when spec compliance matters more than practical deliverability — building an email parser, validating data in a research dataset, that kind of work.

Gmail-specific

Gmail's own rules: 6-30 characters in the local part, only letters/digits/dots, no consecutive dots, no leading or trailing dot, and the domain has to be `gmail.com` or `googlemail.com`. Use this when you want to reject any address that isn't a properly-formatted Gmail address (including addresses at other providers).

Provider-specific rules we enforce on top

Strictness levels handle the general syntax rules. But every major provider also has its own character restrictions that the RFC doesn't enforce. We layer those on top automatically — so `kwart-sonuel@gmail.com` is flagged as invalid in every strictness mode, because Gmail doesn't accept dashes in the local part even though the RFC does.

Here's what we enforce per provider:

How our typo detection works

When you mistype `gmail.com` as `gmial.com` or `gmail.con`, the result is technically a valid email address — it just goes to a domain that doesn't exist or hits the wrong inbox. A pure syntax check passes it.

Our typo detector uses Damerau-Levenshtein edit distance against a list of the 50 most common email providers worldwide. It catches:

• Single-character substitutions — `gmail.con` (1 edit from `gmail.com`)
• Single-character insertions — `gmaill.com` (1 edit)
• Single-character deletions — `gmal.com` (1 edit)
• Adjacent transpositions — `gmial.com` (1 edit, the swap of `i` and `m`)
• Two-edit corrections for longer domains — `hotmial.com` → `hotmail.com`

We don't suggest corrections for short ambiguous strings (`a@b.com` is 4 edits from `gmail.com` but obviously not a typo of it) or for domains that already look intentional (`acme.io`, `mycompany.net`). The bar is intentionally conservative — false suggestions are worse than missed ones because they teach users to ignore the warning.

Syntax checker vs email verifier — when to use which

These two tools answer different questions, and confusing them is the most common mistake in email-list hygiene.

Practical rule: run new addresses through the syntax checker first, then the verifier. Syntax checking is free and instant; verifying costs API quota. Catching invalid syntax cheaply saves verifier credits for the addresses that actually need them.

Five email syntax mistakes you should reject early

1. Consecutive dots in the local part. `kevin..smith@x.com` is invalid per RFC 5322 §3.4.1, but a lot of homegrown regexes let it through. Gmail explicitly rejects it. So do most major providers.

2. TLD typos. `kevin@gmail.con` is a syntactically valid email address (`.con` is a 3-letter TLD pattern) but no mail server exists at `gmail.con`. Catching TLD typos early prevents bounces. Our checker flags these as suspicious with a suggested fix.

3. Hyphens at the start or end of a domain label. `user@-example.com` and `user@example-.com` are invalid per RFC 1035 (the DNS spec), but generic regex usually misses them.

4. Local part starting with a dot. `.kevin@x.com` is invalid. Gmail rejects it; some other providers accept it grudgingly. Catch it at form submit time so you don't store data that'll bounce later.

5. Total length over 254 characters. RFC 5321 caps email addresses at 254 chars. Anything longer will be rejected by most mail servers. Rare but real (typically from someone copy-pasting multiple addresses into one field).

How to add this validation to your own signup forms

If you run a signup form, you want to catch syntax errors BEFORE the form submits. Two patterns work:

Lean on browser-native HTML5 validation

The simplest approach — let the browser do the work:

<input type="email" name="email" required>

Chrome, Firefox, and Safari all enforce the same HTML5 rules our "HTML5" strictness mode uses. The form won't submit if the field doesn't validate. This catches the obvious mistakes for free.

Add JavaScript validation for typo detection

Browser validation handles structure, but it won't catch `gmail.con` typos. For that, add a quick JS check on blur:

function looksValid(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/.test(email);
}

function hasTldTypo(email) {
  const tlds = ['.con', '.cmo', '.cpm', '.ocm'];
  return tlds.some(t => email.endsWith(t));
}

const input = document.querySelector('#email');
input.addEventListener('blur', () => {
  if (input.value && !looksValid(input.value)) {
    showError(input, 'Please enter a valid email address.');
  } else if (hasTldTypo(input.value)) {
    showError(input, 'That looks like a typo — did you mean .com?');
  }
});

Bulk email list cleanup — a workflow

Got a list of thousands of emails to clean up before importing them into a CRM or sending a campaign? Here's the workflow that minimizes wasted verification credits and catches the most errors:

1. Run the list through this tool in Bulk mode with RFC 5322 practical strictness and the MX check toggle ON. Get back a labelled file: valid, invalid, suspicious (typos), unverified (DNS check failed).
2. Apply suggested fixes for the typo column. Most users mistype `gmail.com` as `gmail.con` or `gmial.com` — the tool offers the canonical version one click away.
3. Throw away the invalid rows. Syntax-invalid emails will never deliver. Importing them just pollutes your list and skews your engagement metrics.
4. **Run the survivors through our email verifier.** This is the slow, costly step — but with the syntax-invalid rows already removed, you're not spending verification credits on garbage. Many users see 15-25% of a typical raw list disappear during syntax cleanup, before verification even starts.
5. Import the verified-as-Safe addresses into your CRM. Set up the remaining catch-all and role-account flags as separate audience segments (or skip them entirely for cold outreach).