Como verificar um endereço de e-mail antes de enviar

Um e-mail devolvido informa algo que muitas vezes você poderia ter descoberto antes de enviar: que o endereço não existe. No cold outreach, em que os endereços vêm de sites, diretórios e cartões de visita, e não de formulários de cadastro, uma parte de qualquer lista estará desatualizada.

Este guia é para quem está prestes a enviar e-mails para uma lista que não construiu por opt-in — equipes de vendas, fundadores, agências. Nós, do Outreach, explicamos as três verificações que dizem se um endereço pode receber e-mails, onde essas verificações deixam de funcionar e como ler os códigos de devolução que você recebe quando uma mensagem falha mesmo assim.

A resposta curta logo de início: normalmente dá para confirmar que um endereço existe sem enviar um e-mail para ele, mas nem sempre — e saber quando você não consegue saber é tão útil quanto a própria resposta.

Por que verificar endereços de e-mail antes de enviar?

Porque os provedores de e-mail pedem que os remetentes removam endereços inválidos, e cada devolução é uma mensagem que não chegou a ninguém. As melhores práticas do Sender Hub do Yahoo dizem: “Remova prontamente os destinatários inválidos da sua lista.” As diretrizes para remetentes de e-mail do Google dizem para “cancelar automaticamente a inscrição de destinatários que tiveram várias mensagens devolvidas” e: “Se as mensagens começarem a ser devolvidas ou adiadas, reduza o volume de envio até que a taxa de erros SMTP diminua.”

Em termos simples: os provedores observam como você lida com endereços ruins. Verificar antes de enviar significa menos devoluções para tratar depois e uma visão mais limpa de quantas pessoas reais a sua campanha alcançou.

Quais são as etapas para verificar um endereço de e-mail?

Três verificações, em ordem: o endereço está bem formado, o domínio dele tem um servidor de e-mail e esse servidor diz que a caixa de e-mail existe? Cada etapa pega problemas que a anterior não consegue.

Passar na etapa 3 é o sinal mais forte que você pode obter sem enviar. Mas, como veremos, alguns servidores dão a mesma resposta para todos os endereços, reais ou não.

Como verificar a sintaxe de um e-mail?

Confirme que há exatamente um @, uma parte com aparência válida antes dele e um domínio real depois — dentro dos limites de tamanho do padrão SMTP. A RFC 5321 define em 64 octetos “o comprimento total máximo de um nome de usuário ou de outra parte local” (a parte antes do @), e o comprimento máximo do domínio em 255 octetos.

As verificações de sintaxe pegam o óbvio: sales@@example.com, info@example, um espaço no final copiado de uma página da web ou uma vírgula digitada no lugar de um ponto. Elas são baratas e instantâneas, então sempre execute-as primeiro. O que elas não conseguem dizer é se há alguém por trás do endereço. jane.doe@example.com está perfeitamente formado, quer a Jane trabalhe ali ou não.

Como funciona uma consulta MX?

Ela pergunta ao DNS qual servidor recebe e-mails do domínio; se não houver nenhum, nenhum endereço desse domínio pode receber e-mails. O registro MX (mail exchanger) aponta para o servidor que aceita e-mails de um domínio. Consultá-lo mostra se o domínio está configurado para receber e-mails.

Três resultados possíveis, segundo os padrões:

• Registros MX encontrados. O domínio tem um servidor de e-mail — passe para a etapa 3.
• O domínio não existe. A RFC 5321 diz: “Se um erro de domínio inexistente for retornado, essa situação DEVE ser relatada como erro.” O endereço está morto.
• Não há registro MX, mas o domínio existe. A RFC 5321 diz que o endereço “é tratado como se estivesse associado a um MX implícito” — o e-mail vai para o registro de endereço do próprio domínio. Portanto, a falta de um MX não é automaticamente um beco sem saída.

Também existe um sinal explícito de “não aceitamos e-mails”. A RFC 7505 define um “null MX” — um único registro MX com preferência 0 e um “.” como nome do servidor — que “fará com que todas as tentativas de entrega de e-mail para um domínio falhem imediatamente.” Se você o vir, pare: o domínio declarou que não recebe e-mails.

Como funciona a verificação SMTP da caixa de e-mail sem enviar um e-mail?

O verificador se conecta ao servidor de e-mail do domínio e inicia uma entrega, indica o destinatário, lê a resposta do servidor e depois se desconecta antes de enviar qualquer conteúdo de mensagem. Em termos de SMTP: conectar, EHLO, MAIL FROM, RCPT TO:<address>, ler o código de resposta e depois QUIT — a etapa DATA, em que a mensagem de fato iria, nunca acontece.

A resposta ao RCPT TO é o que importa. A RFC 5321 define os códigos:

Por que não perguntar diretamente ao servidor com o comando VRFY? Porque os servidores podem desativá-lo. A seção 7.3 da RFC 5321 permite que os sites desativem o VRFY por motivos de segurança e diz que um servidor que faz isso “DEVE retornar uma resposta 252” — uma resposta que não significa nem sim nem não. É por isso que os verificadores usam o caminho do RCPT TO.

Nos nossos próprios testes de setembro de 2026, o método RCPT identificou corretamente todos os 6 endereços de um pequeno conjunto conhecido: 3 endereços que sabíamos que tinham sido devolvidos, 2 endereços funcionando e 1 em um domínio catch-all que marcamos corretamente como não confirmável.

O que é um domínio catch-all e por que ele não pode ser verificado?

