Como funciona a verificação de e-mail: os 8 estágios

A resposta curta#

A verificação de e-mail passa um endereço por um pipeline de checagens cada vez mais caras, parando assim que uma delas é decisiva. As checagens baratas e instantâneas acontecem localmente — o endereço tem ao menos o formato de um e-mail, o domínio dele aceita correio de alguma forma — e só os endereços que sobrevivem a essas checagens chegam ao passo lento, dependente de rede, de de fato perguntar ao servidor de e-mail se a caixa postal existe. A Qualisend roda oito estágios distintos, e este post percorre cada um deles: o que ele consegue provar, o que não consegue e qual veredito produz.

A ordem importa porque cada estágio é um filtro. Não faz sentido abrir uma conexão SMTP para checar uma caixa postal em um domínio que não tem servidor de e-mail, e não faz sentido consultar o DNS desse domínio se o endereço nem tem um @. Eliminações baratas primeiro; a pergunta cara por último.

Estágio 1 — Sintaxe#

A primeira checagem é se a string é, de fato, um endereço de e-mail estruturalmente válido: um único @, uma parte local razoável, um domínio com cara de domínio. Isso pega os erros de digitação grosseiros — vírgulas soltas, espaços, um TLD faltando, dois sinais de @ — e é instantâneo e gratuito porque nunca sai do processo.

A validação de sintaxe é necessária, mas fraca por si só. definitely-not-real@some-made-up-domain.com tem sintaxe perfeitamente válida e é completamente indeliverável. Quem "verifica" com uma regex e para por aqui está conferindo ortografia, não entregabilidade. Uma falha neste estágio retorna undeliverable com o motivo invalid_email.

Estágio 2 — Domínio e registros MX#

Em seguida, o verificador pergunta ao DNS se o domínio consegue receber correio de alguma forma: ele resolve? Publica registros MX (ou um fallback utilizável por registro A) apontando para um servidor de e-mail? Um domínio sem rota de correio não consegue aceitar mensagens para ninguém, então este estágio elimina domínios inteiramente mortos em uma única consulta — nomes de empresa digitados errado, domínios expirados e TLDs inventados.

Um domínio que falha aqui retorna undeliverable com o motivo invalid_domain. Um domínio que passa tem uma rota para correio; ele ainda não provou que a sua caixa postal específica existe. Isso ainda está quatro estágios à frente.

Estágio 3 — Domínios descartáveis#

Alguns domínios existem apenas para distribuir caixas de entrada descartáveis — os endereços de dez minutos que as pessoas usam para pegar um código de desconto e nunca mais checam. A Qualisend compara o domínio com uma lista mantida de provedores descartáveis. Um acerto não significa que o endereço não vá aceitar correio hoje; significa que o endereço será inútil amanhã, então ele é sinalizado e tem a pontuação reduzida em vez de ser considerado confiável.

Um endereço descartável é reportado como risky com o motivo low_quality e uma sub-flag de descartável. A questão relacionada de enviar ou não para ele é uma decisão à parte — abordada em endereços de função, descartáveis e gratuitos.

Estágio 4 — Contas de função#

Um endereço de função é uma caixa postal compartilhada — info@, support@, billing@ — lida por uma equipe ou por um sistema de tíquetes, e não por uma pessoa. Em geral, esses endereços são reais e deliveráveis, mas se comportam mal em marketing: nenhum ser humano é dono deles, distorcem as métricas de engajamento e atraem reclamações de spam. Por isso o verificador os detecta (sem diferenciar maiúsculas de minúsculas e ignorando qualquer sufixo +tag) e os sinaliza em vez de tratá-los como uma caixa de entrada pessoal.

Um endereço de função permanece deliverable, mas carrega uma sub-flag de função, para que você decida se ele cabe em um determinado envio. Novamente, a decisão de enviar ou suprimir tem seu próprio guia.

Estágio 5 — Detecção de erros de digitação#

Antes de gastar um ida e volta de rede, o verificador checa se o domínio é uma quase-coincidência de um provedor comum — gmial.com para gmail.com, hotmial.com para hotmail.com — usando a distância de edição de Damerau-Levenshtein (o algoritmo que conta inserções, exclusões, substituições e transposições). Quando encontra um provável erro de digitação, ele apresenta uma sugestão de "você quis dizer", o que é muito mais útil do que uma rejeição seca: no cadastro, permite oferecer a correção em tempo real e salvar o inscrito em vez de perdê-lo.

A detecção de erros de digitação é uma sugestão, não um veredito por si só — mas é um dos estágios de maior alavancagem, porque pegar o erro na captura evita, em um único passo, um hard bounce e um contato perdido.

Estágio 6 — A sondagem SMTP da caixa postal#

Tudo até aqui é local e instantâneo. Este é o estágio que de fato custa algo: o verificador abre uma conexão com o servidor de e-mail do domínio e inicia a conversa de entrega — HELO, MAIL FROM, RCPT TO:<address> — e então lê a resposta do servidor sem nunca enviar uma mensagem. A resposta ao RCPT TO é a coisa mais próxima de uma resposta real sobre se a caixa postal existe:

• 250/251 → o servidor aceita o destinatário → deliverable, accepted_email
• classe 550 → rejeição permanente, usuário inexistente → undeliverable, rejected_email
• 4xx → um adiamento temporário, geralmente greylisting → nova tentativa e, se persistir, unknown
• qualquer outra coisa, ou um timeout → unknown

