Resultados da verificação de e-mail: válido, inválido, arriscado e desconhecido

Todo verificador de e-mail classifica os endereços em cerca de quatro resultados: válido (o servidor de e-mail confirmou a caixa postal), inválido (rejeitado, sem servidor de e-mail ou com sintaxe quebrada), arriscado (alcançável, mas impossível de confirmar, geralmente catch-all) e desconhecido (nenhuma resposta utilizável). As palavras mudam de fornecedor para fornecedor. As decisões por trás delas, não, e é isso que este guia mapeia.

Se você já migrou uma lista de uma ferramenta para outra e viu que as colunas não batiam, o motivo é este. Lemos a documentação de resultados de oito serviços de verificação em 1º de outubro de 2026 e alinhamos os rótulos de cada um lado a lado.

Os quatro resultados por trás de todo rótulo

Cada status é, na verdade, a resposta a uma única pergunta: o que o servidor de e-mail do destinatário disse, se é que disse algo? A verificação funciona abrindo uma conversa SMTP com o servidor e perguntando pela caixa postal na etapa RCPT TO, sem enviar mensagem nenhuma. Explicamos a mecânica em como verificar um e-mail sem enviar nada.

Resultado	O que o servidor fez	Causa típica
Válido	Aceitou o endereço e rejeitou um endereço inventado no mesmo domínio	Uma caixa postal real e funcionando
Inválido	Rejeitou o endereço, ou não havia servidor a quem perguntar	Erro de digitação, caixa postal excluída, domínio morto, sintaxe errada
Arriscado	Aceitou o endereço, mas também aceitou um inventado	Domínio catch-all, caixa postal cheia, provedor descartável (depende do fornecedor)
Desconhecido	Não deu nenhuma resposta utilizável	Timeout, greylisting, conexão recusada, sistema antispam

A distinção que as pessoas mais deixam passar é entre os dois últimos. Arriscado significa que o verificador recebeu uma resposta, e a resposta não queria dizer nada. Desconhecido significa que ele não recebeu resposta alguma. Um é uma característica do domínio e não vai mudar se você verificar de novo amanhã. O outro é uma tentativa que falhou e, muitas vezes, vai mudar.

Como oito fornecedores nomeiam os mesmos resultados

Os mesmos quatro resultados aparecem em pelo menos cinco vocabulários diferentes. Esta tabela mapeia os rótulos de cada fornecedor, tirados da documentação da API de cada um (fontes com link abaixo da tabela).

Fornecedor	Válido	Inválido	Catch-all	Desconhecido	Outros rótulos de primeiro nível
ZeroBounce	valid	invalid	catch-all	unknown	spamtrap, abuse, do_not_mail
NeverBounce	valid	invalid	catchall	unknown	disposable
Kickbox	deliverable	undeliverable	risky (com a flag accept_all)	unknown	nenhum
Bouncer	deliverable	undeliverable	risky (motivo low_deliverability)	unknown	nenhum
Hunter	valid	invalid	accept_all	unknown	webmail, disposable
Clearout	valid	invalid	catch_all	unknown	flag safe_to_send: yes / risky / no / unknown
DeBounce	5 Valid	6 Invalid	4 Accept-All	7 Unknown	1 Syntax, 2 Spam Trap, 3 Disposable, 8 Role
EmailListVerify	ok	email_disabled, dead_server, invalid_mx, invalid_syntax	ok_for_all	unknown	antispam_system, smtp_protocol, disposable, spamtrap

Fontes: códigos de status da ZeroBounce, verificação individual da NeverBounce, README do SDK Ruby oficial da Kickbox, terminologia da Bouncer, referência da API do Hunter, visão geral da Clearout, códigos de resultado da DeBounce e a especificação OpenAPI publicada pela EmailListVerify em api.emaillistverify.com/api-doc.

Onde os fornecedores realmente discordam

A maioria dos rótulos tem tradução direta, mas três categorias caem em baldes diferentes dependendo da ferramenta. Se você comparar os percentuais de resumo de dois verificadores sem saber disso, vai tirar a conclusão errada.

Endereços descartáveis

Um endereço descartável, como um do Mailinator, normalmente tem uma caixa postal funcionando. Só que ninguém vai ler.

• NeverBounce, Hunter, DeBounce e EmailListVerify dão a ele um status próprio de primeiro nível.
• ZeroBounce o classifica em do_not_mail, com o substatus disposable.
• Bouncer o classifica como arriscado (risky), motivo low_quality.
• Kickbox o retorna com uma flag disposable junto do resultado principal.

Ou seja, uma lista limpa na Bouncer vai mostrar uma fatia maior de arriscados do que a mesma lista na NeverBounce, sem nenhuma diferença nos dados de fato. Você mesmo pode checar qualquer domínio com o verificador de e-mails descartáveis.

Endereços de função

info@, sales@ e support@ são caixas postais reais, então a maioria das ferramentas retorna o veredito da caixa postal e acrescenta uma flag de função (role). Duas não fazem assim: a DeBounce dá às contas de função um código próprio (8, que ela rotula como "Maybe, Not recommended", ou seja, "talvez, não recomendado"), e a ZeroBounce as move para do_not_mail com o substatus role_based. Se você deve ou não enviar para elas é outra questão, tratada em vale a pena enviar para info@ e sales@?.

Catch-all marcado como válido

