Catching Email Typos at Signup: gmial.com, hotmial.com and More

To catch email typos at signup, compare the domain the user typed against a short list of popular providers using an edit distance that counts swapped letters as one edit, and show "Did you mean jane@gmail.com?" on blur. Never auto-correct. Typo domains often accept mail, so verification alone will not catch them.

That last point is the reason this post exists. Most advice treats a typo'd domain as a future bounce. We checked, and for a large share of common typos it is not.

What actually happens to mail sent to a typo domain

Of 37 common typo domains we checked, 20 can receive mail: 13 publish MX records and 7 have an A record that mail can fall back to. Mail to those does not reliably bounce. It goes to whoever owns the domain.

We picked the misspellings that appear in typo-suggestion libraries and our own experience (transposed letters, a dropped letter, a doubled letter, .co and .con for .com) for Gmail, Yahoo, Hotmail, Outlook, iCloud and AOL. Then we ran dig for the MX and A records of each one from a residential US connection on 1 October 2026. The raw results, including every MX host, are in our research file.

What DNS returned	Count	What happens to a message	Examples
MX records pointing at a mail server	13	Delivered to that server, if it accepts it	gmai.com, gamil.com, hotmial.com, outlok.com, iclod.com, aoll.com
No MX, but an A record	7	Senders fall back to the A record ("implicit MX")	gmial.com, gmali.com, yaho.com, hotmal.com, ail.com
Null MX (0 .)	7	Rejected; the owner has declared it takes no mail	gmail.co, gmail.cm, yahooo.com, yahoo.co, aol.co
Domain does not exist	6	Bounces immediately	gmail.con, yahoo.con, hotmail.con, outlook.con
No MX and no A record	3	No route; bounces	gmal.com, gmaill.com, hotmail.co
DNS failure (SERVFAIL)	1	Temporary failure, retried, eventually bounces	icloud.co

Three details from the raw data are worth knowing.

Some providers have registered their own typos and switched mail off. gmail.co, whose WHOIS record lists Google LLC as registrant, publishes a null MX record as defined in RFC 7505. So do yahooo.com, yhoo.com, yahho.com and yahoo.co. These are the good case: the message is refused, and a verifier will flag the address as invalid.

Three typo domains share one mail server. gmai.com, hotmial.com and outlok.com all list mail.h-email.net as their MX. We make no claim about who runs it or why; the point is that mail to three different typos of three different providers has somewhere to go.

.con is the safe typo. It is not a top-level domain, so every .con address fails at DNS and bounces at once. The dangerous typos are the ones in the middle of the name, because those are registrable .com domains.

Why verification does not solve this

Verification catches the 17 typo domains that cannot receive mail, but it can pass the other 20, because from the outside they look like any small company's domain.

A typo domain with a working MX passes a DNS check. If its server accepts every address, a catch-all, an SMTP check cannot distinguish jane@ from any other name. A careful verifier reports that as risky rather than valid, but "risky" on a signup form does not tell the user what they did wrong.

We also tried an SMTP probe, asking each server with a mail route whether it would accept a random, made-up address at its domain. Most of the 19 servers we tried refused to talk to a residential IP, timed out or disconnected, so most results were inconclusive. That is normal when probing from a home connection and is why we do not draw conclusions from them. Two are worth reporting: hotmil.com (served by mail.yaxmail.net) and aoll.com (whose MX is Google's) both answered 250 for an address that cannot exist. Mail to any name at those domains is accepted.

The practical upshot: a typo that reaches one of these domains never comes back to you as a bounce. You simply never hear from that user again, and someone else may receive their password reset or order confirmation. That is a privacy problem as much as a deliverability one.

How to suggest corrections

Compare the typed domain to a list of popular providers, suggest only when exactly one candidate is very close, and leave real domains alone.

The detail that most implementations get wrong is the distance measure. Plain Levenshtein distance counts gmial to gmail as two edits (two substitutions), which forces a looser threshold and more false positives. The optimal string alignment variant of Damerau-Levenshtein counts a transposition of neighbouring letters as one edit, which matches how people actually mistype.

This function has no dependencies. We ran it against all 37 typo domains above and 11 real domains that sit close to the targets.

const TARGETS = [
  "gmail.com", "googlemail.com", "yahoo.com", "hotmail.com", "outlook.com",
  "live.com", "icloud.com", "me.com", "aol.com", "proton.me", "protonmail.com",
  "gmx.com", "hotmail.co.uk", "yahoo.co.uk", "btinternet.com",
];
const LEAVE_ALONE = new Set([
  ...TARGETS, "mail.com", "ymail.com", "aim.com", "mac.com", "msn.com",
  "live.co.uk", "gmx.de", "gmx.net", "web.de", "pm.me", "hey.com",
]);

function editDistance(a, b) {
  const d = Array.from({ length: a.length + 1 }, (_, i) => [i, ...Array(b.length).fill(0)]);
  for (let j = 1; j <= b.length; j++) d[0][j] = 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] + 1);
      }
    }
  }
  return d[a.length][b.length];
}

