Verificação de emails em massa: limpar a lista antes do envio

O essencial Um verificador em massa passa cada linha do ficheiro por uma série de testes — formato do endereço, registos MX do domínio, uma conversa SMTP real, listas de endereços de função e de domínios descartáveis — e devolve uma única palavra. Por trás dessa palavra está uma realidade bem mais confusa. Uma única passagem SMTP é uma amostra, não é um veredicto. O greylisting existe precisamente para responder «volte mais tarde» (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. Os catch-all são as linhas que a maioria das ferramentas deita fora sem alarido. Marcados como «arriscados», retirados da lista, esquecidos. 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 fica muito longe de qualquer um destes 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 o usar em qualquer campanha. Carrega-se um CSV, recebe-se o ficheiro com um estado em cada linha e apagam-se as linhas más. É aqui que quase toda a gente deixa de ler. E é aí que se perde dinheiro.

Essa palavra de estado resume 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 é o mesmo que um endereço inválido. E por trás de «desconhecido» está, muitas vezes, um servidor que se recusou a responder à máquina que o interrogou.

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 bem formado? A RFC 5321 §4.5.3.1 fixa os limites: 64 octetos na parte local, 255 no domínio, 256 no caminho completo. Este teste apanha também os erros mais banais, que bastam para inutilizar uma linha: um espaço a mais no fim, .con em vez de .com.

Sobre a entrega, não diz rigorosamente 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 host. Um domínio sem MX mas com um registo A a funcionar não está automaticamente morto. Acontece que, hoje em dia, os envios para esses domínios fazem bounce de qualquer forma, o que faz deles um sinal de alerta 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, indica o destinatário com RCPT TO. Depois lê a resposta e não vai mais longe. Nada chega a ser entregue.

O SMTP tem um comando feito precisamente para isto, o VRFY, mas na prática não se pode contar com ele. A RFC 5321 §3.5.2 permite ao servidor responder 252 (não consigo verificar, mas aceito e vou tentar entregar) sem confirmar coisa nenhuma, e a §7.3 autoriza a desativação total do comando. 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 franca de uma caixa que não existe — «The email account that you tried to reach does not exist.» Já o 452 4.2.2 significa caixa cheia, ou seja, uma pessoa bem real 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 chegar ao destino e servir para alguma coisa são duas questões 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 de correio temporária, aqueles a que se recorre para aproveitar um período de 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 mais usada é o repositório disposable-email-domains. Quem o mantém é franco quanto aos limites: não garante que todos esses domínios ainda possam ser considerados descartáveis. É decisivo num formulário de inscrição. Em prospeção B2B, conta pouco.

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 quanto da sua 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 num canal com ruído, e esse ruído tem causas bem identificadas.

O greylisting é a principal, e a RFC 6647 descreve-o com toda a clareza. No primeiro contacto de um remetente desconhecido, o servidor devolve um 421, fecha a ligação, regista o trio formado pelo endereço IP, o remetente e o primeiro destinatário, e só aceita a mensagem 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 só vez esbarra no adiamento e fica a adivinhar.

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 dá de caras com esse limite, e todos os endereços seguintes ficam por resolver. Também conta o IP de onde parte a pergunta. As diretrizes do Google para remetentes exigem um registo de DNS inverso válido no IP de envio, com uma resolução direta que lhe corresponda, e uma sondagem feita a partir de um IP que não o tenha é 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á ativo. Quando essa funcionalidade está desligada, a resposta do domínio transporta muito menos informação e o verificador fica a decidir às cegas. Na prática, é este mecanismo que está na origem do problema dos catch-all nos domínios B2B europeus.

Daí que a Enrow não se fique por uma passagem. Cada endereço passa por 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 nasce da forma como essas respostas divergem — incluindo a maneira como o domínio trata um endereço de controlo que nunca viu.

Uma sondagem esbarra num adiamento e fica sem resposta. Várias, a partir de regiões diferentes e comparadas com um endereço de controlo, dão um veredicto.

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

Um domínio que aceita tudo recebe correio dirigido a qualquer endereço. jane.doe@, jne.doe@, disparate@. Tudo é aceite e, a seguir, ou é deitado fora internamente, ou faz bounce horas depois, quando a ligação já está fechada.

A maioria dos verificadores fica por aqui. Carimba a linha com «catch-all» ou «arriscado» e deixa a decisão nas suas mãos. 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, com ele, deita fora centenas de decisores bem reais. Ou envia para ele tal como está e engole os bounces. Nos meus ficheiros, o monte dos «arriscados» é muitas vezes o segundo maior, logo a seguir aos válidos, e nalgumas listas chegou a um terço das linhas. São linhas a mais para apagar por palpite.

Um catch-all pode resolver-se a partir de fora, mas não com uma única sondagem. Conversas SMTP repetidas, de origens diferentes, a horas diferentes, comparadas com endereços de controlo inventados de propósito, dão um sinal que nenhuma verificação isolada consegue dar. É assim que a Enrow os resolve: entrega-os como válidos, e não como avisos à espera de decisão. Há domínios que nunca cedem, e o mais honesto é deixar essas linhas de fora. Ficam muito menos por resolver do que com uma ferramenta de passagem única. Zero é que não. O mecanismo completo está explicado em o que é um email catch-all.

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

Para verificar um endereço isolado, cole-o numa ferramenta que faça uma verificação SMTP em tempo real, e não uma simples comparação com padrões. 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 acaba em greylisting ou em bloqueio ao fim de umas dezenas de tentativas, e os scripts do GitHub que automatizam esse diálogo herdam todos os problemas descritos acima.

Verificação em massa, passo a passo

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

1. Primeiro, normalizar e eliminar duplicados. Retirar os espaços a mais, passar os domínios a minúsculas, apagar as linhas repetidas e a mesma pessoa com dois endereços diferentes. Paga-se por endereço testado, portanto este passo é dinheiro que fica no bolso.
2. Passar os endereços de função para um separador próprio antes de carregar o ficheiro. A RFC 2142 dá a lista. Passam na verificação 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 atribui um estado a 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 é executado dentro de um assistente de IA.
4. Dividir o ficheiro por estado, e não filtrá-lo. Uma linha apagada já não se pode rever.
5. Enviar para o segmento limpo e, depois, analisar os bounces por domínio de destino, e 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. E não reaproveitar 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, e o considerando 47 trata o marketing direto como um desses interesses. Os considerandos servem para interpretar, não sã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, publicado pela própria 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 os hard bounces.

Os 5% são o ponto de rutura, não são o alvo. Na prática, o limite que a generalidade dos remetentes adota é 2%, e o cold email deve ficar abaixo de 1%, que é o que uma lista verificada consegue. 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 envia 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% a entrega na caixa de entrada já se ressente. Limiar público de bounce, o Google não publica nenhum. Mais sobre isto em taxa de bounce.

Quanto custa a verificação de emails em massa

Uma verificação na Enrow custa 0,25 crédito por endereço, descontado do mesmo saldo de créditos que se usa para encontrar contactos:

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

Comparemos o que é comparável. O Hunter debita 0,5 crédito por email verificado, em vez dos 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, face aos 75 € da Enrow por 40 000, a 0,001875 €: cerca de 4× mais por endereço testado. Em pagamento anual, para o mesmo volume, 0,0052 € face a 0,0017 €, cerca de 3,1×.

O ZeroBounce oferece 100 créditos gratuitos por mês e consome um crédito por validação, de modo que a subscrição ONE, a 99 $/mês, dá direito a 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 4k de 42 €, que aliás dá para 16 000. Mensal contra mensal, na mesma base. Uma nota sobre a moeda: o ZeroBounce publica em dólares e os valores ficam em dólares, sem conversão, pelo que os dois custos por verificação não se podem dividir um pelo outro. Diga-se ainda que esse plano do ZeroBounce inclui ferramentas de colocação na caixa de entrada e de listas negras que a Enrow não vende: a fatura não é, portanto, só de verificação.

A ressalva honesta, do lado da Enrow: o saldo de créditos é partilhado. 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 fica com os créditos da 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 são desativados. Nenhum fornecedor recupera essas linhas, e uma ferramenta que apresente 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 leia, nem que a pessoa ainda ocupe o cargo que o seu CRM lhe atribui. Isso já é trabalho de pesquisa de contactos: 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 é por isso que os dados não estão desatualizados; montar as listas fica a cargo do LinkedIn ou do 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 uma ferramenta que faça uma verificação SMTP em tempo real, e não uma simples comparação com padrões: sintaxe, registos MX, uma sondagem RCPT TO e ainda 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 adiou a resposta e que a verificação tem de ser repetida por outra rota. Se o domínio aceitar tudo, nenhuma sondagem isolada dá a resposta, 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 apagar linhas com filtros. Envie para os válidos, guarde os catch-all para uma ferramenta que os resolva, apague de vez os inválidos permanentes e 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 faz a sondagem 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 é repetir: 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, pelo que a resposta sobre o seu endereço não diz nada. Apagar o segmento é o erro que sai caro — nas minhas listas é muitas vezes o segundo maior monte e já chegou a um terço das linhas. Verifique-o com sondagens repetidas a partir 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 procure ficar abaixo de 1% em cold email, que é o que uma lista verificada consegue. 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 renove todos os meses, em vez de uma oferta única, e que faça verificações SMTP a sério, não uma simples 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, com o mesmo motor que os clientes pagantes usam, catch-all incluídos.

A palavra de estado não é a resposta. A resposta está no método 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.