Detecção de erros em e-mail: corrija gmail.con antes do usuário submeter

Por que erros de digitação em e-mail atrapalham cadastros\n\nUm caractere errado num endereço de e-mail pode travar um cadastro. Se alguém digita gmail.con em vez de gmail.com, seu e-mail de confirmação nunca chega. O usuário normalmente não faz ideia do porquê. Ele atualiza a página, tenta de novo ou desiste. O mesmo erro mais tarde quebra resets de senha, avisos de cobrança e qualquer mensagem que comprove que a conta é real.\n\nErros em e-mails importam porque a maioria das pessoas não pensa no próprio endereço como “dados”. Pensam “eu digitei, então deve estar certo”. Quando nada aparece na caixa de entrada, culpam seu produto, não o teclado.\n\nO impacto se acumula rápido: mais cadastros abandonados por não conseguirem verificar, mais tickets de suporte dizendo “não recebi o e-mail”, leads perdidos e atribuição confusa porque contatos nunca ficam alcançáveis, além do risco na entregabilidade quando o sistema continua tentando endereços inválidos.\n\nOs erros também são previsíveis. Um pequeno conjunto de domínios é responsável por grande parte das falhas: gmail.con, hotnail.com e yaho.com aparecem repetidas vezes. Detectá-los cedo é um dos poucos ajustes de UX que podem melhorar a conclusão de forma mensurável sem mudar sua proposta.\n\nAjuda deixar claro o que a detecção de erros pode e não pode fazer. Ela pode identificar prováveis enganos (frequentemente comparando o domínio com provedores comuns) e sugerir uma correção antes do envio. Não pode garantir que a caixa existe, que a pessoa é dona dela, ou que o endereço é seguro para aceitar.\n\nUma abordagem prática: sugerir quando tiver confiança, validar quando precisar de certeza. Por exemplo, Verimail pode validar endereços no cadastro usando checagens como regras de sintaxe, verificação de domínio e MX, e detecção de descartáveis, enquanto sugestões de typo impedem erros simples de serem submetidos.\n\n## Os erros de e-mail mais comuns que valem a pena capturar\n\nA maioria das pessoas não erra o e-mail de propósito. Digitam rápido, num teclado pequeno ou trocando entre apps. Uma boa detecção de erros foca em falhas que acontecem com frequência e são seguras para sugerir correções.\n\nAs correções de maior valor geralmente estão na parte do domínio (tudo depois do @). Em geral as pessoas conhecem seu nome de usuário, mas erram provedores populares. Padrões comuns incluem letras faltando (gmal.com), letras trocadas (gmial.com) e letras duplicadas (gmaill.com). Esses são fáceis de detectar porque estão a uma ou duas edições de um domínio conhecido.\n\nErros no TLD são outro grande caso, porque parecem válidos à primeira vista. O clássico é gmail.con em vez de gmail.com, mas você também vai ver .cmo, .coom ou um TLD de país digitado por engano. Se o domínio for uma boa correspondência e só o final estiver errado, a sugestão costuma ser bem recebida.\n\nNem todas as “digitações erradas” são ortografia. Problemas de formatação causam falhas silenciosas também, especialmente quando usuários copiam e colam. Fique de olho em espaços no começo ou fim, ponto final no fim ([email protected].), pontos duplos ([email protected]), vírgulas em vez de pontos (name@gmail,com) e @s faltando ou extras.\n\nMobile traz seus próprios problemas: teclas adjacentes (n e m), autocorreção trocando um domínio ou o teclado inserindo um espaço após um ponto. Um exemplo realista: alguém digita [email protected] no telefone. Uma sugestão simples como “Did you mean [email protected]?” evita um ticket de suporte e um cadastro perdido sem fazer o formulário parecer rígido.\n\n## Onde a detecção de typos se encaixa no fluxo de cadastro\n\nA detecção funciona melhor como um auxílio, não como um bloqueio. Trate-a como corretor ortográfico: rápida, discreta e fácil de ignorar quando o usuário está certo.\n\nVerificações client-side devem acontecer perto da digitação para que as pessoas corrijam antes de seguir. Mantenha leves: compare a parte do domínio com uma lista curta de provedores comuns e sugira só quando a correspondência for muito forte (como gmail.con → gmail.com). Não bloqueie o envio só porque achou um typo. Alguns domínios parecem incomuns mas são perfeitamente válidos.\n\nVerificações server-side são a rede de segurança. Usuários podem contornar o navegador, scripts podem postar direto e até uma ótima UI não evita todos os endereços ruins. Rode a mesma lógica de typos no backend e então faça validação real (sintaxe, domínio, MX, detecção de descartáveis). Uma API de validação de e-mail como Verimail pode cuidar das checagens mais profundas para você não precisar manter isso internamente.\n\nQuando mostrar sugestões depende do estilo do seu formulário:\n\n- On blur (quando o campo perde o foco): calmo e previsível para a maioria dos formulários.\n- Depois de uma pausa curta na digitação (debounced 300–500 ms): parece instantâneo, mas pode ficar barulhento se mal ajustado.\n- On submit: menos interrupção, mas os usuários corrigem depois, quando já se sentem “prontos”.\n\nPessoas que colam um e-mail e apertam Enter rápido são o caso complicado. Evite desacelerá-las. Mostre a sugestão imediatamente, mas deixe o Enter submeter normalmente. Se precisar de uma segunda chance, exiba um pequeno aviso inline após o envio e antes da criação da conta, com duas ações claras: “Usar e-mail digitado” e “Usar e-mail sugerido”.\n\nUma regra simples: sugira cedo, verifique sempre e nunca prenda usuários num loop onde não consigam seguir em frente.\n\n## Passo a passo: um algoritmo simples de sugestão de typos\n\nUma boa verificação de typos faz uma coisa bem: detecta erros óbvios como gmail.con e sugere a correção certa, sem adivinhar quando o usuário digitou algo incomum de propósito.\n\nComece construindo um conjunto pequeno e curado de domínios que você está disposto a sugerir. Inclua os grandes provedores públicos (gmail.com, outlook.com, yahoo.com) e, se fizer sentido para seu público, os domínios de clientes que aparecem frequentemente (por exemplo, se muitos cadastros vêm de algumas empresas). Mantenha essa lista curta e revisada, pois cada domínio adicionado aumenta a chance de uma sugestão errada.\n\nEm seguida, normalize o que o usuário digitou antes de comparar. Remova espaços, divida no @, coloque apenas a parte do domínio em minúsculas e trate caracteres Unicode estranhos com cuidado (usuários podem colar letras que parecem iguais).\n\nAqui está um fluxo simples que funciona bem na prática:\n\n- Extraia o domínio depois do @; se não houver @, não faça nada.\n- Se o domínio for uma correspondência exata na sua lista curada, não faça nada.\n- Calcule uma pontuação de correspondência próxima contra cada domínio curado (distância de edição é a escolha comum).\n- Sugira apenas se houver um vencedor claro e a distância for pequena (por exemplo, 1 ou 2 edições).\n- Mostre a sugestão como uma opção, não como reescrita automática.\n\nUm exemplo mínimo em pseudocódigo:\n\ntext\nif not hasAt(email): return\nlocal, domain = split(email)\nd = normalize(domain)\nif d in knownDomains: return\nbest = closestByEditDistance(d, knownDomains)\nif best.distance \u003c= 2 and best.isUniqueWinner:\n suggest(local + \"@\" + best.domain)\n\n\nSeja conservador com os limites. É melhor não detectar um typo raro do que irritar muitas pessoas com prompts constantes. Sugira apenas quando a confiança for alta, como hotnail.com → hotmail.com, não quando vários domínios estiverem igualmente próximos.\n\nPor fim, mantenha o usuário no controle. Ofereça escolhas claras como “Usar gmail.com” e “Manter gmail.con”, e não bloqueie o envio só porque mostrou uma sugestão. Sua camada de validação (por exemplo, uma API de validação de e-mail como Verimail) ainda pode rodar separadamente para pegar domínios inválidos e endereços descartáveis.\n\n## Padrões de UX que consertam erros sem irritar as pessoas\n\nUma boa sugestão de correção parece um empurrãozinho útil, não uma bronca. O objetivo é simples: ajudar alguém a consertar gmail.con ou hotnail.com com um toque, sem interromper o fluxo.\n\nO padrão mais limpo é uma dica inline logo abaixo do campo de e-mail. Seja curto e específico: “Did you mean gmail.com?” Adicione uma ação óbvia como “Usar gmail.com” para que o usuário não precise digitar de novo. Isso funciona melhor assim que o endereço parece completo (depois do usuário digitar o domínio, ou on blur), não a cada tecla.\n\nQuando o risco for maior, adicione uma leve confirmação antes do envio. Por exemplo, quando o usuário clica em “Criar conta”, mostre uma pequena mensagem inline perto do campo de e-mail apresentando as duas opções: manter o que foi digitado ou trocar para o domínio sugerido. Isso reduz falsos positivos e evita a sensação de que o formulário está “assumindo o controle”.\n\nAlguns detalhes tornam esses padrões respeitosos:\n\n- Torne a sugestão descartável (“Dismiss”) e memorize essa escolha para a sessão para não reaparecer.\n- Evite modais para typos menores. Um modal é pesado e pode parecer um erro, mesmo quando você não tem certeza.\n\n- Depois que o usuário aceita a correção, mantenha o foco previsível: o cursor deve continuar no campo de e-mail (ou ir para o próximo campo apenas se esse for o comportamento normal).\n\n- Se ele optar por manter o input, não fique sugerindo de novo a menos que o e-mail mude.\n\nExemplo: alguém digita [email protected] num trial. Uma dica inline oferece “Usar hotmail.com.” Sarah toca uma vez, o campo atualiza e ela continua para a senha sem perder o ritmo. Depois, você ainda pode rodar uma checagem server-side (por exemplo com uma API de validação de e-mail) para pegar problemas mais profundos, mas a vitória de UX acontece aqui.\n\n## Texto e acessibilidade que importam\n\nA detecção de typos é, em grande parte, sobre como você fala com o usuário. O objetivo é ajudar, não culpar. Texto neutro mantém as pessoas em movimento: “Did you mean gmail.com?” funciona melhor que “Esse e-mail está errado.” Se precisar de um tom mais cauteloso, tente “Verifique o domínio: queria dizer gmail.com?”\n\nMostre a diferença exata e concentre-se apenas na parte que mudou. A maioria dos erros está no domínio, então destaque só esse segmento (por exemplo, mostre name@ inalterado e enfatize visualmente gmail.con → gmail.com). Isso reduz confusão e faz a correção parecer segura.\n\nMantenha estados de sugestão e erro claramente diferentes. Uma sugestão é uma dica, não uma falha, então deve parecer mais discreta que um erro grave. Por exemplo: uma linha de sugestão cinza sob o campo, e use vermelho só quando realmente bloquear o envio (como falta de @, caracteres inválidos ou um domínio impossível).\n\nAcessibilidade precisa do mesmo cuidado das visuais. Leitores de tela devem anunciar tanto a sugestão quanto a ação disponível. Um padrão simples é:\n\n- Anunciar: “Sugestão: queria dizer gmail.com?”\n- Fornecer um rótulo de ação: “Usar gmail.com em vez deste”\n- Confirmar após ativação: “E-mail atualizado para gmail.com”\n\nTambém garanta que a sugestão seja navegável por teclado (alcançável com Tab, ativável por Enter/Espaço) e que o foco não pule de forma inesperada.\n\nLocalização é fácil de errar. Traduza o texto ao redor, mas não traduza o domínio em si. gmail.com continua gmail.com em qualquer idioma. Se usar uma API como Verimail, mantenha as mensagens do produto consistentes entre locais preservando o domínio sugerido intacto.\n\n## Quando não sugerir correção\n\nErros são comuns, mas sugestões confiantes demais podem ser piores que não fazer nada. Se seu formulário “corrige” um endereço real, você arrisca perder um usuário que fez tudo certo.\n\nComece sendo conservador com domínios que você não reconhece. Muitas pessoas usam e-mails de escolas, domínios de empresas ou TLDs novos como .dev ou .app. Se alguém digita [email protected], isso não é “errado” só porque você não viu antes. Trate domínios desconhecidos como “a verificar”, não como “typo”.\n\nEvite mexer na parte local (tudo antes do @). Mudar jane.smith para jane-smith ou remover pontos é chute. Sugira alterações na parte local só se tiver uma regra clara e aprovada pelo usuário no seu produto (por exemplo, você sabe que seu próprio domínio ignora pontos). Caso contrário, foque sugestões só no domínio.\n\nPlus-addressing é outro ponto que times quebram por engano. Endereços como [email protected] são válidos e amplamente usados para filtragem. Se seu sistema os suporta, não alerte, remova ou bloqueie. Se não suporta, deixe claro o motivo, pois usuários podem depender das tags para regras de caixa de entrada.\n\nUma regra prática: sugira, não force. Bons momentos para não sugerir incluem:\n\n- Você não tem alta confiança (por exemplo, apenas um caractere difere entre muitos domínios possíveis)\n- O domínio parece intencionalmente customizado (empresa, escola, interno)\n- O usuário já editou o e-mail duas vezes e manteve o mesmo valor\n- Sua sugestão exigiria mudar a parte local\n\nPor fim, sempre deixe as pessoas prosseguir com o que digitarem. Uma opção clara como “Usar como digitado” previne frustração, especialmente quando seu validador (por exemplo, um serviço como Verimail) não consegue confirmar entregabilidade instantaneamente mas o usuário sabe que o endereço está certo.\n\n## Erros e armadilhas comuns a evitar\n\nA maneira mais fácil de fazer a detecção parecer “inteligente” é também a forma mais fácil de errar: sugerir correções com muita frequência. Se seu limiar de correspondência for frouxo, você vai irritar pessoas com endereços corretos (especialmente domínios corporativos). Foque sugestões em casos de alta confiança como provedores populares (gmail.com, outlook.com, yahoo.com) e edições muito pequenas.\n\nAuto-correção silenciosa é outra armadilha clássica. Trocar gmail.con por gmail.com sem avisar pode parecer útil, mas cria problemas reais depois: resets de senha vão para a caixa errada ou o usuário pensa que se cadastrou com um endereço diferente do que você armazenou. Sempre peça confirmação quando propuser uma correção.\n\nTambém não dependa apenas de checagens no frontend. Uma UI limpa ainda aceita lixo se bots ou clientes scriptados postarem direto no endpoint. Trate a sugestão no navegador como conveniência e faça a validação no servidor também. Um fluxo prático é: sugerir na UI, depois re-checar server-side com sintaxe e verificação de domínio/MX (e rejeitar endereços obviamente inválidos).\n\nPara manter isso sob controle, registre o que acontece depois de mostrar uma sugestão. Se não logar resultados, você não saberá se suas regras ajudam ou prejudicam.\n\n- Logue: sugestão mostrada, sugestão aceita, sugestão ignorada, usuário editou manualmente\n- Acompanhe: domínios envolvidos, taxa de erro por domínio e taxa de bounce por coorte\n- Revise: falsos positivos frequentes e adicione-os a uma allowlist\n\nPor fim, não confunda tratamento de typos com detecção de e-mails descartáveis. Um endereço descartável pode estar perfeitamente escrito, e um typo pode ocorrer num domínio não descartável. Trate-os como sinais distintos com UIs diferentes.\n\nPor exemplo, hotnail.com provavelmente é um typo que merece um gentil “Did you mean hotmail.com?” Mas mailinator.com não é um typo. Se você bloqueá-lo, diga claramente. Se usar uma API como Verimail, mantenha decisões distintas: sugestões de typo para UX e detecção de descartáveis para proteger a qualidade dos cadastros.\n\n## Checklist rápido pré-lançamento\n\nAntes de liberar a detecção de typos, faça um rápido teste com dispositivos reais e hábitos reais de digitação. A maioria das falhas vem de pequenos detalhes: quando a sugestão aparece, o que acontece no Enter e se o servidor concorda com o navegador.\n\nUse este checklist para pegar os problemas que aparecem após o lançamento:\n\n- Mostre sugestão apenas quando tiver muita convicção. Foque em correções de domínio de alta confiança (por exemplo, gmail.con → gmail.com) e evite chutes em domínios corporativos incomuns.\n- Aceitar e dispensar deve ser seguro. Se o usuário ignorar a sugestão, mantenha exatamente o que ele digitou. Se aceitar, mude só a parte do domínio e nunca limpe o campo.\n- Teste caminhos rápidos em mobile e desktop: colar, autofill e apertar Enter para submeter. A sugestão não deve bloquear o envio nem desaparecer antes do usuário agir.\n- Verifique acessibilidade. A sugestão precisa ser anunciada por leitores de tela e os botões de ação alcançáveis por teclado com rótulos claros.\n- Faça o comportamento do cliente casar com o do servidor. Se o navegador sugeriu uma correção, seu backend ainda deve validar o e-mail final e tratar casos extremos da mesma forma (sintaxe, existência de domínio, MX). Se usar uma API como Verimail, confirme que regras e resultados server-side alinham com o que o usuário viu.\n\nDepois, adicione analytics para provar que o recurso ajuda em vez de supor. Capture, no mínimo: quando uma sugestão foi mostrada, quando foi aceita, quando foi dispensada e qual e-mail foi salvo (armazene com segurança e considere logar apenas o domínio ou um valor hash se não precisar do endereço completo).\n\nUm último teste de sanidade: digite propositalmente errado um domínio comum, aceite a correção e conclua o cadastro. Faça de novo ignorando a correção. Em ambos os casos, o formulário deve parecer calmo e previsível, e o e-mail salvo deve corresponder à escolha do usuário.\n\n## Exemplo: corrigindo um typo num trial na prática\n\nUm usuário inicia um trial e digita o e-mail rápido: [email protected]. À primeira vista parece certo, mas quase certamente vai falhar depois. O usuário submete, espera o e-mail de boas-vindas e então abre um ticket: “Não recebi.”\n\nCom detecção de typos, o formulário pega o erro enquanto o usuário ainda está no campo. Logo abaixo do input, aparece uma nota inline (não um popup): “Did you mean [email protected]?” Ao lado há uma ação única, tipo “Usar hotmail.com.”\n\nO usuário toca uma vez, o e-mail é atualizado no campo e o cursor segue como se nada tivesse acontecido. Sem modal, sem salto de página, sem interrupção. Se a sugestão estiver errada, o usuário pode ignorá-la e seguir.\n\nUma versão simples da interação é:\n\n- Mostrar sugestão somente após o usuário terminar de digitar (on blur) ou pausar brevemente\n- Fazer a correção com um toque e reversível (desfazer ou “x” para dispensar)\n- Manter a mensagem calma: “Did you mean…” em vez de “E-mail inválido”\n\nMesmo com uma sugestão perfeita, o backend ainda deve validar o endereço antes de criar a conta. Por exemplo, depois que o usuário aceita hotmail.com, seu servidor pode rodar checagens completas (sintaxe, domínio, registros MX, detecção de descartáveis e blocklists) usando uma API como Verimail.\n\nO resultado é prático: menos e-mails de boas-vindas devolvidos, menos tickets “não recebi” e menos usuários de trial perdidos por um typo minúsculo.\n\n## Próximos passos: medir resultados e reforçar validação\n\nDepois de adicionar detecção de typos, trate-a como qualquer mudança de produto: meça e então ajuste com base no comportamento real. O objetivo é menos cadastros falhos e menos endereços ruins, sem bloquear pessoas reais.\n\nComece acompanhando um conjunto pequeno de resultados que conectam diretamente à dor do usuário e ao custo do negócio:\n\n- Taxa de conclusão do cadastro (mais pessoas terminaram o formulário?)\n- Taxa de bounce do e-mail de boas-vindas (menos falhas nas primeiras mensagens?)\n- Taxa de e-mails confirmados (mais pessoas verificaram com sucesso?)\n- Contatos de suporte sobre login ou e-mails faltando (a confusão diminuiu?)\n- Taxa de aceitação da correção (com que frequência aceitam sua sugestão)\n\nEntão itere suas regras. Se usuários raramente aceitam uma sugestão, pode ser que ela esteja agressiva (por exemplo, sugerindo gmail.com para muitos domínios incomuns). Se aceitam com frequência, expanda sua lista de domínios e ajuste os limiares (distância de edição, letras trocadas, ponto faltando) para refletir o que vê na produção. Mantenha uma allowlist curta de domínios populares, mas aprenda também com seu próprio tráfego.\n\nTypos são apenas uma camada. Para reduzir fraude e proteger entregabilidade, adicione checagens mais profundas que confirmem se um endereço provavelmente é alcançável: checagens de sintaxe conforme RFC, existência de domínio e lookup de registros MX, e matching em blocklists para provedores descartáveis e armadilhas conhecidas. Em muitos produtos, vale a pena retornar flags de risco em vez de bloqueios rígidos quando a confiança é baixa.\n\nSe quiser uma opção tudo-em-um para essas checagens durante o cadastro, Verimail (verimail.co) roda sintaxe, domínio, MX e matching de descartáveis/blocklist em milissegundos e retorna um resultado claro que seu formulário pode usar.\n\nRolar mudanças gradualmente: faça A/B tests na UI de sugestão e nos limiares de validação, ou libere por porcentagem de tráfego. Observe atentamente falsos positivos, especialmente para domínios internacionais, domínios corporativos e provedores menos comuns. Em caso de dúvida, deixe o usuário prosseguir, mas registre o evento para melhorar as regras com evidência.