Erros de digitação em e-mails no cadastro: gmial.com e outros

Para pegar erros de digitação em e-mails no cadastro, compare o domínio que o usuário digitou com uma lista curta de provedores populares usando uma distância de edição que conte letras trocadas de lugar como uma única edição, e mostre "Did you mean jane@gmail.com?" (Você quis dizer jane@gmail.com?) quando o campo perder o foco. Nunca corrija automaticamente. Domínios com erro de digitação muitas vezes aceitam e-mail, então a verificação sozinha não vai pegá-los.

Esse último ponto é o motivo deste post. A maioria dos conselhos trata um domínio digitado errado como um bounce futuro. Nós checamos e, para boa parte dos erros comuns, não é.

O que realmente acontece com e-mails enviados para um domínio com erro

Dos 37 domínios comuns com erro que checamos, 20 podem receber e-mail: 13 publicam registros MX e 7 têm um registro A que o e-mail pode usar como fallback. E-mails para esses domínios não dão bounce de forma confiável. Eles vão para quem for o dono do domínio.

Escolhemos os erros que aparecem em bibliotecas de sugestão de erros de digitação e na nossa própria experiência (letras trocadas de lugar, uma letra a menos, uma letra repetida, .co e .con no lugar de .com) para Gmail, Yahoo, Hotmail, Outlook, iCloud e AOL. Depois rodamos dig para os registros MX e A de cada um a partir de uma conexão residencial nos EUA em 1 de outubro de 2026. Os resultados brutos, incluindo cada host MX, estão no nosso arquivo de pesquisa.

O que o DNS retornou	Quantidade	O que acontece com uma mensagem	Exemplos
Registros MX apontando para um servidor de e-mail	13	Entregue a esse servidor, se ele aceitar	gmai.com, gamil.com, hotmial.com, outlok.com, iclod.com, aoll.com
Sem MX, mas com registro A	7	Os remetentes recorrem ao registro A ("MX implícito")	gmial.com, gmali.com, yaho.com, hotmal.com, ail.com
MX nulo (0 .)	7	Rejeitado; o dono declarou que não recebe e-mail	gmail.co, gmail.cm, yahooo.com, yahoo.co, aol.co
O domínio não existe	6	Dá bounce na hora	gmail.con, yahoo.con, hotmail.con, outlook.con
Sem MX e sem registro A	3	Sem rota; dá bounce	gmal.com, gmaill.com, hotmail.co
Falha de DNS (SERVFAIL)	1	Falha temporária, nova tentativa e, no fim, bounce	icloud.co

Vale a pena conhecer três detalhes dos dados brutos.

Alguns provedores registraram seus próprios erros de digitação e desligaram o e-mail. gmail.co, cujo registro WHOIS lista o Google LLC como titular, publica um registro MX nulo conforme definido na RFC 7505. O mesmo fazem yahooo.com, yhoo.com, yahho.com e yahoo.co. Esses são o caso bom: a mensagem é recusada e um verificador vai marcar o endereço como inválido.

Três domínios com erro compartilham um mesmo servidor de e-mail. gmai.com, hotmial.com e outlok.com listam mail.h-email.net como MX. Não afirmamos nada sobre quem o opera nem por quê; o ponto é que e-mails para três erros diferentes de três provedores diferentes têm para onde ir.

.con é o erro seguro. Não é um domínio de topo, então todo endereço .con falha no DNS e dá bounce na hora. Os erros perigosos são os que ficam no meio do nome, porque esses são domínios .com que podem ser registrados.

Por que a verificação não resolve isso

A verificação pega os 17 domínios com erro que não podem receber e-mail, mas pode aprovar os outros 20, porque vistos de fora eles parecem o domínio de qualquer empresa pequena.

Um domínio com erro que tem um MX funcionando passa numa checagem de DNS. Se o servidor dele aceita todos os endereços, um catch-all, uma checagem SMTP não consegue diferenciar jane@ de qualquer outro nome. Um verificador cuidadoso reporta isso como arriscado em vez de válido, mas "arriscado" num formulário de cadastro não diz ao usuário o que ele fez de errado.

Também tentamos uma sondagem SMTP, perguntando a cada servidor com rota de e-mail se ele aceitaria um endereço aleatório e inventado no seu domínio. A maioria dos 19 servidores que testamos se recusou a falar com um IP residencial, estourou o tempo limite ou desconectou, então a maioria dos resultados foi inconclusiva. Isso é normal ao sondar a partir de uma conexão doméstica e é por isso que não tiramos conclusões deles. Dois valem ser reportados: hotmil.com (atendido por mail.yaxmail.net) e aoll.com (cujo MX é do Google) responderam 250 para um endereço que não pode existir. E-mails para qualquer nome nesses domínios são aceitos.

A consequência prática: um erro de digitação que cai num desses domínios nunca volta para você como bounce. Você simplesmente nunca mais tem notícias desse usuário, e outra pessoa pode receber a redefinição de senha ou a confirmação de pedido dele. Isso é tanto um problema de privacidade quanto de entregabilidade.

Como sugerir correções

Compare o domínio digitado com uma lista de provedores populares, sugira só quando houver exatamente um candidato muito próximo e deixe os domínios reais em paz.

O detalhe que a maioria das implementações erra é a medida de distância. A distância de Levenshtein simples conta de gmial para gmail como duas edições (duas substituições), o que força um limite mais frouxo e mais falsos positivos. A variante de alinhamento ótimo de strings (optimal string alignment) da Damerau-Levenshtein conta a troca de duas letras vizinhas como uma única edição, que é como as pessoas realmente erram ao digitar.

