Email Typo Detection: Catching 'gmial.com' Before It Becomes a Bounce

Email typo detection flags misspelled addresses — like [email protected] or [email protected] — at the moment of entry, before they turn into hard bounces, lost signups, or spam trap hits. Somewhere between 1% and 3% of email addresses typed into signup forms contain a typo. Every single one is either a user you'll never reach or a bounce your sender reputation has to absorb.

The fix is small. The ROI is not. This post covers the scale of the problem, the full taxonomy of email typos, how detection algorithms actually work, why naive "closest match" logic is dangerous, and the correct UX pattern for fixing typos without creating privacy problems.

Why Should You Care About a 1–3% Typo Rate?

Because 1–3% compounds.

Run the numbers on a product doing 50,000 signups a month:

Each one of those is a person who intended to give you a real address. They typed gmial.com, your form accepted it, the confirmation email bounced (or worse — see the trap section below), and they concluded your product is broken. They don't come back to fix it. They just leave.

That's the growth cost. The deliverability cost runs in parallel: every send to a non-existent domain generates a hard bounce. Since Gmail moved to hard 5xx enforcement in November 2025 and Microsoft followed with its own bulk-sender rules in May 2025, chronic bounce rates above roughly 2% put you in filtering territory. A signup form that silently accepts typos is a machine for manufacturing bounces.

And unlike invalid addresses you inherit in an old list, typo addresses are 100% preventable at the point of entry. The user is right there, looking at the form, able to confirm the correction. This is the cheapest deliverability win that exists.

The Taxonomy of Email Typos

Not all typos look alike. If your detection only catches one category, you're fixing a fraction of the problem. Here's what actually shows up in production signup data.

Domain typos (the big one)

The vast majority of email typos live after the @. People know their own name; they mistype the domain. The usual suspects, seen constantly in real form data:

• Transposition: gmial.com, gmal.com, gamil.com, hotmial.com
• Missing letter: gmai.com, hotmal.com, yaho.com, outlok.com, iclod.com
• Doubled letter: gmaill.com, yahho.com, outloook.com
• Wrong TLD: gmail.co, gmail.con, gmail.cm, hotmail.net
• Keyboard adjacency: gmsil.com (a/s on QWERTY), gnail.com (b/g reach errors)

The top 10–15 typo variants of gmail.com, yahoo.com, hotmail.com, and outlook.com account for the overwhelming majority of all domain typos. Free webmail dominates consumer signups, so the typo distribution is heavily concentrated.

Local-part typos

Less common, but real:

• Double dots: [email protected] — invalid syntax, rejected by any decent validator
• Leading/trailing dots: [email protected]
• Trailing spaces: [email protected] — almost always from copy-paste or mobile autocomplete
• Case and Unicode lookalikes: rarely typos, but worth normalizing

Keyboard fat-finger patterns

Mobile keyboards generate a distinct typo signature: adjacent-key hits (gmsil), missed-shift errors, and autocorrect "fixes" that change a valid string into an invalid one. On mobile-heavy signup flows, expect the typo rate to sit at the high end of the 1–3% range.

Autocomplete and autofill failures

Browsers and password managers autofill stale addresses. The user doesn't type anything wrong — the form fills [email protected] and they tap through. Typo detection can't catch a syntactically valid, correctly-spelled dead address; that's what full validation (MX, SMTP, mailbox checks) is for. Don't confuse the two problems.

How Does Email Typo Detection Actually Work?

Four techniques, usually layered.

1. Edit distance to known domains

The core algorithm. Compute the Levenshtein (or Damerau-Levenshtein, which treats transposition as one edit) distance between the submitted domain and a list of common real domains. gmial.com → gmail.com is distance 1 (a transposition). If the distance is below a threshold — almost always 1, occasionally 2 for long domains — you have a candidate suggestion.

The reference list matters more than the algorithm. A good list includes the top few hundred consumer and corporate mail domains, weighted by how often they appear in your own signup data.

2. Common-typo dictionaries

Precomputed maps from known-bad to known-good: hotmal.com → hotmail.com, yaho.com → yahoo.com, outlok.com → outlook.com. Dictionary lookup is O(1), catches the highest-frequency cases without any distance math, and encodes human knowledge that pure edit distance misses (e.g., gmail.co is distance 2 from gmail.com but is a classic typo worth catching).

3. Keyboard-layout adjacency weighting

Plain Levenshtein treats gmsil and gxail as equally distant from gmail. They're not. On a QWERTY layout, s sits next to a, so gmsil is a plausible slip; x is not adjacent to m in a way that produces gxail. Weighting substitutions by physical key adjacency (with separate layouts for QWERTY, AZERTY, and mobile) cuts false positives noticeably.

4. Frequency tables

Not all distance-1 suggestions are equally likely. If your own signup data shows 40,000 @gmail.com and zero @gmsil.com, the prior probability that gmsil was meant to be gmail is overwhelming. Bayes beats raw string distance: combine edit distance, keyboard adjacency, and the observed frequency of both domains in your data, then suggest only when the evidence is strong.

