Verificar um endereço não envia nenhuma mensagem: a sessão SMTP pára antes do comando DATA, o que transmite o conteúdo (RFC 5321, secção 4.1.1.4). Este mecanismo, pouco conhecido, explica a maioria das falsas crenças sobre a verificação de emails, que lhe atribuem poderes a mais ou intrusões que não comete.
O seu efeito mais bem estabelecido incide sobre o hard bounce: afasta os endereços inexistentes antes do envio. Não toca nem nas queixas de spam nem no envolvimento. As 9 falsas crenças abaixo resolvem-se cada uma com um limiar publicado ou com o funcionamento do protocolo SMTP.
Verificação e validação: o perímetro em poucas linhas
A validação controla a forma de um endereço: um «@», um domínio, uma sintaxe conforme à RFC 5322. A verificação interroga em seguida o domínio, através do registo MX, depois o próprio servidor de correio, e assinala os endereços descartáveis. O pormenor das etapas encontra-se no artigo sobre a diferença entre validação e verificação.
9 falsas crenças sobre a verificação de emails, postas à prova
Um endereço verificado é um endereço sem risco?
Não. Um verificador reparte os endereços por categorias (válido, inválido, catch-all, de risco) porque um «válido» não cobre todos os casos. Os endereços descartáveis são um deles: a caixa existe e responde no dia do teste, e depois é abandonada. Os serviços detetam-nos graças a listas de domínios descartáveis, comparadas no artigo sobre os endereços de email descartáveis. A armadilha de spam é o caso mais insidioso: mantida por um fornecedor de correio ou por uma entidade antispam, aceita o correio. O teste SMTP vê-a, portanto, como uma caixa normal. A documentação da Amazon SES esclarece que estas armadilhas podem ser antigos endereços válidos, abandonados após um longo período de ressaltos.
É possível verificar uma caixa sem lhe enviar um email?
Sim. Uma transação SMTP tem 3 comandos: MAIL FROM anuncia o remetente, RCPT TO designa o destinatário, DATA transmite o conteúdo da mensagem (RFC 5321, secção 3.3). O servidor responde a RCPT TO antes de DATA existir; um verificador pára aí e fecha a ligação. O código 250 significa «aceite», o 550 «caixa desconhecida», e um código 4xx uma recusa temporária a repetir.
O registo MX indica onde colocar a pergunta. A secção 5.1 da RFC 5321 prevê que um domínio sem MX seja tratado como se tivesse um MX implícito a apontar para o seu próprio anfitrião. A ausência de MX continua, assim, a ser um sinal a cruzar com o resto. Este mecanismo tem uma falha conhecida, desenvolvida mais abaixo: alguns domínios respondem 250 a tudo.
A verificação é invasiva?
O conteúdo fica fora de alcance: nenhuma mensagem é transmitida nem lida, uma vez que a sessão pára antes de DATA. Resta a questão do RGPD: um endereço nominativo continua a ser um dado pessoal. A CNIL fixa as regras no momento da prospeção. Exige consentimento prévio em B2C e direito de oposição em B2B. Recomenda recolhê-los através de uma caixa não selecionada por defeito (a caixa pré-selecionada é proibida). Cada solicitação deve identificar a organização emissora e oferecer uma recusa simples (página da CNIL sobre a prospeção por correio eletrónico, página em francês, atualizada a 10 de junho de 2026).
O catch-all prova que o endereço existe?
Não. Um domínio catch-all aceita o correio dirigido a qualquer nome antes da arroba: jean.dupont@ e azertyuiop@ obtêm o mesmo 250 no comando RCPT TO.
Nenhum método decide com certeza: o destino da mensagem, arrumada numa caixa real ou descartada, depende da configuração do domínio. Os serviços sérios classificam estes endereços como risky («accept-all» em alguns), o que exprime uma incerteza real. Um lote de teste enviado a este segmento, com registo do hard bounce antes de alargar, vale mais do que uma triagem às cegas.
Uma ferramenta gratuita ou uma simples sintaxe bastam?
Não. «gmial.com» respeita todas as regras de sintaxe. O controlo seguinte, o registo MX, elimina os domínios inexistentes sem travar um domínio real em que a caixa não existe. Só a conversa SMTP interroga o próprio endereço. Uma ferramenta gratuita avalia-se, portanto, pela profundidade do seu controlo: sintaxe e domínio de um lado, SMTP com deteção do catch-all do outro. A validação isolada nada diz sobre o estado da caixa de entrada.
Os endereços verificados estão sempre ativos?
Não. «Válido» significa aceite pelo servidor no momento do teste. Uma caixa pode ficar meses sem leitor. Pode também ficar cheia e devolver soft bounces. A Amazon SES recomenda aliás parar o envio aos destinatários que não abrem nem clicam: um contacto inativo não ressalta, pesa no envolvimento.
Uma verificação por ano chega?
Nenhum número universal fixa o ritmo. Depende da velocidade de renovação da base e do custo de um ressalto (limiares mais abaixo). Para os contactos a quem não se escreve há muito tempo, a SES aconselha a incluir apenas uma pequena parte em cada envio. A página sobre a frequência de verificação de uma lista de emails detalha o ritmo. Um double opt-in e uma verificação no momento do registo cortam a fonte dos erros de escrita logo à entrada; a limpeza da lista existente completa estas duas salvaguardas.
A verificação garante a entregabilidade?
Não, atua numa única linha do balanço. Para as queixas de spam, o Gmail fixa a regra desde 1 de fevereiro de 2024 para todos os remetentes:
«Mantenha as taxas de spam indicadas no Postmaster Tools abaixo de 0,10% e evite atingir uma taxa de spam de 0,30% ou mais.»
Esta orientação consta das diretrizes da Google para remetentes, que exigem SPF ou DKIM a todos os remetentes e acrescentam o DMARC a partir de 5000 mensagens por dia para o Gmail. Um destinatário perfeitamente válido que clica em «denunciar como spam» pesa na reputação do remetente sem que qualquer verificação o possa impedir; a definição de spam e os erros de entregabilidade cobrem esta metade do dossiê.
Quanto aos ressaltos, a mesma página da Amazon SES dá uma escala legível: menos de 2% de ressaltos definitivos para bons resultados, revisão da conta a partir dos 5% e suspensão possível a partir dos 10%. Os ressaltos temporários, como uma caixa cheia, não entram neste cálculo.
Todos os serviços de verificação se equivalem?
Não. Os serviços divergem no destino dado aos endereços catch-all, na atualidade das suas listas de domínios descartáveis e na finura dos seus estados. Um serviço que só devolve «válido» ou «inválido» esconde a categoria mais incerta, a dos catch-all. O teste mais revelador cabe em poucos minutos: submeter algumas centenas de endereços cujo destino já se conhece, e depois comparar os estados devolvidos. A amostra mistura caixas internas ativas, endereços inventados em domínios reais e um domínio catch-all identificado.
O que uma lista verificada deixa de fora
O teste não mede nem o conteúdo da mensagem nem o consentimento dos destinatários. Também nada diz sobre a vontade de ler. Uma amostra retirada do segmento mais antigo e passada pela Captain Verify antes da próxima campanha dá a parte de inválidos dessa base, a comparar com o limiar de 2% de ressaltos da Amazon SES.
