Verificação de emails em massa: limpar antes de enviar

O essencial Um verificador em massa passa cada linha do ficheiro por uma série de testes — formato do endereço, registos de correio, uma conversa SMTP real, listas de endereços de função e de domínios descartáveis — e devolve uma palavra. Essa palavra esconde muito mais confusão do que deixa ver. Uma única passagem SMTP é uma amostra, não é um veredicto. O greylisting responde «volte mais tarde» por desenho (RFC 6647), o Gmail responde 421 4.7.28 quando o volume lhe parece anormal, e os servidores que aceitam tudo dizem sim a qualquer endereço. A Enrow faz mais de 10 verificações por email, com várias passagens SMTP e várias sondagens de catch-all a partir de servidores em regiões diferentes. As linhas que a maioria das ferramentas deita fora sem alarido são os catch-all. Marcados «arriscados», removidos, desaparecidos. A Enrow verifica-os e entrega-os como válidos. O Amazon SES põe a conta em revisão a partir de 5% de bounce e pode suspender os envios aos 10%. Uma lista verificada não chega perto de nenhum desses dois valores. Uma verificação custa 0,25 crédito na Enrow, e os 50 créditos gratuitos de cada mês dão para 200 verificações.

Verificar emails em massa é passar o ficheiro inteiro por um verificador antes de qualquer campanha lhe tocar. Carrega-se um CSV, devolvem-no com um estado em cada linha, apagam-se as linhas más. É aqui que quase toda a gente pára de ler. E é aqui que se perde dinheiro.

Essa palavra de estado carrega muito mais do que parece. Por trás de «válido» está uma conversa com um servidor de correio que pode ter dito a verdade ou não. Por trás de «arriscado» está um domínio que responde sim a tudo, o que não é a mesma coisa que um endereço mau. E por trás de «desconhecido» está, quase sempre, um servidor que se recusou a falar com a máquina que perguntou.

O que um verificador em massa testa, na prática

A validação faz-se em seis camadas. As duas primeiras são baratas e rápidas. É nas outras quatro que os verificadores se distinguem uns dos outros.

1. Sintaxe

A cadeia de caracteres é sequer um endereço legal? A RFC 5321 §4.5.3.1 fixa os limites: 64 octetos na parte local, 255 no domínio, 256 no caminho completo. E apanha os erros mais banais e mais letais: um espaço a mais no fim, .con em vez de .com.

Sobre entrega, não diz absolutamente nada. O postmaster@ de qualquer domínio passa em todas as expressões regulares alguma vez escritas, e a RFC 5321 obriga qualquer implementação de SMTP a aceitar essa caixa. Perfeitamente válido. Perfeitamente inútil para prospeção.

2. Domínio e registos MX

O verificador consulta os registos de mail exchanger do domínio. Sem registos, não há correio — só que a norma é mais subtil do que isso, e um verificador decente segue-a. A RFC 5321 §5.1 põe-no por escrito: quando a lista de MX vem vazia, o endereço tem de ser tratado como se lhe estivesse associado um MX implícito de preferência 0, a apontar para esse mesmo anfitrião. Um domínio sem MX mas com um registo A a funcionar não está automaticamente morto. Acontece que os sistemas de envio atuais fazem bounce a esses domínios de qualquer forma, o que os torna um sinal de aviso e não um veredicto de inválido.

3. O diálogo SMTP

É aqui que se testa a sério. O verificador abre uma ligação ao servidor de destino e começa uma entrega: identifica-se, declara um remetente, nomeia o destinatário com RCPT TO. Depois lê a resposta e pára. Não é entregue nada.

O SMTP tem um comando feito de propósito para isto, o VRFY, e na prática não serve. A RFC 5321 §3.5.2 deixa o servidor responder 252 (não consigo verificar, mas aceito e vou tentar entregar) sem confirmar coisa nenhuma, e a §7.3 deixa desligar o comando por completo. A maior parte dos servidores públicos aproveitou essa saída há anos, e os verificadores acabaram todos a sondar com RCPT TO e a ler códigos de resposta.