Este estágio também lê o texto e os códigos da resposta para duas condições especiais: uma mensagem 452/552 ou "over quota" significa que a caixa postal existe, mas está cheia (risky), e uma mensagem de "disabled/suspended" significa que a conta está morta (undeliverable). A gramática completa dessas respostas tem sua própria referência: códigos de resposta SMTP explicados.

Estágio 7 — Detecção de catch-all#

Um 250 do SMTP só significa algo se o servidor tivesse dito não a um endereço inexistente. Por isso, junto com o seu endereço, o verificador sonda uma caixa postal deliberadamente sem sentido no mesmo domínio. Se o servidor aceitar essa também, o domínio é catch-all — aceita tudo — e o 250 do seu endereço não prova nada. Esse endereço é reportado como risky com o motivo low_deliverability e uma flag de catch-all, nunca arredondado para cima como deliverável.

Este é o estágio mais deturpado do setor, e é por isso que ele tem seu próprio pilar. O resumo honesto: uma caixa postal por trás de um domínio catch-all é inconfirmável, e nenhuma pontuação muda isso.

Estágio 8 — Pontuação e o veredito#

O estágio final combina todos os sinais — o veredito do SMTP, as sub-flags, a reputação do domínio, se a caixa postal está em um provedor gratuito — em um único status (deliverable | risky | undeliverable | unknown), um código de motivo e uma pontuação de confiança de 0 a 100. O status diz o que fazer; o motivo e as sub-flags dizem por quê; a pontuação ordena os endereços dentro de um mesmo status. E, o mais importante, todo veredito vem acompanhado de sua evidência — o provedor de MX, o detalhe da sondagem — para que o número seja auditável em vez de uma caixa-preta.

O que os oito estágios ainda não conseguem te dizer#

Um pipeline tão completo pode dar a impressão de que deveria produzir um sim ou não limpo para cada endereço. Não produz, e vale a pena expor com clareza os limites honestos:

• Um domínio catch-all limita a certeza a "risky". Quando o estágio 7 encontra um servidor que aceita tudo, o 250 do estágio 6 não informa nada — a caixa postal é inconfirmável, não importa quantos estágios rodaram. Nenhum verificador resolve isso sem enviar, e qualquer um que afirme resolver está chutando.
• Um servidor com greylisting ou limitação de taxa pode forçar um unknown. Se o estágio 6 só recebe um adiamento 4xx dentro do orçamento de tempo, o veredito honesto é unknown — tente de novo mais tarde — e não um válido ou inválido fabricado.
• A verificação é um instantâneo. Um endereço confirmado como deliverável hoje pode se deteriorar amanhã, quando alguém deixa um emprego ou abandona uma caixa de entrada. É por isso que relimpar antes de envios importantes faz diferença, e por que uma taxa de bounce subindo é um sinal para verificar de novo.
• Engajamento é a única coisa que a verificação não consegue medir. Um endereço deliverável que nunca abre nada é um passivo de entregabilidade que o pipeline não enxerga. A verificação te diz que um endereço pode receber correio, não que o dono dele quer o seu correio.

Nenhuma dessas é uma falha do pipeline — são as fronteiras do que qualquer verificação pode saber. Uma ferramenta que finge que essas fronteiras não existem é a que você deve desconfiar.

Por que o verificador gratuito para no estágio 5#

Nosso verificador de e-mail gratuito roda os estágios 1 a 5 — os locais — e para deliberadamente antes da sondagem SMTP. Isso não é uma versão capada do produto; é uma fronteira honesta. Os estágios 1–5 conseguem descartar um endereço (sintaxe ruim, sem rota de correio, descartável, erro de digitação óbvio), mas não conseguem confirmar uma caixa postal nem detectar catch-all, porque isso exige abrir uma conversa SMTP real a partir de um IP com boa reputação. Qualquer ferramenta gratuita de navegador que afirme confirmar caixas postais ativas ou não está fazendo o estágio 6 ou não está sendo honesta sobre isso. O trade-off entre completo e gratuito tem sua própria análise.

Perguntas frequentes#

Verificar um e-mail envia uma mensagem para ele?#

Não. A sondagem SMTP no estágio 6 conduz a conversa de entrega até o ponto em que o servidor aceita ou rejeita o destinatário e, então, encerra a conexão sem emitir o comando DATA que transmitiria a mensagem. O dono da caixa postal não vê nada. Enviar um e-mail de "teste" de verdade para checar a validade é exatamente a má prática que uma verificação adequada evita.

Por que a verificação simplesmente não pode ser instantânea?#

Os estágios 1–5 são instantâneos porque são locais. O estágio 6 exige uma conversa pela rede com um servidor de e-mail de terceiros que você não controla — um que pode te aplicar greylisting, limitar sua taxa de requisições ou responder devagar de propósito. Esse ida e volta é o preço de uma resposta de verdade, e é por isso que os processos em massa rodam de forma assíncrona em vez de travar em cada endereço.

Qual é a diferença entre o status e a pontuação?#

O status (deliverable | risky | undeliverable | unknown) é a decisão; a pontuação (0–100) ordena os endereços dentro de um mesmo status para você priorizar. Um endereço deliverável em um provedor gratuito pontua diferente de um em um domínio corporativo, mas ambos são deliveráveis. Use o status para decidir e a pontuação para ordenar.

Quais estágios a API expõe?#

Todos eles. Um resultado de verificação retorna o status final e o motivo, além das sub-flags (catch-all, descartável, função, gratuito, caixa-cheia) e a sugestão de "você quis dizer", para que o seu próprio código possa agir sobre a evidência em vez de apenas sobre o veredito. Veja a documentação para desenvolvedores e — se você está escolhendo entre provedores — a comparação de APIs de verificação de e-mail.