Como saber se o seu verificador de e-mail está mentindo para você

A verificação de e-mail tem um problema incomum: não é fácil saber se ela funcionou.

Se um verificador diz que um endereço é válido e você envia para ele, só descobre semanas depois, pela sua taxa de bounce (devolução). A essa altura o estrago já está feito: reputação de remetente, entregabilidade, um domínio queimado. Toda ferramenta da categoria anuncia "99% de precisão", e quase ninguém confere.

Aqui está um teste que leva cerca de um minuto, e o que descobrimos quando o rodamos no nosso próprio produto.

O teste

Invente um endereço que não tem como existir, num provedor que você sabe que rejeita caixas postais desconhecidas:

definitely-not-real-xyz9987661@gmail.com

O Gmail rejeita destinatários desconhecidos na camada SMTP com uma resposta 550. Isso não é um palpite sobre o comportamento do Gmail. É observável, e é todo o mecanismo sobre o qual a verificação é construída.

Então existe exatamente uma resposta correta: inválido.

Envie esse endereço ao seu verificador. Se voltar válido, a ferramenta não checou a caixa postal. Ela olhou o domínio, viu gmail.com e presumiu.

Falhamos no nosso próprio teste

Nós construímos este produto. Quando passamos aquele endereço pelo nosso próprio motor, ele retornou:

definitely-not-real-xyz9987661@gmail.com  →  valid  ("Verified")

Não "arriscado". Não "desconhecido". Verificado.

Duas coisas no nosso próprio código causaram isso, e vale entender as duas, porque são erros fáceis de cometer.

O atalho dos provedores. O motor tinha uma lista dos principais provedores (Gmail, Yahoo, Outlook, iCloud e assim por diante) e retornava válido para qualquer endereço bem formatado num deles, sem nunca abrir uma conexão SMTP. O raciocínio era que esses domínios com certeza aceitam e-mail. Isso vale para o domínio e não diz nada sobre a caixa postal. Numa lista típica de consumidores, esse único atalho carimba como aprovada uma grande parte de todo arquivo que você envia.

O fallback de falha. Quando a checagem SMTP rodava e falhava por qualquer motivo (timeout, porta bloqueada, conexão recusada), o código caía num padrão de válido, com a lógica de que sintaxe válida mais um servidor de e-mail válido provavelmente significam um endereço real.

Esse segundo erro pesa mais do que parece, por causa de onde a verificação costuma rodar.

A maioria dos provedores de nuvem bloqueia a porta de que a verificação precisa

Checar uma caixa postal significa conectar ao servidor de e-mail do destinatário na porta 25. Quase todo grande provedor de nuvem bloqueia a porta 25 de saída por padrão, para conter spam. Medimos em dois:

Hospedagem	Porta 25 de saída
Railway	Bloqueada
DigitalOcean	Bloqueada

Junte esses dois fatos. Se um verificador roda numa infraestrutura que bloqueia a porta 25 e o código dele assume válido quando a checagem SMTP falha, então todo endereço num domínio ativo volta como válido, e a ferramenta não verificou absolutamente nada enquanto informa confiança total.

Não é uma falha hipotética. Foi o que o nosso próprio código fez até corrigirmos.

Como é um resultado honesto

A correção não é uma sondagem mais esperta. É estar disposto a dizer "não sei".

Um verificador deveria retornar três estados, e o do meio é o importante:

• válido: um servidor de e-mail confirmou que esta caixa postal existe
• inválido: um servidor de e-mail a rejeitou, o domínio não tem servidor de e-mail, a sintaxe está quebrada ou é um endereço descartável
• arriscado: não foi possível concluir a checagem

Arriscado é a resposta honesta para casos realmente ambíguos, e há vários:

Domínios catch-all aceitam todo endereço do domínio, real ou não, então qualquercoisa@dominiodeles.com retorna aceitação. Ali, a verificação não consegue distinguir uma caixa postal real de um erro de digitação. Qualquer ferramenta que responde válido num domínio catch-all está informando a configuração do domínio, não a caixa postal.

Provedores que escondem o status da caixa postal. Alguns grandes provedores para consumidores, entre eles Yahoo e iCloud, se recusam a dar uma resposta clara para destinatários desconhecidos na etapa RCPT, então uma sondagem contra eles muitas vezes é inconclusiva. A Microsoft não está nesse grupo: tanto o Outlook.com quanto o Microsoft 365 rejeitam destinatários desconhecidos durante a conversa SMTP.

Conexões bloqueadas ou recusadas, como acima.

Hoje o nosso motor retorna inválido para aquele endereço inventado do Gmail, com o motivo Mailbox not found. Tudo o que ele não consegue confirmar vai para arriscado, e nunca para válido.

Como testar o verificador que você usa

Monte um arquivo pequeno com endereços cujas respostas você já conhece:

1. Um endereço inventado no gmail.com: tem que dar inválido
2. O seu próprio endereço real: tem que dar válido
3. Algo sem @: tem que dar inválido
4. Um endereço num domínio descartável como mailinator.com: deveria dar inválido
5. Um endereço num domínio sem nenhum servidor de e-mail: tem que dar inválido
6. Um endereço de função como info@ numa empresa real: deveria ser marcado como arriscado ou como endereço de função

Seis linhas. Qualquer verificador que valha o que custa acerta as seis, e a primeira é a que flagra o chute.

Se o seu fornecedor responde válido na linha 1, você não está comprando verificação. Está comprando um verificador de sintaxe com tom confiante, e vai descobrir a diferença pela sua taxa de bounce.

Por que publicamos isto

Teria sido fácil corrigir o bug em silêncio. Escrevemos sobre ele porque o teste é mais útil que a promessa: você não deveria acreditar na nossa palavra sobre a nossa precisão, assim como não deveria acreditar na de ninguém.

Rode as seis linhas contra nós. Rode contra quem você usa hoje. Os resultados vão dizer mais que qualquer percentual de precisão numa página de preços.