Interessam duas famílias de códigos (RFC 5321 §4.2.1). Uma resposta 5yz é permanente: não se repete. Uma 4yz é transitória: tenta-se outra vez mais tarde. O 550 5.1.1 do Gmail é a resposta honesta de caixa inexistente — «The email account that you tried to reach does not exist.» Já o 452 4.2.2 significa caixa cheia, ou seja uma pessoa viva com a caixa de entrada por arrumar, não um endereço inválido.

Um verificador que leia um 4yz como inválido está errado. Se o ler como válido, está errado à mesma. Quase todo o ofício está em saber lidar com essa ambiguidade.

4. Endereços de função

sales@, support@, info@, abuse@, webmaster@. Existem, chegam ao destino e estão normalizados desde 1997 pela RFC 2142, Mailbox Names for Common Services, Roles and Functions. Vão dar a uma caixa partilhada que várias pessoas leem — ou que ninguém lê.

Os verificadores assinalam-nos à parte porque entregabilidade e utilidade são duas perguntas diferentes. Um endereço de função é válido de verdade, e é ao mesmo tempo o caminho mais curto para uma queixa de spam quando a sequência foi escrita para uma pessoa com nome próprio.

5. Domínios descartáveis

Serviços de caixa temporária, os que servem para apanhar um teste gratuito sem dar o endereço verdadeiro. Aqui a deteção é uma lista de bloqueio, não é um protocolo, e a referência pública de facto é o repositório disposable-email-domains. Quem o mantém diz o limite sem rodeios: não pode garantir que todos estes domínios continuem a poder considerar-se descartáveis. Conta imenso num formulário de registo. Conta pouco em prospeção B2B.

6. Deteção de catch-all

O verificador propõe ao servidor um endereço que não tem hipótese de existir. Se esse também for aceite, o domínio aceita tudo e a resposta que deu sobre o endereço verdadeiro não vale nada. É esta camada que decide que parte da lista sobrevive.

Porque é que dois verificadores discordam sobre o mesmo endereço

O mesmo endereço volta como «desconhecido» após uma sondagem e como «válido» após mais de 10 verificações.

Passe o mesmo endereço por duas ferramentas e há dias em que recebe duas respostas diferentes. Nenhum dos dois fornecedores está a mentir. Uma passagem SMTP isolada é uma medição feita através de um canal com ruído — e o ruído tem nomes.

O greylisting é o mais barulhento de todos, e a RFC 6647 descreve-o sem rodeios. No primeiro contacto de um remetente desconhecido, o servidor devolve um 421, fecha a ligação, guarda o trio endereço IP, remetente e primeiro destinatário, e só aceita numa tentativa posterior. A própria RFC assume o preço disso: o prejuízo mais evidente do greylisting é o atraso que impõe ao correio legítimo. Um verificador que sonde uma vez apanha o adiamento e adivinha o resto.

O volume dispara outro alarme. O próprio Google publica a resposta: 421 4.7.28, «Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited.» Uma ferramenta que testa milhares de endereços alojados no Gmail a partir de um punhado de IPs bate nessa parede, e tudo o que estava atrás dela fica por resolver. E conta também de que IP vem a pergunta. As regras de remetente do Google exigem um registo de DNS inverso válido no IP de envio, com uma resolução direta que corresponda, e uma sondagem que venha de um IP sem isso é travada muito antes de se chegar à questão da caixa de correio.

A terceira fonte de ruído são os domínios que aceitam tudo. O Microsoft 365 rejeita destinatários desconhecidos logo no RCPT TO, com 550 5.4.1, quando o Directory-Based Edge Blocking está ligado. Onde essa funcionalidade não está ativa, a resposta do domínio transporta muito menos informação e o verificador fica a decidir sem dados. É este mecanismo que está na origem prática do problema dos catch-all nos domínios B2B europeus.