Esta função não tem dependências. Rodamos ela contra os 37 domínios com erro acima e 11 domínios reais que ficam perto dos alvos.

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}`;
}

Resultados do nosso teste:

Conjunto de entrada	Resultado
Todos os 37 domínios com erro da tabela acima	37 sugestões corretas (por exemplo yaho.com para yahoo.com, ail.com para aol.com, icloud.co para 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	Nenhuma sugestão, o que está correto

A primeira versão que escrevemos não tinha LEAVE_ALONE nem o limite mais apertado para domínios curtos. Ela sugeria me.com para acme.com, gmail.com para mail.com e ymail.com, aol.com para aim.com e me.com para mac.com. Todos esses são domínios reais com usuários reais. Domínios curtos precisam de um limite mais apertado, e provedores reais que ficam perto dos seus alvos precisam ser listados explicitamente. Se o seu público é regional, adicione os provedores dele às duas listas: web.de e gmx.de para a Alemanha, btinternet.com e as variantes .co.uk para o Reino Unido, e assim por diante.

Duas regras tornam seguro colocar isso em produção:

1. Abstenha-se nos empates. Se dois alvos estão igualmente próximos, não mostre nada em vez de chutar.
2. Sugira, nunca corrija. A função retorna um texto para você exibir, não uma substituição.

O que encontramos ao testar o Mailcheck

O Mailcheck (cerca de 7.900 estrelas no GitHub quando checamos) é uma biblioteca open source de longa data para isso, mas a versão no npm e o código no GitHub se comportam de forma diferente, e cada um fez uma sugestão errada que o outro não fez.

Quando checamos em 1 de outubro de 2026, o repositório tinha sido atualizado em setembro de 2026 e o package.json dele dizia 1.1.2, mas a versão mais recente no registro do npm era a 1.1.1, publicada em julho de 2015. Rodamos as duas com as mesmas entradas.

Entrada	npm 1.1.1	GitHub master
jane@gmial.com, jane@hotmial.com, jane@gmail.con	Sugestão correta	Sugestão correta
jane@gmail.co	Sugere gmail.com	Nenhuma sugestão
jane@acme.com	Sugere me.com	Nenhuma sugestão
jane@yaho.com	Sugere yahoo.com	Sugere aol.com
jane@outloo.com	Sugere outlook.com	Sugere icloud.com

O README no master deixa claro que .co é ignorado de propósito ("sample@gmail.co receives no suggestion because .co is real", ou seja, não recebe sugestão porque .co é real) e descreve a biblioteca como "a typo suggester, not an email validator or a deliverability check" (um sugeridor de erros de digitação, não um validador de e-mail nem uma checagem de entregabilidade). Concordamos com as duas posições. Mas, dados os nossos resultados de DNS, gmail.co é um caso em que sugerir é a decisão certa: .co é um TLD real, mas esse domínio específico não aceita e-mail.

Nada disso faz do Mailcheck uma má escolha. Significa, sim, que você deve instalar uma versão específica, rodá-la com os seus principais domínios e os erros comuns deles, e checar o que ela sugere para domínios reais perto dos seus alvos.

A interface

Mostre a sugestão quando o campo perder o foco, como um botão que a aplica, dentro de uma live region para que leitores de tela a anunciem.

<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, "?");
  });
}

Testamos isso no jsdom: ao tirar o foco com jane@hotmial.com, apareceu "Did you mean jane@hotmail.com?", clicar no botão substituiu o valor e escondeu a dica, e jane@acme.com não mostrou nada.

Algumas escolhas que importam:

• Ao perder o foco, não a cada tecla. Sugerir gmail.com enquanto alguém está no meio de digitar gmail.com é ruído.
• textContent, não innerHTML. A sugestão inclui o que o usuário digitou antes do @, então monte os nós do DOM em vez de concatenar HTML.
• Nunca bloqueie o envio. Se a pessoa ignorar a dica, envie o que ela digitou.
• type="email" e autocomplete="email" permitem que os navegadores ofereçam o endereço salvo do usuário e mostrem um teclado de e-mail nos celulares, o que evita muitos erros antes que aconteçam.

Onde isso se encaixa com as outras checagens

Uma sugestão de erro de digitação corrige um engano que o usuário ainda pode consertar; tudo o que vem depois do envio só pode rejeitar ou sinalizar.

A ordem que funciona num formulário de cadastro:

1. Sintaxe, no navegador e de novo no servidor. Veja por que regex de e-mail falha.
2. Sugestão de erro de digitação ao perder o foco, como acima.
3. DNS no servidor, que rejeita os domínios .con, com MX nulo e os domínios com erro mortos. O código para isso está em validar e-mail em JavaScript e Node.js.
4. Um e-mail de confirmação, que é a única checagem que prova que a pessoa digitou o próprio endereço. Os prós e contras estão em double opt-in vs. verificação de e-mail.

Se você está limpando uma lista existente em vez de um formulário, a mesma função de distância de edição funciona offline: rode-a sobre a coluna de domínios e revise cada sugestão manualmente antes de mudar qualquer coisa.

A conclusão prática

• Erros no meio do nome de um provedor (gmial, hotmial, outlok) muitas vezes caem em domínios que podem receber e-mail. Eles não dão bounce, então você não vai encontrá-los nos seus logs de bounce.
• Use uma distância de edição que trate a troca de letras vizinhas como uma única edição, abstenha-se nos empates e mantenha uma lista explícita de domínios reais que nunca devem ser corrigidos.
• Sugira; não corrija automaticamente.
• Teste qualquer biblioteca que você usar com domínios reais perto dos seus alvos. Encontramos sugestões erradas tanto na versão do npm quanto na versão do GitHub do Mailcheck.
• Para ver o que um domínio específico retorna, passe-o pela ferramenta gratuita de consulta MX.