Um domínio catch-all aceita e-mails para qualquer endereço — real ou inventado —, então o servidor dele responde “250 OK” para todo destinatário, e uma verificação antes do envio não descobre nada. Algumas empresas configuram o e-mail assim para que endereços digitados errado ainda cheguem a alguém. Outras usam gateways que aceitam tudo primeiro e organizam depois.

Você detecta um catch-all perguntando ao servidor sobre um endereço que quase certamente não existe, como uma longa sequência aleatória no mesmo domínio. Se o servidor aceitar esse também, todo “sim” dele não tem significado.

Qual é a frequência disso? Em um teste de setembro de 2026, nós, do Outreach, enviamos verificações RCPT com endereços inventados a 25 domínios de e-mail extraídos de 200 contatos de empresas que tínhamos coletado (principalmente empresas coreanas). Cerca de 74% dos domínios responderam com honestidade e rejeitaram o endereço falso; cerca de 25% o aceitaram — eram catch-all. Trate isso como uma amostra de um mercado, e não como uma taxa universal. O ponto é que isso não é raro.

Para endereços catch-all, o resultado honesto é “não conseguimos verificar.” A única forma de descobrir é enviar, e isso é uma questão de julgamento: um endereço publicado no próprio site da empresa é uma aposta melhor do que um adivinhado a partir de um padrão de nome.

Por que alguns servidores de e-mail se recusam a fazer verificações?

Alguns servidores de e-mail limitam quem pode perguntar sobre destinatários, então, em vez de responder, eles atrasam, rejeitam temporariamente ou derrubam a conexão. As recusas costumam ter este aspecto:

• Uma resposta temporária 4xx para todo destinatário, pedindo que você tente de novo mais tarde.
• Uma resposta 5xx que se refere a política ou reputação, e não à caixa de e-mail — por exemplo, um código aprimorado 5.7.1, que a RFC 3463 descreve como “Entrega não autorizada, mensagem recusada.”
• Nenhuma resposta, ou uma conexão que cai.

Nenhuma dessas respostas diz se a caixa de e-mail existe. Um bom verificador as informa como “desconhecido”, e não como “inválido” — marcar um endereço real como morto porque o servidor dele foi cauteloso descartaria um bom contato.

Alguns provedores de hospedagem também bloqueiam conexões de saída na porta 25, a porta do SMTP, o que significa que um verificador executado ali não consegue alcançar nenhum servidor de e-mail. Novamente, a resposta certa nesse caso é “não é possível verificar,” e não “não existe.”

Como ler os códigos de devolução depois do envio?

Olhe o primeiro dígito do código de status aprimorado: 5 significa permanente, 4 significa temporário. Depois, o dígito do meio diz que tipo de problema é. A RFC 3463 define códigos no formato class.subject.detail:

• 5.x.x — Falha permanente: “improvável de ser resolvida reenviando a mensagem na forma atual.”
• 4.x.x — Falha transitória persistente: “o envio no futuro pode ter sucesso.”

Os códigos que você mais verá quando o problema é o endereço:

Essa última linha importa. Um código 5.7.x geralmente significa que o servidor receptor recusou você, e não que a caixa de e-mail não existe. Verifique a sua configuração de SPF, DKIM e DMARC antes de excluir o contato.

Como verificar um único endereço gratuitamente?

Digite-o no nosso verificador gratuito de endereços de e-mail; ele executa as verificações de sintaxe, MX e caixa de e-mail e informa um de três resultados. Não é preciso se cadastrar. O verificador está disponível em inglês e coreano; digite o endereço que você quer verificar. O resultado é um destes:

• Pode receber e-mails — o servidor de e-mail aceitou o destinatário.
• Não existe — o endereço não está bem formado, o domínio não tem servidor de e-mail ou o servidor disse que não há essa caixa de e-mail.
• Não conseguimos verificar — o domínio é catch-all, o servidor recusou a verificação ou nenhuma verificação foi possível. A ferramenta informa qual foi o motivo.

Para evitar que a ferramenta seja usada para sondagens em massa, ela permite um número limitado de verificações por dia. Para uma lista inteira, verifique dentro do seu fluxo de envio, em vez de um endereço por vez.

O que fazer com os endereços que não podem ser verificados?

Mantenha-os separados, envie para eles em lotes menores e remova os que forem devolvidos com um código 5.x.x. Uma ordem prática:

1. Descarte tudo o que falhar na sintaxe ou não tiver servidor de e-mail.
2. Remova os endereços que o servidor disse que não existem.
3. Envie primeiro para os endereços confirmados.
4. Envie com mais cautela para os endereços marcados como “não conseguimos verificar” e remova os que voltarem com uma devolução permanente — como o Yahoo e o Google recomendam.

Lembre-se também de que um endereço válido não significa um destinatário disposto. As denúncias de spam contam contra você, o endereço existindo ou não; tratamos dos números em por que os cold emails caem no spam.

Resumindo

• Verifique em três etapas: sintaxe → consulta MX → verificação SMTP da caixa de e-mail (RCPT, sem enviar conteúdo).
• A parte antes do @ pode ter no máximo 64 caracteres (RFC 5321); um null MX significa que o domínio não recebe e-mails (RFC 7505).
• Os domínios catch-all aceitam todos os endereços — no nosso teste com 25 domínios, cerca de 25% o faziam — então alguns endereços só podem ser marcados como “não conseguimos verificar.”
• Nas devoluções, 5.x.x é permanente e 4.x.x é temporário; 5.1.1 significa que a caixa de e-mail não existe; 5.7.x aponta para um problema de política, e não de endereço inválido.
• Experimente um único endereço com o nosso verificador gratuito de e-mail.