Daí que a Enrow não se fique por uma passagem. Cada endereço leva mais de 10 verificações, com várias passagens SMTP e várias sondagens de catch-all a partir de servidores em regiões diferentes, e o veredicto sai da diferença entre essas respostas — incluindo a forma como o domínio trata um endereço de controlo que nunca viu.

Uma sondagem apanha um adiamento e fica sem resposta. Várias, de regiões diferentes, contra um endereço de controlo, dão um veredicto.

O problema dos catch-all, e o que ele custa em oportunidades reais

Um domínio que aceita tudo recebe correio dirigido a seja o que for. jane.doe@, jne.doe@, disparate@. Tudo aceite, e depois deitado fora lá dentro ou a fazer bounce horas mais tarde, muito depois de a ligação ter fechado.

A maioria dos verificadores chega aqui e pára. Carimba a linha com «catch-all» ou «arriscado» e devolve-lhe a decisão a si. O ZeroBounce encaminha os catch-all por resolver para um produto de pontuação à parte, e admite na própria página que não é possível confirmar se o endereço pertence a uma pessoa real (fonte).

E depois quem tem a lista faz uma de duas asneiras. Apaga o segmento, e vão atrás dele umas centenas de decisores bem vivos. Ou envia para ele em bruto e engole os bounces. Nos meus ficheiros, o monte dos «arriscados» é com frequência o segundo maior a seguir aos válidos limpos, e nalgumas listas chegou a um terço das linhas. São demasiadas para se apagarem por palpite.

Um catch-all resolve-se de fora, só que não com uma sondagem. Conversas SMTP repetidas, de origens diferentes, a horas diferentes, medidas contra endereços de controlo inventados de propósito, dão um sinal que uma verificação isolada nunca dá. É desta maneira que a Enrow os resolve, e entrega-os como válidos, não como um aviso que fica à espera de decisão; como só cobra quando o resultado é válido, uma linha que não se consegue resolver não custa nada. Há domínios que nunca cedem, e o honesto é deixar essas linhas de fora. Muito menos por resolver do que numa ferramenta de passagem única. Zero é que não. Mecânica completa em o que é um email catch-all.

Como saber se um email é válido: verificar um endereço isolado

Para verificar um endereço sozinho, cole-o numa ferramenta que faça trabalho SMTP em tempo real, e não simples correspondência de formatos. O que interessa é que separe «o servidor disse que não» de «o servidor não quis dizer nada». Uma ferramenta que devolva apenas válido ou inválido, sem terceira categoria e sem tratamento de catch-all, costuma ser uma verificação de sintaxe e MX disfarçada. À mão é pior: fazer telnet à porta 25 a partir do IP do escritório dá greylisting ou bloqueio ao fim de umas dezenas de tentativas, e os scripts do GitHub que automatizam esse diálogo herdam todos os problemas acima.

Verificação em massa, passo a passo

Na limpeza de listas grandes, a ordem dos passos conta mais do que a ferramenta.

1. Normalizar e eliminar duplicados, primeiro. Cortar espaços, passar os domínios a minúsculas, matar as repetições e a mesma pessoa com dois endereços diferentes. Paga-se por endereço testado, portanto este passo é dinheiro que fica no bolso.
2. Separar os endereços de função para um separador só deles antes de carregar o ficheiro. A RFC 2142 dá a lista. Verificam como válidos e estragam qualquer sequência personalizada.
3. Carregar o CSV. O Email Verifier da Enrow aceita um ficheiro com milhares de linhas e devolve um estado em cada uma; o mesmo motor responde endereço a endereço pela API, ou a partir do servidor MCP oficial (github.com/EnrowAPI/enrow-mcp) quando o processo corre dentro de um assistente de IA.
4. Dividir o ficheiro por estado, não filtrá-lo. Uma linha apagada não se revê mais tarde.
5. Enviar para o segmento limpo e depois olhar para os bounces por domínio de destino, não por campanha. Cinco bounces espalhados por um envio inteiro são ruído; cinco no domínio da mesma empresa querem dizer que as linhas dessa empresa não prestam.
6. Verificar de novo antes do envio seguinte. Não é reutilizar o mesmo ficheiro três meses depois.