This is roughly how the typo-suggestion layer in a serious validation pipeline works. Try it: paste a few typo addresses into the free email validator and watch the suggestion layer fire — it runs alongside syntax, MX, SMTP, disposable, and spam-trap checks.

Why Naive "Closest Match" Is Dangerous

Here's where developers get it wrong. The tempting implementation is:

# DON'T do this
def fix(email):
    domain = email.split("@")[1]
    closest = min(KNOWN_DOMAINS, key=lambda d: distance(d, domain))
    return email.replace(domain, closest)

Three problems.

1. You can "correct" a real address into someone else's. [email protected] might be a typo for Gmail. But [email protected] corrected by a badly-tuned matcher could become a different real mailbox. You'd then email a stranger someone else's account confirmation, password reset, or receipt. That's a privacy incident, not a growth hack. If the suggested domain hosts real mailboxes, the address you construct may belong to an actual person.

2. Some typo domains are spam traps. More on this below — but auto-correcting toward or away from the wrong domain can route you straight into one.

3. Silent correction destroys the feedback loop. The user never learns their muscle memory is wrong. They'll type gmial again on your login form, your checkout form, and every other site. And if they did mean the unusual domain — some people genuinely have mailboxes at domains that look like typos — you've just locked them out of their own account.

The rule: typo detection produces a suggestion for the human. It never silently rewrites the address.

The Correct UX Pattern: "Did You Mean?" as a Suggestion

The battle-tested pattern is an inline prompt shown after the field loses focus (or after submit fails validation), offering a one-tap correction:

<div class="field">
  <label for="email">Email</label>
  <input id="email" type="email" autocomplete="email">
  <p id="typo-hint" class="hint" hidden>
    Did you mean <button type="button" id="suggestion"></button>?
  </p>
</div>

<script>
const COMMON_DOMAINS = ["gmail.com", "yahoo.com", "hotmail.com",
  "outlook.com", "icloud.com", "aol.com", "proton.me"];
const TYPO_MAP = { "gmial.com": "gmail.com", "gmal.com": "gmail.com",
  "gamil.com": "gmail.com", "hotmal.com": "hotmail.com",
  "yaho.com": "yahoo.com", "outlok.com": "outlook.com",
  "gmail.co": "gmail.com", "gmail.con": "gmail.com" };

function damerau(a, b) {
  // standard Damerau-Levenshtein; treat transposition as cost 1
  const d = Array.from({length: a.length + 1}, (_, i) =>
    Array.from({length: b.length + 1}, (_, j) => i + j ? 0 : Math.max(i, j)));
  for (let i = 1; i <= a.length; i++)
    for (let j = 1; j <= b.length; j++) {
      const cost = a[i-1] === b[j-1] ? 0 : 1;
      d[i][j] = Math.min(d[i-1][j] + 1, d[i][j-1] + 1, d[i-1][j-1] + cost);
      if (i > 1 && j > 1 && a[i-1] === b[j-2] && a[i-2] === b[j-1])
        d[i][j] = Math.min(d[i][j], d[i-2][j-2] + cost);
    }
  return d[a.length][b.length];
}

function suggest(domain) {
  domain = domain.toLowerCase().trim();
  if (TYPO_MAP[domain]) return TYPO_MAP[domain];
  if (COMMON_DOMAINS.includes(domain)) return null; // already valid
  let best = null, bestDist = 2; // distance-1 suggestions only
  for (const d of COMMON_DOMAINS) {
    const dist = damerau(domain, d);
    if (dist < bestDist) { best = d; bestDist = dist; }
  }
  return best; // null if nothing close enough
}

document.getElementById("email").addEventListener("blur", (e) => {
  const [local, domain] = e.target.value.split("@");
  if (!domain) return;
  const fixed = suggest(domain);
  const hint = document.getElementById("typo-hint");
  if (fixed) {
    const btn = document.getElementById("suggestion");
    btn.textContent = `${local}@${fixed}`;
    btn.onclick = () => { e.target.value = btn.textContent; hint.hidden = true; };
    hint.hidden = false;
  } else {
    hint.hidden = true;
  }
});
</script>

Design rules that matter:

• Suggest, never auto-correct. The user clicks to accept. The original text stays until they do.
• One suggestion maximum. Offering gmail.com? ymail.com? gmal.com? is worse than offering nothing.
• Distance-1 by default. Distance-2 suggestions have a much higher wrong-guess rate. Reserve them for dictionary-confirmed typos like gmail.co.
• Don't block submission. If the user dismisses the suggestion, let them through and validate the address server-side. Some people really do have mail at weird domains.
• Fire on blur, not on every keystroke. Suggesting while someone is mid-type is noise.

For a client-side head start, the Mailcheck library (and its maintained forks) implements exactly this pattern. For anything serious, run it server-side through a validation API so you get typo suggestion plus MX, SMTP, and trap screening in one call — see the real-time API docs for the validation endpoint shape.