export function suggestDomain(email) {
  const at = email.lastIndexOf("@");
  if (at < 1) return null;
  const domain = email.slice(at + 1).trim().toLowerCase();
  if (LEAVE_ALONE.has(domain)) return null;

  const scored = TARGETS
    .map((candidate) => ({ candidate, distance: editDistance(domain, candidate) }))
    .filter(({ candidate, distance }) => distance <= (Math.min(domain.length, candidate.length) <= 7 ? 1 : 2))
    .sort((x, y) => x.distance - y.distance);

  if (scored.length === 0) return null;
  if (scored.length > 1 && scored[0].distance === scored[1].distance) return null;
  return `${email.slice(0, at)}@${scored[0].candidate}`;
}

Results from our run:

Input set	Outcome
All 37 typo domains in the table above	37 correct suggestions (for example yaho.com to yahoo.com, ail.com to aol.com, icloud.co to icloud.com)
acme.com, stripe.com, gmx.com, gmx.de, me.com, mail.com, ymail.com, aim.com, mac.com, live.co.uk, hotmail.co.uk	No suggestion, which is correct

The first version we wrote did not have LEAVE_ALONE or the shorter threshold for short domains. It suggested me.com for acme.com, gmail.com for mail.com and ymail.com, aol.com for aim.com, and me.com for mac.com. Every one of those is a real domain with real users. Short domains need a tighter threshold, and real providers that sit near your targets need to be listed explicitly. If your audience is regional, add their providers to both lists: web.de and gmx.de for Germany, btinternet.com and the .co.uk variants for the UK, and so on.

Two rules make it safe to ship:

1. Abstain on ties. If two targets are equally close, show nothing rather than guess.
2. Suggest, never correct. The function returns a string for you to display, not a replacement.

What we found testing Mailcheck

Mailcheck (about 7,900 GitHub stars when we checked) is a long-standing open-source library for this, but the version on npm and the code on GitHub behave differently, and each made a wrong suggestion the other did not.

When we checked on 1 October 2026, the repository had been updated in September 2026 and its package.json said 1.1.2, but the latest version on the npm registry was 1.1.1, published in July 2015. We ran both against the same inputs.

Input	npm 1.1.1	GitHub master
jane@gmial.com, jane@hotmial.com, jane@gmail.con	Correct suggestion	Correct suggestion
jane@gmail.co	Suggests gmail.com	No suggestion
jane@acme.com	Suggests me.com	No suggestion
jane@yaho.com	Suggests yahoo.com	Suggests aol.com
jane@outloo.com	Suggests outlook.com	Suggests icloud.com

The README on master is explicit that .co is left alone on purpose ("sample@gmail.co receives no suggestion because .co is real") and describes the library as "a typo suggester, not an email validator or a deliverability check". We agree with both positions. But given our DNS results, gmail.co is a case where suggesting is the right call: .co is a real TLD, but that particular domain accepts no mail.

None of this makes Mailcheck a bad choice. It does mean you should install a specific version, run it against your own top domains and their common misspellings, and check what it suggests for real domains near your targets.

The interface

Show the suggestion when the field loses focus, as a button that applies it, in a live region so screen readers announce it.

<input id="email" type="email" autocomplete="email">
<p id="email-hint" role="status" hidden></p>

import { suggestDomain } from "./suggest.mjs";

export function attachTypoHint(input, hint) {
  input.addEventListener("blur", () => {
    const suggestion = suggestDomain(input.value.trim());
    hint.hidden = !suggestion;
    if (!suggestion) return;
    hint.replaceChildren("Did you mean ");
    const button = hint.ownerDocument.createElement("button");
    button.type = "button";
    button.textContent = suggestion;
    button.addEventListener("click", () => {
      input.value = suggestion;
      hint.hidden = true;
      input.focus();
    });
    hint.append(button, "?");
  });
}

We tested this in jsdom: blurring with jane@hotmial.com showed "Did you mean jane@hotmail.com?", clicking the button replaced the value and hid the hint, and jane@acme.com showed nothing.

A few choices that matter:

• On blur, not on every keystroke. Suggesting gmail.com while someone is halfway through typing gmail.com is noise.
• textContent, not innerHTML. The suggestion includes whatever the user typed before the @, so build the DOM nodes rather than concatenating HTML.
• Never block submission. If they ignore the hint, submit what they typed.
• type="email" and autocomplete="email" let browsers offer the user's saved address and show an email keyboard on phones, which prevents many typos before they happen.

Where this fits with the other checks

A typo prompt fixes a mistake the user can still correct; everything after submission can only reject or flag.

The order that works on a signup form:

1. Syntax, in the browser and again on the server. See why email regex fails.
2. Typo suggestion on blur, as above.
3. DNS on the server, which rejects the .con, null-MX and dead typo domains. Code for that is in validating email in JavaScript and Node.js.
4. A confirmation email, which is the only check that proves the person typed their own address. The trade-offs are in double opt-in vs email verification.

If you are cleaning an existing list rather than a form, the same edit-distance function works offline: run it over the domain column and review every suggestion by hand before changing anything.

The practical takeaway

• Typos in the middle of a provider name (gmial, hotmial, outlok) often land on domains that can receive mail. They do not bounce, so you will not find them in your bounce logs.
• Use an edit distance that treats a swap of neighbouring letters as one edit, abstain on ties, and keep an explicit list of real domains never to correct.
• Suggest; do not auto-correct.
• Test whatever library you use against real domains near your targets. We found wrong suggestions in both the npm release and the GitHub version of Mailcheck.
• To see what a particular domain returns, run it through the free MX lookup tool.