Em listas europeias, o tratamento assenta em geral no artigo 6.º, n.º 1, alínea f) do RGPD, o interesse legítimo, com o considerando 47 a incluir aí o marketing direto. Os considerandos são interpretativos, não vinculativos.

O que significa cada estado, e o que fazer com a linha

Que taxa de bounce é segura antes de carregar em enviar

Uma lista verificada fica abaixo de 1%, bem longe do ponto de rutura do SES.

Há um número, e vem da fonte, que vale a pena decorar. É do Amazon SES: com uma taxa de bounce igual ou superior a 5%, a conta passa automaticamente a revisão; a 10% ou mais, a capacidade de enviar mais correio pode ser suspensa. O SES só conta hard bounces.

Os 5% são o ponto de rutura, não são o alvo. O limite de trabalho, transversal a quem envia, são 2%, e o cold email deve ficar abaixo de 1% — que é o que uma lista verificada dá. Nas minhas listas, os endereços encontrados e verificados pela Enrow ficam abaixo de 1% de bounce: é uma média observada em envios reais, não é uma garantia e não é coisa que alguém lhe possa reembolsar.

Há um número que anda sempre mal citado. Os 0,3% do Google são uma taxa de queixas de spam, não uma taxa de bounce: quem empurra mais de 5 000 mensagens por dia para o Gmail tem de manter a taxa de spam do Postmaster Tools abaixo de 0,3%, e acima de 0,1% já se paga em colocação na caixa de entrada. Limiar público de bounce, o Google não publica nenhum. Mais sobre isto em taxa de bounce.

Quanto custa verificar uma lista em massa

Uma verificação na Enrow custa 0,25 crédito por endereço, retirado do mesmo saldo de créditos que se gasta a procurar contactos:

O plano gratuito são 50 créditos todos os meses, recorrentes, sem cartão — 200 verificações por mês, para sempre.

Comparar o que é comparável. O Hunter debita 0,5 crédito por email verificado, contra os 0,25 da Enrow, e publica os preços em euros — são os números dele, não uma conversão minha. No escalão mensal de 10 000 créditos isso dá 149 € por 20 000 verificações, 0,00745 € cada, contra os 75 € da Enrow por 40 000, a 0,001875 € — cerca de 4× por endereço testado. Em pagamento anual, para o mesmo volume: 0,0052 € contra 0,0017 €, à volta de 3,1×.

O ZeroBounce repõe 100 créditos gratuitos por mês e gasta um crédito por validação, de modo que a subscrição ONE, a 99 $/mês, compra 10 000 verificações a 0,0099 $ cada. As mesmas 10 000 verificações na Enrow são 2 500 créditos — cabem no plano Start de 42 €, que na verdade dá para 16 000. Mensal contra mensal, a mesma base. Uma nota de moeda: o ZeroBounce publica em dólares e assim fica, sem conversão, de forma que os dois valores por verificação não se dividem um pelo outro. E aquele plano do ZeroBounce inclui ferramentas de colocação em caixa de entrada e de listas negras que a Enrow não vende, ou seja não é só uma conta de verificação.

A ressalva honesta, do lado da Enrow: o saldo de créditos é comum. Uma verificação de 40 000 endereços no Pro consome o orçamento do mês inteiro, e não sobra um crédito para encontrar contactos novos. Decida a repartição antes de carregar o ficheiro, ou a limpeza come a prospeção.

O que a verificação não consegue fazer

Não ressuscita uma caixa de correio morta.

É o limite que ninguém no negócio da verificação diz com todas as letras. Numa lista construída há um ano ou dois, o trabalho do verificador é dizer-lhe quanto dela já desapareceu — e num ficheiro antigo desapareceu muito. As pessoas mudam de empresa, os domínios são absorvidos por quem comprou a empresa, os aliases reformam-se. Nenhum fornecedor recupera essas linhas, e uma ferramenta que devolva uma percentagem de válidos estranhamente alta num ficheiro velho está a descrever a sua própria indulgência, não os dados de quem a paga.