Este é o ponto de atenção. O status valid da ZeroBounce tem um substatus chamado accept_all, que a documentação descreve como endereços que "belong to domains on the ZeroBounce accept_all list" (pertencem a domínios da lista accept_all da ZeroBounce). Isso é diferente do status de primeiro nível catch-all, que ela descreve como "impossible to validate without sending a real email and waiting for a bounce" (impossível de validar sem enviar um e-mail real e esperar um bounce). Se você filtrar só pelo status de primeiro nível, alguns endereços accept-all vão junto com os válidos. Leia a coluna de substatus antes de importar.

O Hunter tem uma versão mais discreta do mesmo problema. O status webmail dele cobre endereços em provedores como Gmail e Outlook, e a documentação diz que, para endereços webmail e descartáveis, "we provide an arbitrary score of 50" (atribuímos uma pontuação arbitrária de 50). webmail informa quem hospeda a caixa postal, não se ela existe.

O que fazer com cada resultado

Envie para os válidos, exclua os inválidos, segure os arriscados e verifique de novo os desconhecidos. Essa é a política inteira, com alguns ajustes.

Resultado	Ação	Por quê
Válido	Enviar	O servidor confirmou a caixa postal
Inválido	Excluir e colocar na lista de supressão para nunca ser reimportado	Vai dar hard bounce
Descartável	Excluir das listas de marketing	Nenhum ser humano vai ler
Spam trap (quando sinalizado)	Excluir	Cair em uma prejudica a reputação de remetente muito mais do que um bounce
Arriscado / catch-all	Enviar separadamente, em lotes pequenos, só se o endereço veio de uma fonte confiável	Impossível de confirmar, não necessariamente ruim
Desconhecido	Verificar de novo depois de 24 a 48 horas	Muitas vezes é uma falha temporária, como greylisting
Função (role)	Decisão sua, conforme o caso de uso	Caixa postal real, risco maior de reclamação

Duas observações sobre essa tabela.

Válido tem prazo de validade. A documentação da Clearout diz que a garantia de "safe to send" (seguro para enviar) só vale se você enviar "within 24 hours of the verification time" (em até 24 horas após a verificação), e a ZeroBounce descreve os endereços válidos como tendo "a very low bounce rate of under 2%" (uma taxa de bounce muito baixa, abaixo de 2%). As duas afirmações são dos próprios fornecedores, sem auditoria independente, mas concordam no que importa: um resultado válido descreve a caixa postal no dia em que você verificou. Veja com que frequência verificar sua lista de novo.

Catch-all precisa de uma política própria. Muitas vezes é o maior balde não válido de uma lista B2B, e excluí-lo de vez joga fora pessoas reais. Escrevemos um critério de decisão para enviar a endereços catch-all.

Desconhecido é para tentar de novo, não um veredito

Desconhecido significa que a verificação não chegou ao fim, então a resposta certa é rodá-la de novo, e não decidir. Os substatus que os fornecedores publicam deixam as causas claras. A ZeroBounce lista greylisted, timeout_exceeded, mail_server_did_not_respond, failed_smtp_connection e antispam_system. A Bouncer lista timeout, unavailable_smtp, dns_error e unsupported. A Kickbox lista no_connect, timeout e unavailable_smtp.

A maioria dessas causas é temporária. Um servidor com greylisting rejeita a primeira tentativa de um remetente desconhecido com um código temporário 4xx e aceita uma tentativa posterior. Um servidor sobrecarregado dá timeout uma vez e responde na próxima.

Existe uma causa de desconhecido que é culpa do verificador, e não do destinatário: a própria rede do verificador não consegue alcançar a porta 25. Medimos isso na nossa própria infraestrutura no texto sobre provedores de nuvem que bloqueiam a porta 25. Um verificador nessa situação deveria retornar desconhecido ou arriscado para tudo o que não conseguiu checar. Um verificador que retorna válido em vez disso comete a falha descrita em como saber se o seu verificador de e-mail está mentindo.

Como os três status do SimpleVerifier se encaixam

Retornamos três status em vez de quatro, e vale deixar explícito para onde vai cada coisa:

• valid (válido): o servidor de e-mail do destinatário confirmou a caixa postal.
• invalid (inválido): o servidor rejeitou a caixa postal, a sintaxe está errada, o domínio não tem servidor de e-mail ou o domínio está na nossa lista de 8.740 provedores descartáveis.
• risky (arriscado): o domínio funciona, mas não foi possível confirmar a caixa postal. Isso inclui domínios catch-all e servidores que não responderam, então tanto "arriscado" quanto "desconhecido" da tabela de fornecedores acima caem aqui.

Endereços de função recebem uma flag junto do status, em vez de substituí-lo. Tudo o que não conseguimos confirmar é retornado como arriscado, nunca como válido. Falhas transitórias são verificadas de novo, em vez de ficarem guardadas em cache como veredito.

Na prática

Ao abrir um arquivo de resultados, faça três coisas antes de importar qualquer coisa:

1. Traduza os rótulos para válido / inválido / arriscado / desconhecido usando a tabela acima, para não comparar as categorias de dois fornecedores como se fossem equivalentes.
2. Leia a coluna de substatus ou de motivo, não só o status principal. O catch-all dentro do válido e o descartável dentro do arriscado se escondem ali.
3. Rode de novo os desconhecidos um dia depois, antes de decidir qualquer coisa sobre eles.

Se quiser ver como um único endereço é classificado antes de rodar um arquivo inteiro, o verificador de e-mail individual gratuito mostra o status e o motivo.