The Typo-Trap Connection: Why gmial.com Can Be Worse Than a Normal Bounce

This is the part most teams don't know, and it changes the stakes.

Mailbox providers and anti-spam operators have long registered popular typo domains — including variants of gmail.com, yahoo.com, and hotmail.com — and run them as spam traps. A typo trap domain accepts mail (it has MX records, its SMTP server answers RCPT TO with a 250), but no human ever signed up from it. The only mail it receives comes from senders who failed to catch a typo.

Sending to one of these isn't a bounce. It's worse:

• It doesn't clean itself off your list. A hard bounce gets suppressed. A trap accepts the mail, so the address stays "valid" in your database and you hit it again and again.
• It's a direct signal of bad acquisition hygiene. Providers treat trap hits as evidence that your list-building process doesn't verify addresses. Since Yahoo moved to domain-reputation-first filtering in April 2025, signals like this follow your domain, not just your IP.
• It poisons your engagement math. Trap addresses never open. They dilute every engagement metric providers use to judge you.

So a typo address has three possible outcomes, and two of them hurt you: it bounces (reputation cost), it lands in a trap (bigger reputation cost), or — rarely — it's a real stranger's mailbox (privacy problem). There is no harmless outcome. The only winning move is catching it before the first send.

Check your exposure: run a sample of recently collected addresses through the email validator. The typo-suggestion and spam-trap layers flag exactly these cases before they cost you.

Where Should You Enforce Typo Detection?

Three surfaces, in priority order.

1. Signup forms, in real time

The highest-leverage spot. The user is present, motivated, and able to confirm the fix in one tap. Implement the "Did you mean?" pattern above, and back it with a server-side validation call on submit so malformed addresses never enter the database even when the suggestion is dismissed. On mobile-heavy flows, this alone typically recovers the majority of typo signups.

2. List imports, in bulk

Every CSV import is a typo time capsule. Addresses collected on paper forms, transcribed from phone calls, exported from old tools — the typo rate in imported lists routinely exceeds the 1–3% web-form baseline. Validate the whole file before the first send: syntax, domain/MX, typo suggestion, disposable, role-based, and trap screening. The workflow for that is laid out step by step in our bulk email validation CSV checklist.

A nuance for imports: you can't ask the user to confirm, so don't rewrite typo domains silently in bulk either. Flag them (suggestion: gmail.com in the results), quarantine the rows, and either confirm with the contact through another channel or suppress them. Silently "fixing" 500 imported addresses is how you email 500 strangers.

3. CRM and database cleanup, on a schedule

Existing databases accumulate typo damage from before you had detection in place, plus address decay. A quarterly pass over the active list catches stragglers. Pair it with monitoring so you notice if bounce rate creeps up between cleanups — sudden spikes after a form change or a new acquisition channel are usually typo-related. (If you're already seeing deliverability symptoms, our post on why emails land in spam walks the diagnostic order.)

Measuring the Win: The Recovered Signups Metric

Typo detection is unusually easy to justify to a CFO because the metric is direct. Instrument three numbers:

1. Suggestions shown — how often the hint fires. This is your true typo rate; expect 1–3%.
2. Suggestions accepted — the acceptance rate. A well-placed one-tap suggestion sees 60–80% acceptance.
3. Recovered signups — accepted suggestions that go on to verify their email or activate. This is the money metric: users who would have been lost and weren't.

-- weekly recovered-signup report
SELECT date_trunc('week', created_at) AS week,
       count(*) FILTER (WHERE suggestion_shown) AS shown,
       count(*) FILTER (WHERE suggestion_accepted) AS accepted,
       count(*) FILTER (WHERE suggestion_accepted AND activated) AS recovered,
       round(100.0 * count(*) FILTER (WHERE suggestion_accepted)
             / nullif(count(*) FILTER (WHERE suggestion_shown), 0), 1) AS accept_pct
FROM signup_events
GROUP BY 1 ORDER BY 1 DESC;

On the deliverability side, watch hard-bounce rate on welcome emails before and after rollout. Teams typically see it drop by half or more within weeks, because typo addresses were a large share of new-list bounces. If you want a before/after baseline, send your welcome flow through the deliverability tester — it scores authentication, DNS, headers, and content so you can separate typo-bounce problems from everything else.

A Realistic Rollout Plan

1. Week 1: Ship client-side "Did you mean?" on the top signup form (the snippet above, or Mailcheck). Add the three event metrics.
2. Week 2: Add server-side validation on submit — syntax, MX, typo suggestion, disposable, trap screening via API.
3. Week 3: Bulk-validate the existing database and all pending imports. Quarantine flagged rows.
4. Ongoing: Quarterly list hygiene, bounce-rate monitoring, extend the pattern to checkout, referral, and profile-update forms.

Total engineering effort: a few days. Payback: permanent.