Verificar prova uma coisa e só uma: que aquela caixa aceita correio hoje. Não prova que alguém a lê, nem que a pessoa continua no cargo que o seu CRM lhe atribui. Isso já é procurar contactos, outra tarefa: como encontrar o email de alguém.

Dois limites da Enrow, ambos assumidos. Não há base de dados para consultar — funciona em tempo real, e é essa a razão por que os dados não estão velhos; montar as listas fica para o LinkedIn ou para o Sales Navigator. E não envia nada: as sequências ficam para a Emelia, a La Growth Machine ou o lemlist. O que faz e nenhum concorrente iguala: a partir de um perfil do LinkedIn, a extensão Chrome escreve a ficha de contacto completa e verificada no HubSpot, no Salesforce ou no Pipedrive, num clique.

FAQ

Como saber se um endereço de email é válido?

Use um verificador que faça uma verificação SMTP em tempo real e não simples correspondência de formatos: sintaxe, registos MX, uma sondagem RCPT TO, mais as listas de endereços de função e de domínios descartáveis. Uma rejeição permanente 5yz quer dizer que a caixa está morta. Uma 4yz transitória quer dizer que o servidor o adiou e que a verificação tem de ser repetida por outra rota. Se o domínio aceitar tudo, nenhuma sondagem isolada responde, e é preciso uma ferramenta que resolva os catch-all.

Como verificar emails em massa?

Normalize o ficheiro e elimine os duplicados, mova os endereços de função como o sales@ para um segmento próprio, carregue o CSV e divida os resultados por estado, sem filtrar linhas para fora. Envie para os válidos limpos, guarde os catch-all para uma ferramenta que os resolva, apague os inválidos permanentes de vez, verifique de novo antes da campanha seguinte.

Porque é que dois verificadores dão respostas diferentes para o mesmo endereço?

Porque uma passagem SMTP é uma amostra. O greylisting (RFC 6647) responde 421 no primeiro contacto de um remetente desconhecido, o Gmail trava as sondagens de grande volume com 421 4.7.28, a reputação do IP que pergunta altera a resposta, e os servidores que aceitam tudo dizem sim a qualquer coisa. E cada fornecedor traça a fronteira entre válido e arriscado num sítio diferente. A solução é a repetição: a Enrow faz mais de 10 verificações por endereço, com várias passagens SMTP e várias sondagens de catch-all a partir de servidores em regiões diferentes.

O que significa «catch-all» nos meus resultados, e devo apagar essas linhas?

O domínio aceita correio para todos os endereços que lhe forem propostos, incluindo um que o verificador inventou, portanto a resposta sobre o seu não tem informação nenhuma. Apagar o segmento é o erro caro — nas minhas listas é com frequência o segundo maior monte e já chegou a um terço das linhas. Verifique-o com sondagens repetidas de várias regiões: as linhas que se resolvem regressam à lista, as outras ficam de fora.

Que taxa de bounce é segura antes de enviar?

O Amazon SES põe a conta em revisão aos 5% e pode suspender os envios aos 10%, contando apenas os hard bounces. Trabalhe com um limite de 2% e aponte a menos de 1% em cold email, que é o que uma lista verificada dá. Não confunda isto com os 0,3% do Google, que são uma taxa de queixas de spam e uma métrica completamente diferente.

Qual é o melhor verificador de emails gratuito?

Procure um plano gratuito que se repita todos os meses, em vez de uma amostra única, e que faça verificações SMTP a sério e não validação de sintaxe. A Enrow dá 50 créditos por mês, sem cartão — 200 verificações por mês a 0,25 crédito cada, no mesmo motor que os clientes pagantes usam, catch-all incluídos.

A palavra do estado não é a resposta. A resposta é o método que está por trás dela. Limpe a próxima lista com a Enrow — mais de 10 verificações por endereço, catch-all resolvidos e não arrumados na gaveta dos «arriscados», e 50 créditos gratuitos todos os meses.