Para quem trabalha com infraestrutura, desenvolvimento ou DevOps, a expressão “validador de email” às vezes soa simplista — como se fosse uma ferramenta que rodasse um regex em uma string e devolvesse true ou false. Na prática, a validação de email moderna é um conjunto de procedimentos coordenados em camadas, e entender como cada uma funciona é o que separa a integração robusta da gambiarra que vai falhar em produção.
Este artigo abre a caixa preta. Vamos passar pelas três camadas reais que um validador de email sério executa.
Camada 1: validação sintática
A camada mais óbvia, e a única que muitos times implementam, é a verificação de sintaxe contra a RFC 5322. Aqui o objetivo é simples: o que foi enviado é um email bem-formado?
Os erros que essa camada detecta são óbvios:
Espaços não escapados na parte local
Caracteres proibidos fora de aspas
TLDs que não existem (.con em vez de .com)
Estrutura mal-formada (@ em duplicidade, parte de domínio vazia)
Um detalhe que muita gente erra: implementar a regex completa da RFC 5322 é trabalhoso, e a maior parte das bibliotecas de linguagem traz a implementação errada (mais permissiva ou mais restritiva do que deveria). Usar uma biblioteca testada (como email-validator em Python, validator.js em JavaScript) é menos arriscado do que escrever a sua.
Camada 2: verificação de DNS e MX records
Sintaxe correta não significa nada se o domínio do email não existir, ou se ele não estiver configurado para receber mensagens. A camada 2 resolve essa pergunta consultando os registros DNS do domínio.
O foco é o registro MX (Mail Exchanger), que indica para o mundo qual servidor recebe email para aquele domínio. Se não existir MX, o domínio não recebe email — independente da sintaxe estar correta.
Detalhes técnicos relevantes nessa camada:
Fallback para A record — pela RFC, se não houver MX, o servidor de origem deveria tentar entregar no A record do domínio. Validadores cuidadosos consideram esse fallback.
Prioridades MX — domínios podem ter múltiplos MX com prioridades. Não afeta validação, mas afeta o handshake da próxima camada.
Cache de DNS — consultas DNS são caras quando você está validando 100k contatos. Validadores escaláveis fazem cache agressivo de MX por domínio.
Camada 3: handshake SMTP
A camada final é a mais delicada. Mesmo com sintaxe correta e MX válido, o endereço específico pode não existir no servidor. A camada 3 verifica isso conectando no servidor MX via SMTP e simulando o início de um envio — sem nunca completá-lo.
O fluxo é mais ou menos assim:
> HELO sender.example.com
< 250 mail.targetdomain.com Hello
> MAIL FROM: <[email protected]>
< 250 OK
> RCPT TO: <[email protected]>
< 250 OK ← ou < 550 No such user
> QUIT
A resposta ao RCPT TO é o que indica se a caixa existe. 250 significa que o servidor aceita; 550 (ou similar 5xx) significa que ela não existe.
Validadores robustos como o EmailChecker implementam essa camada com cuidados extras: retries com backoff exponencial, rotação de IPs de origem para não serem bloqueados por anti-abuse, respeito aos rate limits de cada provedor (Gmail tem políticas diferentes do Outlook).
O caso especial dos catch-all
Existe um padrão de configuração em muitos servidores corporativos chamado catch-all: o servidor aceita qualquer endereço naquele domínio, mesmo se a caixa específica não existir. É comum em empresas pequenas que querem evitar perder emails legítimos enviados com erro de digitação.
Para o validador, catch-all é um problema: o servidor responde 250 OK para qualquer RCPT TO, então a camada 3 não consegue distinguir caixa real de caixa inexistente.
A detecção de catch-all é feita comparando a resposta de um endereço aleatório improvável (tipo [email protected]) com a resposta do endereço real. Se ambos respondem 250, o domínio é catch-all e o resultado da validação fica ambíguo — geralmente marcado como “risky” em vez de “valid”.
Detecção de descartáveis e role-based
Camadas auxiliares incluem:
Lista de domínios descartáveis — base curada de provedores como 10minutemail, mailinator, guerrillamail. Atualização contínua é crítica, novos surgem toda semana.
Detecção de role-based — endereços tipo info@, contato@, vendas@. Tecnicamente válidos, mas com taxa de engajamento historicamente baixa. Geralmente segregados em uma categoria separada.
Por que reimplementar é uma má ideia
Validar email em escala é um problema de engenharia de longa data. Lidar com retries, rate limits, detecção de greylisting, parsing de respostas SMTP não-padrão (cada servidor tem suas peculiaridades), cache de DNS, lista de descartáveis sempre atualizada — tudo isso é trabalho contínuo que dificilmente vale a pena dentro de outro projeto.
Usar um serviço dedicado com API limpa é, para 99% dos casos, mais barato e mais confiável do que tentar reproduzir o sistema do zero.
Conclusão
A próxima vez que um desenvolvedor chamar validação de email de “regex check”, vale lembrar: é um stack de camadas que conversa com DNS, com SMTP, com listas de reputação, com detecção de padrões corporativos. Quando bem feita, blinda a entregabilidade do sistema de email do produto inteiro.
