Um utilizador termina de preencher o seu formulário de registo. Digita o nome, escolhe uma palavra-passe e insere o email como [email protected] — um caractere trocado. Clica em enviar. No seu painel, tudo parece bem: mais um registo, mais uma linha na tabela de utilizadores. Mas nenhum email de boas-vindas chega. Nenhum recibo é entregue. Quando tentam redefinir a palavra-passe três dias depois, esse link também não vai a lado nenhum. Este utilizador não abandonou. Nunca teve a oportunidade de ativar a conta, porque um único caractere errado cortou silenciosamente todos os pontos de contacto futuros que tinha com ele.
Provavelmente está a olhar para números de registo que nunca se convertem em utilizadores ativados, e uma parte significativa dessa lacuna são erros de digitação que poderia ter detetado no ponto de entrada. Uma análise de validação de emails descobriu que aproximadamente 2 a 5% dos endereços de email recolhidos contêm um erro de digitação — isso são 200 a 500 contactos perdidos por cada 10.000 registos por ano. A plataforma de gestão de igrejas Planning Center encontrou no seu sistema o único erro de escrita gmail.con mais de 37.000 vezes, causando centenas de milhares de mensagens não entregues. Cada um desses "bounces" degrada a reputação do remetente, inflaciona o custo de aquisição e envenena as métricas de entregabilidade. Este artigo mostra-lhe como detetar um erro de digitação no email em tempo real, quando corrigir versus bloquear, e como construir uma camada de validação que estanca a perda.
Índice
- Por Que os Erros de Email Passam Despercebidos e o Que Realmente Lhe Custam
- Os Erros de Email Mais Comuns e os Padrões por Trás Deles
- Validação do Lado do Cliente vs. API — Onde Deve Detetar Erros de Digitação?
- Construir um Fluxo de Sugestão "Será Que Quis Dizer?" Que Recupera Registos
- Quando Corrigir, Quando Bloquear e Quando Sinalizar para Revisão
- Integrar a Deteção de Erros em Tempo Real no Seu Fluxo de Registo
- A Sua Checklist de Defesa Contra Erros de Email
- Perguntas Frequentes
Por Que os Erros de Email Passam Despercebidos e o Que Realmente Lhe Custam
Para corrigir erros de digitação com precisão, primeiro precisa de saber onde eles acontecem. Cada endereço de email tem quatro zonas, e cada uma reúne uma classe distinta de erro.
A parte local — tudo antes do @ — acumula caracteres em falta ou a mais. Um utilizador a escrever rapidamente transforma john@ em jhon@, ou acrescenta uma letra a mais. O próprio símbolo @ é duplicado (user@@domain.com) ou omitido totalmente, produzindo user.gmail.com, que não é sequer um endereço de email. O domínio é onde vivem os erros de maior volume: nomes de fornecedores mal escritos como gmial.com, gamil.com, gmal.com, gnail.com, yaho.com, yahooo.com, hotmal.com e outlok.com. Por fim, o TLD reúne erros como .con, .cmo, .ne e .co no lugar de .com — o n fica mesmo ao lado do m, que é exatamente a razão pela qual só o gmail.con apareceu mais de 37.000 vezes num sistema de produção.
O Que um Endereço Errado Realmente Quebra
Um endereço inválido causa um hard bounce — uma falha de entrega permanente desencadeada por um endereço inválido, um domínio inexistente ou um destinatário bloqueado. Isso é diferente de um soft bounce, que é temporário: uma caixa de entrada cheia, um erro transitório do servidor, uma caixa de correio momentaneamente acima da quota. Os soft bounces resolvem-se numa nova tentativa. Os hard bounces nunca.
O dano corre por uma cadeia. De acordo com o fornecedor de infraestrutura de email SMTP.com, hard bounces acima do limite degradam a sua reputação de remetente, e assim que essa reputação cai, os ISPs começam a filtrar e a restringir o seu correio — mesmo o correio que vai para destinatários válidos. As heurísticas em que a maioria das fontes de entregabilidade convergem: uma taxa total de bounce abaixo de 2% é saudável, qualquer coisa acima de 5% é prejudicial, e os hard bounces especificamente devem manter-se abaixo de cerca de 0,5%. Estas são regras práticas de fornecedores e ESPs, não normas regulamentadas — diferentes fontes traçam a linha do "problemático" em qualquer ponto entre 2% e 10% — por isso trate-as como objetivos operacionais, não como lei.
O ângulo do gasto desperdiçado agrava o impacto na entregabilidade. Pagou para adquirir um lead que agora nunca poderá contactar. Os seus fluxos transacionais quebram silenciosamente — recibos, redefinições de palavra-passe e links de confirmação vão todos parar ao vazio. E as suas análises mentem-lhe, contabilizando registos que nunca poderão ativar, o que inflaciona silenciosamente o denominador da sua conversão e esconde o verdadeiro problema.
Um erro de digitação silencioso não aparece como um erro no seu painel — aparece como um utilizador que nunca voltou.
Uma Distinção Crítica: Erros de Digitação Não São Emails Descartáveis
Aqui está a distinção que orienta cada decisão de política adiante. Um erro honesto e um endereço deliberadamente falso parecem semelhantes na sua base de dados, mas exigem um tratamento oposto. Um erro de digitação é um engano recuperável e bem-intencionado — o utilizador queria chegar à sua caixa de entrada real e enganou-se nas teclas, por isso a jogada certa é corrigi-lo e mantê-lo. Um endereço descartável ou temporário é evasão deliberada — alguém a abusar de um teste gratuito ou a fugir a acompanhamentos — e a jogada certa é rejeitá-lo. Um verificador de endereços de email descartáveis trata do segundo caso; um fluxo de sugestão trata do primeiro. Confunda-os e ou bloqueará clientes reais ou admitirá abusadores. O resto deste guia mantém os dois em vias separadas.
Os Erros de Email Mais Comuns e os Padrões por Trás Deles
Antes de poder construir a lógica de correção, precisa de uma referência do que está a corrigir e por que se agrupa da forma como se agrupa.
| O que o utilizador escreveu | O que quis dizer | Tipo de erro | Detetável só pela sintaxe? |
|---|---|---|---|
gmial.com |
gmail.com |
Transposição de domínio | Não — precisa de inteligência de domínio |
gamil.com |
gmail.com |
Transposição de domínio | Não |
yaho.com |
yahoo.com |
Caractere em falta | Não |
yahooo.com |
yahoo.com |
Caractere a mais | Não |
hotmal.com |
hotmail.com |
Caractere em falta | Não |
gmail.con |
gmail.com |
Erro de TLD | Parcial (regras de TLD) |
user@@domain.com |
[email protected] |
@ duplicado |
Sim |
user@gmail |
[email protected] |
TLD em falta | Sim |
Três mecanismos explicam quase todos estes. A proximidade do teclado produz gmial (o i e o a transpostos) e gamil — os dedos caem em teclas vizinhas ou disparam fora de ordem. A suposição fonética produz hotmal e yaho, onde o utilizador soletra pelo som em vez de pela memória. E os erros de preenchimento automático e do telemóvel produzem o resto: teclados táteis pequenos mais correção automática agressiva eliminam ou trocam caracteres, e os erros de TLD como .con acontecem porque o n é vizinho do m no teclado.
Estes são padrões de alta frequência, não casos extremos. A contagem de gmail.con da Planning Center, de mais de 37.000 num único sistema, é a prova — um erro de escrita específico, repetido dezenas de milhares de vezes. Uma análise de milhões de emails validados pela ValidateList mostra o mesmo agrupamento em torno de variantes de Gmail, Yahoo e Outlook. Se quiser uma base pronta a usar para a sua lista de sugestões, o repositório open-source common-email-domain-typos no GitHub mapeia centenas de erros de escrita para os domínios pretendidos, e pelo menos um módulo comercial de correção de erros afirma cobrir mais de 150 erros comuns de domínio — o que lhe diz que o conjunto abordável é grande, mas finito.
Agora a nuance que molda tudo a jusante: alguns destes erros são detetáveis por regras de sintaxe puras e outros não. Um @ duplicado, um @ em falta ou um TLD em falta violam a forma de um endereço — a regex apanha-os instantaneamente. Mas gmial.com é um endereço perfeitamente bem formado. Tem uma parte local, um @, um domínio e um TLD .com. Passa na validação de endereço de email que só verifica a estrutura. Detetá-lo requer inteligência de domínio — uma lista de fornecedores conhecidos combinada com um algoritmo de distância, ou uma consulta em tempo real que confirme que o domínio e a caixa de correio existem realmente. Essa distinção é toda a razão pela qual precisa de camadas em vez de uma única verificação.
Validação do Lado do Cliente vs. API — Onde Deve Detetar Erros de Digitação?
Existem quatro abordagens para detetar erros de digitação, e cada uma apanha uma falha diferente que as outras deixam passar. A matriz abaixo pontua-as; o comentário explica onde cada uma justifica a sua utilidade.
| Abordagem | Deteta erros de domínio? | Deteta caixa de correio inválida? | Adiciona atrito de UX? | Sinaliza descartáveis? |
|---|---|---|---|---|
| Verificação de regex / sintaxe | Não | Não | Nenhum | Não |
| "Será que quis dizer?" do cliente | Parcial (lista conhecida) | Não | Baixo | Não |
| Consulta MX / DNS | Não | Não (só domínio) | Baixo | Não |
| API de verificação em tempo real | Sim | Sim | Baixo | Sim |
As verificações de regex e sintaxe apanham erros de forma — @ em falta, @ duplicado, TLD em falta — instantaneamente e com custo de rede zero. Executam-se no navegador antes de qualquer pedido ser disparado. O seu ponto cego é total para erros bem formados: gmial.com passa em todas as regras de sintaxe alguma vez escritas, porque é sintaticamente válido. A manutenção é quase nula, razão pela qual esta camada deve estar sempre presente como a sua primeira passagem gratuita.
As sugestões "Será que quis dizer?" do lado do cliente apanham erros de domínio quase acertados usando uma lista estática de fornecedores mais um cálculo de distância de edição, tipicamente Levenshtein. Isto proporciona uma excelente UX — a correção aparece instantaneamente, sem ida e volta ao servidor — mas só é tão boa quanto a lista que a suporta. Domínios que não estejam na lista passam intocados, e a lista precisa de manutenção contínua à medida que surgem novos fornecedores e domínios corporativos. Recupera erros honestos para fornecedores comuns, mas não pode garantir se alguma caixa de correio existe realmente.
A consulta MX/DNS confirma que um domínio está configurado para receber correio, o que apanha domínios inexistentes e mortos. O que não consegue fazer é confirmar a caixa de correio específica. Um domínio pode ter registos MX válidos enquanto o endereço individual gera bounce, por isso esta camada estreita o problema sem o encerrar.
A API de verificação em tempo real combina as três — sintaxe, resolução de domínio e MX, e verificações ao nível da caixa de correio — no momento da entrada. A definição de verificação em tempo real da Clearout capta isto: validar formato e entregabilidade no instante em que o endereço é inserido, para que apenas endereços entregáveis cheguem à sua lista. Crucialmente, uma API bem construída também sinaliza endereços descartáveis na mesma resposta, fechando a lacuna erro-versus-falso numa só chamada em vez de dois sistemas.
A regex pode dizer-lhe que um endereço está com a forma correta. Não lhe pode dizer que a caixa de correio é real.
A conclusão é uma defesa em camadas, não um único vencedor. A regex é gratuita e instantânea, por isso execute-a primeiro. As sugestões recuperam os quase acertos honestos a baixo custo. Só uma API em tempo real confirma que a caixa de correio existe e filtra descartáveis — por isso é a camada única mais forte e pertence ao final da cadeia, onde as verificações mais baratas já filtraram os casos óbvios.
Seja honesto quanto ao limite, no entanto. Mesmo a verificação em tempo real não é infalível. Erros de digitação que caem fora das listas de fornecedores conhecidos podem passar sem sinalização. Alguns fornecedores de caixa de correio restringem a verificação por privacidade, devolvendo resultados ambíguos em vez de definitivos. E problemas intermitentes de DNS podem produzir falsos negativos em domínios que estão de facto corretos. A API é a sua camada mais forte — trate-a como tal, não como uma garantia de que nenhum endereço errado alguma vez passa.
Construir um Fluxo de Sugestão "Será Que Quis Dizer?" Que Recupera Registos
O princípio orientador aqui é a correção em vez da punição. Uma boa sugestão recupera um registo que um bloqueio total teria perdido. Aqui está a sequência que o leva até lá.
1. Valide a sintaxe ao perder o foco (blur), não a cada tecla premida. Disparar a validação a cada tecla lança erros enquanto o utilizador ainda está a meio da escrita — vê vermelho antes de terminar o domínio. Validar no blur espera até ele sair do campo, para que a verificação corra contra uma tentativa completa. Esta única decisão de temporização é a diferença entre um formulário que parece útil e um que parece hostil.
2. Verifique o domínio contra uma lista de fornecedores conhecidos mais a distância de edição. Calcule a distância de Levenshtein entre o domínio escrito e cada domínio conhecido. gmial.com está à distância 2 de gmail.com, confortavelmente dentro de um limite de quase acerto. Alimente a sua lista a partir do repositório open-source common-email-domain-typos, ou comece com um top-50 curado como o que a Planning Center implementou. Os limites de distância evitam que sugira correções absurdas para domínios genuinamente invulgares.
3. Apresente uma sugestão inline não bloqueante. Mostre "Será que quis dizer [email protected]?" por baixo do campo. Nunca um erro rígido, nunca um botão de envio bloqueado. O utilizador mantém-se no controlo — pode aceitar a sua sugestão ou ignorá-la e prosseguir. Uma sugestão que bloqueia é apenas uma rejeição com um rótulo mais simpático.
4. Ofereça a aceitação com um clique para corrigir automaticamente. Um único toque deve substituir o valor do campo pelo endereço corrigido. Não obrigue o utilizador a reescrever nada — reescrever é atrito, e o atrito é onde os registos morrem. O objetivo é tornar a correção sem esforço.
5. Recorra à verificação por API em tempo real para domínios fora da lista conhecida. As listas estáticas não conseguem cobrir domínios novos, domínios corporativos ou a cauda longa de pequenos fornecedores. Quando o domínio escrito não está na sua lista e não é um quase acerto de nada nela, passe para a API, que confirma a entregabilidade para qualquer domínio, em vez de apenas os que catalogou. É exatamente aqui que as sugestões baseadas em listas ficam cegas e a validação de endereço de email em tempo real assume a cobertura.
6. Registe cada correção. Capture quais sugestões os utilizadores aceitam. Com o tempo, isto revela-lhe os padrões de erro reais do seu público específico — que podem diferir da lista genérica — e permite-lhe expandir e afinar a sua lista de fornecedores com base em dados reais em vez de suposições.
O próprio resultado da Planning Center é a referência que vale a pena recordar: implementar uma lista curada dos 50 principais domínios mal escritos nos seus campos de entrada reduziu de forma mensurável os emails não entregues. Não precisa de um modelo de machine learning para mover este número. Precisa de uma boa lista, matemática de distância de edição e uma interface não bloqueante.
Quando Corrigir, Quando Bloquear e Quando Sinalizar para Revisão
Nem todos os endereços questionáveis merecem o mesmo tratamento. Mapeie cada sinal a uma ação, e ligue cada ação a um resultado de negócio, antes de lançar — não depois de os tickets de suporte chegarem.
Corrigir (sugestão automática): Erros de domínio quase acertados como
gmial.com, deslizes de TLD como.con, e transposições óbvias. Resultado: recupera registos que de outra forma seriam perdidos e evita bounces antes que eles toquem sequer na sua reputação de remetente.Bloquear totalmente: Sintaxe irrecuperável, domínios confirmadamente inexistentes, e domínios descartáveis ou temporários usados para abusar de testes gratuitos. Resultado: protege a integridade do teste e mantém os inválidos totalmente fora da sua lista. Uma análise de higiene de listas estima que cerca de 15% dos endereços numa lista típica são inválidos e que aproximadamente 22,5% dos endereços válidos ficam obsoletos a cada ano, o que é exatamente por que um portão rígido na entrada compensa — está a impedir a entrada de lixo antes que ele dilua tudo a jusante. É aqui que um verificador de endereços de email descartáveis pertence no fluxo, filtrando a evasão deliberada na mesma passagem que corrige erros honestos.
Sinalizar / atrito suave: Endereços baseados em funções (
admin@,info@), domínios catch-all e resultados de baixa confiança. Resultado: permite-os mas monitoriza em vez de rejeitar, o que evita afastar falsamente utilizadores empresariais legítimos que genuinamente usam uma caixa de entrada partilhada.Lista branca / permitir sempre: Domínios conhecidos de parceiros e empresas aos quais nunca quer adicionar atrito. Resultado: atrito zero para as suas relações de maior valor, sem risco de uma regra de validação bloquear acidentalmente um contrato assinado.
A Ressalva das Armadilhas de Erros
Há uma razão pela qual não deve corrigir tudo automaticamente às cegas. As armadilhas de erros (typo traps) são domínios deliberadamente registados para ficarem a um caractere de distância dos principais fornecedores — gnail.com, yahoo.cmo — especificamente para apanhar remetentes que enviam para endereços sem os confirmar. De acordo com a publicação especializada em entregabilidade Email on Acid, citando o analista da Spamhaus Tom Mortimer, estas armadilhas entram frequentemente nas listas quando os endereços são recolhidos no ponto de venda, e a normalização demasiado agressiva pode na verdade encaminhar o correio para um domínio-armadilha hostil em vez de o afastar.
A salvaguarda é o double opt-in. Combine a sua lógica de correção com um email de confirmação que tem de ser clicado antes de a conta ser ativada. Um endereço mal escrito nunca recebe a confirmação, por isso nunca é enviado em escala — e o mesmo se aplica a uma armadilha. O double opt-in é o que torna segura uma política de correção agressiva: mesmo que a sua sugestão esteja errada, o endereço que produz tem de provar que é real e consentido antes de lhe enviar mais alguma coisa. A correção trata da intenção; o double opt-in trata da verificação. Quer ambos.
Integrar a Deteção de Erros em Tempo Real no Seu Fluxo de Registo
Com a política definida, a integração é um caminho curto e repetível. Cinco passos levam-no de um campo de entrada bruto a uma decisão aplicada.
1. Capture a entrada. Vincule a sua lógica aos eventos de blur e submit do campo de email. O blur dá-lhe uma verificação antecipada antes da submissão; o submit é o seu portão final. Ambos devem acionar o mesmo caminho de validação.
2. Chame a API de verificação. Envie o endereço no blur ou no submit. Isto é um único pedido de saída, não uma série deles.
3. Analise a resposta única. Uma API bem concebida devolve tudo o que precisa num só payload. Em vez de três idas e voltas separadas — uma para sintaxe, uma para MX, uma para triagem de descartáveis — obtém uma resposta que transporta os campos valid, suggested_correction e disposable em conjunto. Essa é a diferença entre um formulário que espera por três chamadas de rede e um que espera por uma.
4. Aplique a política. Aplique as regras de corrigir-bloquear-sinalizar-lista-branca da secção anterior contra esses campos. Se suggested_correction estiver preenchido, apresente a sugestão. Se disposable for verdadeiro, bloqueie. Se o resultado for de baixa confiança, sinalize e permita.
5. Devolva feedback de UX. Mostre uma sugestão, uma mensagem de bloqueio ou uma passagem silenciosa dependendo da decisão. O utilizador só deve ver atrito quando há um problema real a resolver.
Uma chamada de API deve dizer-lhe três coisas de uma só vez: é válido, quiseram dizer outra coisa, e é descartável.
Lidar com os Casos Extremos
Três modos de falha vão morder-lhe se não os planear. Tratamento assíncrono: nunca congele o formulário enquanto o pedido está em curso. Valide numa thread em segundo plano e deixe o utilizador continuar a avançar; bloqueie a submissão apenas se a verificação final o exigir. Timeouts e recursos alternativos: se a API estiver lenta ou inacessível, falhe em modo aberto. Uma falha de API nunca deve bloquear um utilizador legítimo — degrade graciosamente para validação apenas de sintaxe e deixe o registo passar, porque um registo perdido durante uma falha é um resultado pior do que um raro endereço não filtrado. Não bloqueie em excesso: mesmo com uma ótima API, mantenha o double opt-in como a sua rede de segurança de entregabilidade, para que um falso positivo do seu lado nunca bloqueie permanentemente uma pessoa real.
Para equipas que constroem pipelines automatizados, as mesmas verificações correm dentro de fluxos de trabalho de agentes de IA. Um servidor MCP permite que ferramentas como o Cursor ou o Claude Desktop chamem a lógica de validação idêntica de forma programática — útil quando está a limpar uma lista importada, a rever registos em massa, ou a ligar a verificação a um agente que processa registos sem um humano no ciclo. O contrato de validação é o mesmo; só o chamador muda.
Fundamente toda a abordagem na razão pela qual funciona: validar formato e entregabilidade no momento da entrada significa que apenas endereços entregáveis alguma vez entram na sua lista, segundo o enquadramento de verificação em tempo real da Clearout. E quando os endereços passam mesmo assim, a orientação de entregabilidade da Infobip é alimentar os códigos de erro de email inválido de volta no seu fluxo de aquisição como gatilhos para refinar a deteção — cada bounce que chega até si é um dado sobre um padrão de erro que pode começar a apanhar na captura.
A Sua Checklist de Defesa Contra Erros de Email
Aqui está o plano pronto a lançar. Cada item merece o seu lugar, e cada um tem uma razão de uma linha para que nada esteja na lista por hábito.
- Adicione validação de sintaxe no blur do campo — apanha
@em falta,@duplicado e TLD em falta instantaneamente com custo de rede zero. - Implemente sugestões de domínio "Será que quis dizer?" para os principais fornecedores — alimente com uma lista curada dos 50 principais; a abordagem da Planning Center reduziu de forma mensurável o correio não entregue.
- Adicione uma camada de verificação por API em tempo real para a existência de caixa de correio e domínio — a única camada que confirma que
gmial.comestá errado e que a caixa de correio por trás de um endereço aparentemente válido é real. - Defina regras de política explícitas de corrigir-vs-bloquear-vs-sinalizar — mapeie cada sinal a uma ação antes de lançar, não depois das reclamações.
- Coloque domínios de confiança na lista branca e bloqueie descartáveis conhecidos — proteja as relações empresariais e os testes gratuitos na mesma passagem de validação.
- Ative o double opt-in como rede de segurança de entregabilidade — garante que endereços mal escritos ou armadilhas nunca são enviados em escala.
- Falhe em modo aberto em erros de API — degrade para apenas sintaxe para que uma falha nunca bloqueie um registo legítimo.
- Registe correções e monitorize a taxa de bounce como a sua métrica de sucesso — vise um bounce total abaixo de 2% e hard bounce abaixo de cerca de 0,5% como KPIs operacionais.
A forma mais rápida de saber se isto importa para os seus próprios registos é vê-lo acontecer com dados reais. Pode testar sugestões de erros em tempo real e sinalizações de descartáveis contra o seu próprio formulário ao vivo usando um nível gratuito de 50 chamadas de API, sem necessidade de cartão de crédito, e ver os campos reais suggested_correction e disposable a preencherem-se nos endereços que os seus utilizadores estão a escrever neste momento. Esse único teste — passar os seus últimos cem registos pela verificação — normalmente revela mais erros recuperáveis do que a maioria das equipas espera.
Perguntas Frequentes
Posso detetar erros de email sem abrandar o registo?
Sim. Valide de forma assíncrona no blur do campo em vez de a cada tecla premida, e nunca congele o formulário durante a chamada de rede. As verificações de sintaxe no blur são efetivamente instantâneas, e a verificação por API corre em segundo plano, devolvendo uma sugestão sem bloquear a submissão. Falhe em modo aberto nos timeouts para que uma resposta lenta nunca trave um utilizador legítimo. Bem feita, a validação é invisível até ter algo de útil para dizer à pessoa a preencher o formulário.
Qual é a diferença entre um erro de digitação e um email inválido?
Um erro de digitação é um engano recuperável — o utilizador quis dizer um endereço real e enganou-se, como gmial.com em vez de gmail.com — por isso corrige-o e mantém-no. Um email inválido é genuinamente não entregável: uma caixa de correio inexistente ou um domínio morto que deve bloquear. Cerca de 15% dos endereços numa lista típica são inválidos, o que torna o portão de bloqueio tão importante quanto o portão de correção. Ambos os problemas chegam pelo mesmo campo, mas exigem respostas opostas.
Como apanho erros em domínios que nunca vi antes?
As listas estáticas de "Será que quis dizer?" só cobrem fornecedores conhecidos, por isso erros em domínios novos ou corporativos passam diretamente. É aí que as consultas MX/DNS em tempo real e a verificação ao nível da caixa de correio justificam o seu lugar — confirmam a entregabilidade para qualquer domínio, não apenas os da sua lista. Combine as duas abordagens: use a lista para cobertura instantânea e de custo zero de fornecedores comuns, e recorra à API para tudo o que a lista não conseguir reconhecer.
Corrigir erros vai realmente melhorar a minha entregabilidade?
Sim, de forma indireta mas mensurável. Cada erro corrigido é um hard bounce evitado, e os hard bounces são um dos principais motores da degradação da reputação do remetente. Manter a sua taxa total de bounce abaixo de 2% e os hard bounces abaixo de cerca de 0,5% protege a sua colocação na caixa de entrada ao longo do tempo. Corrigir na captura para esses bounces antes de eles alguma vez chegarem às suas métricas de envio — o que significa que o impacto na reputação nunca chega a acontecer, em vez de ser reparado após o facto.
Como é que um erro de digitação difere de um email descartável na forma como o devo tratar?
Intenção oposta, ação oposta. Um erro de digitação é um engano honesto que deve corrigir e manter — a pessoa quer ter notícias suas. Um endereço descartável é evasão deliberada, muitas vezes abuso de teste, que deve bloquear totalmente. Uma única resposta de API que devolve tanto uma suggested_correction como uma flag disposable permite-lhe aplicar ambas as políticas numa só verificação, para que recupere os erros genuínos e rejeite os falsos intencionais sem ter de executar dois sistemas separados.