Validação SMTP explicada: como os validadores de e-mail funcionam realmente

A maioria dos verificadores de e-mail afirma ter precisão. Poucos explicam como eles realmente verificam um endereço.

Esta é essa explicação.

O que é SMTP?

SMTP = Simple Mail Transfer Protocol
É a linguagem que os servidores de e-mail usam para enviar e receber mensagens.

Quando você envia um e-mail:
1. O seu cliente se conecta a um servidor SMTP
2. Envia MAIL FROM: you@yourcompany.com
3. Envia RCPT TO: recipient@their.com
4. O servidor responde 250 OK (yes, we accept it) or 550 Reject (no, we don't)
5. O cliente envia o corpo da mensagem

Validação SMTP: A Verificação Real

Validação SMTP simula os passos 1–4 sem enviar o e-mail real.

É por isso que essa é a única forma de saber se uma caixa de e-mail realmente existe.

O processo de handshake SMTP

→ Cliente: EHLO mail.validador.com
← Servidor: 250 OK ESMTP

→ Cliente: MAIL FROM:<validador@mail.validador.com>
← Servidor: 250 OK

→ Cliente: RCPT TO:<test@gmail.com>
← Servidor: 250 OK
     (caixa de correio existe e aceita mail)

→ Cliente: QUIT
← Servidor: 221 Tchau

Se o RCPT TO returns 250, o endereço é Válido.
Se ele retornar 550, o endereço é Inválidos.
Se o servidor não responder, é Arriscado ou Desconhecido.

Por que outros métodos falham

❌ Apenas verificação de sintaxe

test@example.com ✅ (parece bom)
test.12345@example.com ❌ (pode not existem)

A sintaxe está correta, mas não sabemos se a caixa de correio existe.

❌ Apenas verificação de registro MX

Domínio: gmail.com → MX: aspmx.l.google.com (sim, existe)
Mas: faz test@gmail.com realmente existem? Desconhecido.

✅ Validação SMTP

Conectar à gmail SMTP → RCPT TO test@gmail.com
← 550 Nein tal user
Resultado: INVÁLIDO (caixa de correio não't existem)

O desafio: domínios catch-all

Alguns servidores (especialmente os mais antigos) respondem "sim" para todo endereço:

→ RCPT TO: realuser@company.com
← 250 OK

→ RCPT TO: fakeuser123456789@company.com
← 250 OK (também aceitou!)

Estes são domínios catch-all. A verificação SMTP sozinha não consegue saber se é real.

Avançado: Pontuação + Deteção de Catch-All

Validadores melhores combinam SMTP + outros sinais:

• Reputação do domínio — o servidor de e-mail é conhecido por devolver mensagens?
• Atividade recente — este domínio esteve ativo nos últimos 90 dias?
• Verificações de honeypot — é uma armadilha de spam conhecida?
• Sinalizador de risco + catch-all — "Válido por SMTP mas pode ser catch-all"

Pontuação 0–10 = nível de confiança, não apenas aprovado/reprovado.

Velocidade vs Precisão

Porque É Importante a Validação SMTP

✅ Protege a reputação do remetente — verifique antes de enviar
✅ Reduz as taxas de devolução — o SMTP identifica inválidos antes do envio
✅ Economiza créditos — não pague ao ESP por e-mails devolvidos
✅ Melhora a entregabilidade — provedores recompensam envios limpos

Como verificar por conta própria (apenas para devs)

import smtplib

domínio = "gmail.com"
try:
    smtp = smtplib.SMTP(f"mx.{domínio}")
    smtp.mail("test@validator.com")
    code, msg = smtp.rcpt("recipient@gmail.com")
    if code == 250:
        print("Valid")
    else:
        print("Invalid")
    smtp.quit()
except:
    print("Risky/Unknown")

Mas em produção, use um serviço. A validação SMTP em escala é complexa (firewalls, limites de taxa, atrasos).

SMTP em Mais Detalhe

SMTP é um protocolo de texto. Uma sessão é uma conversa curta com uma sequência de comandos e respostas numéricas. Para a validação, apenas a primeira metade importa — a parte que vem antes de qualquer corpo de mensagem ser enviado.

Portas e TLS

• 25 — a porta clássica de servidor para servidor. Frequentemente bloqueada pelos fornecedores de alojamento para impedir spam, razão pela qual os serviços de validação usam infraestrutura dedicada.
• 465 — TLS implícito (SMTPS).
• 587 — porta de submissão com STARTTLS, usada pelos clientes de e-mail.

Um validador precisa de alcançar a porta 25 do MX do destinatário. Se o seu próprio servidor não conseguir alcançar a porta 25, não poderá executar verificações SMTP fiáveis por conta própria — este é o motivo mais comum pelo qual as equipas externalizam a verificação.

EHLO, MAIL FROM, RCPT TO

→ EHLO validador.example.com
← 250-mail.example.com
← 250-PIPELINING
← 250 SIZE 35882577

→ MAIL FROM:<de sintaxe@validator.example.com>
← 250 OK

→ RCPT TO:<person@example.com>
← 250 OK

EHLO opens the session and asks which extensions the server supports. MAIL FROM declares the envelope sender. RCPT TO is the actual test: the server accepts or rejects the recipient. QUIT ends the session.

O ponto-chave: A resposta a RCPT TO é dada antes de qualquer dado da mensagem ser enviado. É isto que torna a validação possível sem entregar o e-mail.

Interpretar os Códigos de Resposta SMTP

Um validador que trata toda resposta diferente de 250 como "inválida" está errado: os códigos 4xx são temporários e muitas vezes resolvem-se ao tentar novamente.

Por que as verificações de sintaxe e MX não são suficientes

Ambas são baratas e úteis como primeiro filtro, mas nenhuma consegue responder à única pergunta que realmente importa: esta caixa de correio aceita e-mails?

• Sintaxe indica que o texto tem aspeto de endereço. Não consegue perceber que a empresa encerrou atividade.
• MX indica que o domínio tem um servidor de e-mail. Não consegue perceber que person@ was never created.
• SMTP comunica com esse servidor e pergunta por aquele destinatário específico. Só este passo devolve uma resposta real.

A consequência prática: uma lista que passa nas verificações de sintaxe e MX pode, ainda assim, ser devolvida (bounce) em 20–30%. É por isso que as ferramentas de "verificação de e-mail gratuita" que apenas executam expressões regulares são populares, mas inúteis para trabalho de entregabilidade.

Domínios Catch-All em detalhe

Um servidor catch-all está configurado para aceitar e-mails para qualquer parte local. Trata-se de uma configuração legítima — as empresas usam-na para que um erro de digitação no endereço de um potencial cliente não desapareça silenciosamente — mas inviabiliza a validação SMTP.

Como lidar com os catch-all:

1. Detete-os. Envie uma sonda para uma parte local aleatória e obviamente falsa. Se também devolver 250, o domínio é catch-all.
2. Assinale, não elimine. Os endereços catch-all pertencem frequentemente a pessoas reais. Eliminá-los pode custar 5–15% de uma lista B2B.
3. Envie em pequenos lotes e meça aberturas e devoluções. Se um segmento catch-all tiver bom desempenho, mantenha-o.
4. Use sinais adicionais — reputação do domínio, envolvimento histórico e correspondência de padrões — para ordenar os endereços catch-all.

Greylisting, limites de taxa e anti-recolha de endereços

Servidores de e-mail reais não são ambientes de teste. Espere:

• Greylisting — o servidor rejeita temporariamente remetentes pela primeira vez com um código 4xx e espera uma nova tentativa. Os serviços de validação repetem as tentativas automaticamente.
• Limitação de taxa — muitas conexões a partir de um mesmo IP são limitadas. Bons provedores distribuem as verificações entre IPs e ao longo do tempo.
• Anti-harvesting — alguns servidores respondem de forma ambígua de propósito a quem testa muitos endereços.
• Honeypots — endereços que existem apenas para apanhar remetentes em massa. Um bom validador os sinaliza.

É por isso que scripts de validação feitos em casa funcionam com dez endereços, mas falham com dez mil.

Tempo real vs. lote, e o padrão assíncrono

• Tempo real é o ideal para formulários de inscrição e checkout: um endereço, uma resposta imediata, com um timeout rigoroso para que o utilizador nunca espere mais de um ou dois segundos.
• Lote é o ideal para listas: milhares de endereços, novas tentativas e um ficheiro de resultados que pode segmentar.
• Assíncrono é o padrão de produção para ambos: colocar o endereço em fila, devolver a resposta de imediato, validar em segundo plano e atualizar o registo quando o resultado chegar.

Nunca bloqueie a thread de um pedido à espera de um handshake SMTP remoto. Um servidor lento ou hostil pode manter a ligação aberta durante 30 segundos ou mais.

Um Exemplo Melhor em Python

import smtplib
import dns.resolver

def de sintaxe(domínio: str, endereço: str, timeout: int = 10) -> str:
    try:
        mx = str(dns.resolver.resolve(domínio, "MX")[0].exchange).rstrip(".")
        with smtplib.SMTP(mx, 25, timeout=timeout) as smtp:
            smtp.ehlo_or_helo_if_needed()
            smtp.mail("check@validator.example.com")
            code, _ = smtp.rcpt(endereço)
            if code in (250, 251):
                return "valid"
            if code in (450, 451, 452, 552):
                return "arriscado"
            if code in (550, 551, 553):
                return "invalid"
            return "unknown"
    except Exceção:
        return "unknown"

Mesmo esta versão simplificada tem problemas em grande escala: ignora o greylisting, não deteta domínios catch-all, usa um único IP e será bloqueada por fornecedores que limitam a taxa de pedidos. É uma ferramenta de aprendizagem, não um validador para produção.

Limitações e Ética

Nenhum validador pode garantir a entregabilidade. As caixas de correio fecham entre a verificação e o envio; os servidores mudam de política; um endereço "válido" pode ainda assim ser abandonado. Use a verificação para eliminar falhas previsíveis, não para prometer uma campanha sem devoluções.

Do ponto de vista ético, valide apenas os endereços para os quais tem uma base legal para contactar. A sondagem SMTP é uma operação técnica, mas não cria consentimento, e usar a validação para legitimar uma lista comprada não torna o envio legal.

O que a validação não consegue ver

• Envolvimento — um endereço válido pode nunca abrir o seu e-mail.
• Intenção — uma pessoa real pode não querer a sua oferta.
• Exemplo — um endereço entregável não é uma base legal.
• Estado futuro — uma caixa de correio pode ser encerrada no dia seguinte à verificação.

A verificação elimina a incerteza técnica. Todo o resto continua a ser marketing.

Testar primeiro o seu próprio domínio

Antes de validar uma lista, valide o seu domínio de envio:

• Envie um teste para uma caixa de correio que controla no Gmail, no Outlook e num domínio corporativo.
• Verifique o alinhamento de SPF, DKIM e DMARC.
• Acompanhe de perto os primeiros 200 envios de qualquer domínio novo; o aquecimento importa mais do que qualquer verificação isolada.

Uma lista limpa enviada a partir de um domínio com autenticação incorreta continua a cair no spam.

Perguntas Frequentes

A validação SMTP envia um e-mail?
Não. Termina em RCPT TO, before any message body is transmitted.

Porque é que alguns endereços válidos aparecem como arriscados?
Greylisting, erros temporários do servidor ou políticas antirrecolha de endereços. Tente novamente após 24–48 horas.

Posso validar a partir do meu próprio servidor?
Apenas se conseguir aceder à porta 25 e não estiver limitado em taxa nem na lista negra. A maioria das alojamentos partilhados bloqueia-a.

A detecção de catch-all é confiável?
Indica com segurança que o domínio é catch-all. Não consegue dizer se uma caixa de correio específica existe.

Que precisão devo esperar?
Um bom validador baseado em SMTP acerta cerca de 95–99% das vezes; a incerteza restante deve-se sobretudo a catch-alls e falhas temporárias.

SPF, DKIM e DMARC num Parágrafo Cada

• SPF indica os servidores autorizados a enviar em nome do seu domínio. É um registo TXT de DNS e falha quando ultrapassa o limite de 10 consultas.
• DKIM acrescenta uma assinatura criptográfica a cada mensagem para que o destinatário possa comprovar que não foi alterada. Rode as chaves periodicamente.
• DMARC indica aos destinatários o que fazer quando o SPF ou o DKIM falham (none, quarantine, reject) e envia-lhe relatórios. Comece com p=none, read the reports, then tighten.

A validação SMTP verifica o destinatário; SPF, DKIM e DMARC determinam se o seu próprio correio é considerado fiável à saída. Uma lista verificada enviada a partir de um domínio com autenticação mal configurada continua a falhar. Configure os relatórios DMARC antes de escalar uma campanha — são os relatórios que lhe permitem encontrar os remetentes de que se tinha esquecido.

Comece a validar

Comece grátis →

100 validações SMTP/mês, sem cartão de crédito.