Validação de E-mail Além da Sintaxe: Reduzindo Custos de Disparo
Em um projeto recente na empresa onde trabalho, lidávamos com o envio de e-mails transacionais para clientes utilizando o SendPulse.
Com o aumento do volume de envios, falhas causadas por e-mails inválidos começaram a gerar desperdício de créditos e distorcer métricas de entregabilidade.
A primeira abordagem adotada foi a validação de sintaxe conforme a RFC 5322, aliada a um registro detalhado de erros e exceções em logs, cruzando essas informações com os retornos fornecidos pela própria plataforma de envio.
A análise desses dados revelou um padrão de que a maioria das falhas estava relacionada a e-mails inexistentes, e não a problemas temporários ou de infraestrutura. Ou seja, muitos envios falhavam por motivos que poderiam ser identificados antes mesmo da tentativa de disparo.
Para atacar esse problema, adicionamos uma nova camada de validação baseada na consulta a registros MX (Mail eXchange) do domínio antes do disparo. O resultado foi imediato: menos exceções, menos tentativas de envio desnecessárias e uma melhora perceptível nas métricas da operação.
Essa experiência prática evidenciou que validar e-mails apenas pela sintaxe não é suficiente, e que pequenas melhorias no processo de validação podem gerar ganhos técnicos e financeiros reais, especialmente em plataformas SMTP que cobram por disparo, independentemente do sucesso ou erro.
Sintaxe Válida Não Significa E-mail Entregável
Validar e-mail por sintaxe resolve apenas uma parte do problema.
A validação por RFC responde se o endereço é bem-formado. O que importa em produção é se ele é entregável.
Mas o que você quer responder em produção quase sempre é: "isso é entregável?".
Alguns exemplos de endereços sintaticamente válidos, mas inúteis na prática:
[email protected][email protected](sem registros MX que, em geral, indica problema de entrega)[email protected](domínio válido, caixa não existe)
A validação de sintaxe é a primeira barreira, mas não a última.
Onde o Dinheiro Escapa: Custo e Métricas
Quando o volume de envio cresce, pequenas taxas de erro passam a ter um impacto relevante:
- Desperdício de créditos por tentativa
- Aumento de falhas e hard bounces
- Ruído em observabilidade (exceções e retries desnecessários)
Plataformas SMTP, como o SendPulse, normalmente cobram por tentativa de envio, não por sucesso.
Reduzir disparos para e-mails inválidos não é perfumaria, é otimização de custo e qualidade.
Camadas de Validação de E-mail
Uma forma prática de estruturar a validação é pensar em camadas, aplicando as mais baratas primeiro e avançando conforme necessário.
Normalização + Sintaxe (Barato e Obrigatório)
Antes de qualquer validação, o primeiro passo é a normalização:
trim- Lower-case do domínio (o domínio é case-insensitive)
- Remover espaços invisíveis
- Bloquear casos óbvios (sem @, sem domínio, etc.)
Depois, validação de sintaxe conforme RFC (ou biblioteca confiável que implemente bem as regras).
Cache de Domínio Conhecido (Custo Zero Depois da Primeira Vez)
A ideia é:
- Se
dominio.comjá foi validado recentemente, não faz sentido consultar DNS toda hora - Você reduz latência e carga
- O custo marginal tende a zero
Boas práticas para o cache:
- TTL por domínio
- Guardar metadados
- Estratégia de invalidação: se começar a aparecer muito hard bounce em um domínio "validado", revalidar
Cachear domínio, e não e-mail, é uma decisão simples que escala muito melhor.
Consulta DNS/MX (Barato e com Ótimo Retorno)
Registro MX indica "para onde entregar e-mails" naquele domínio. Se não existe MX (ou se DNS falha consistentemente), a chance de entrega ser possível cai muito.
Isso resolve muito bem:
- Domínio inexistente
- Domínio sem infraestrutura de e-mail
Porém MX ok não garante que o usuário existe.
Verificação via SMTP (Profundo, Caro e com Pegadinhas)
Além da validação por sintaxe e da consulta a registros MX, existe uma abordagem mais profunda para validação de e-mails: a verificação via comunicação direta com o servidor SMTP do domínio.
Essa técnica tenta entender se uma caixa de entrada específica existe estabelecendo uma conexão SMTP e analisando as respostas do servidor, sem efetivamente enviar um e-mail. É nesse nível que ferramentas como o check-if-email-exists atuam.
Esse método pode aumentar a precisão da validação, especialmente em cenários onde identificar a existência do destinatário é relevante. No entanto, ele também traz custos e limitações importantes.
Do ponto de vista operacional, abrir conexões SMTP em volume pode ser interpretado por provedores como comportamento abusivo, resultando em rate limit ou bloqueios. Além disso, muitos servidores utilizam mecanismos como catch-all, greylisting ou proteções contra enumeração de usuários, o que pode gerar falsos positivos ou falsos negativos.
Fluxo Interessante: Sintaxe + MX + cache
O fluxo abaixo, na minha opinião, é uma ótima condição e interessante de se aplicar:
- Normaliza o e-mail (
trim, etc.) - Valida sintaxe de acordo com RFC 5322
- Extrai domínio
- Se o domínio está no cache como válido -> passa
- Se não está no cache:
- Faz consulta MX
- Se falhar -> bloqueia antes de disparar
- Se passar -> grava domínio no cache
O fluxograma abaixo resume a estratégia adotada, combinando validação de sintaxe, cache por domínio e consulta a registros MX.
flowchart TD
A["Recebe e-mail"] --> B["Normaliza: trim, domínio lowercase, remove espaços invisíveis"]
B --> C{"Sintaxe válida? (RFC 5322)"}
C -- "Não" --> R["Rejeita envio"]
C -- "Sim" --> D["Extrai domínio"]
D --> E{"Domínio está no cache como válido (TTL ativo)?"}
E -- "Sim" --> OK["Aceita envio"]
E -- "Não" --> F["Consulta DNS: registros MX do domínio"]
F --> G{"MX válido e consulta bem-sucedida?"}
G -- "Não" --> R2["Rejeita envio (DNS/MX)"]
G -- "Sim" --> H["Salva domínio no cache (TTL)"]
H --> OK
Na prática, a combinação sintaxe + MX + cache costuma entregar o melhor custo-benefício: reduz tentativa inútil, limpa o pipeline e melhora os números que importam, especialmente quando sua plataforma cobra por volume de envios.
Limites e Cuidados com MX
Utilizando MX, podem acontecer:
- Timeout e instabilidade: um erro temporário de DNS não deveria necessariamente "invalidar" e-mail para sempre.
- Domínio catch-all: alguns servidores aceitam qualquer destinatário e só falham depois (ou nunca falham).
- Política de erro: se MX falhar por timeout: Negar? Re-tentar? Permitir e observar?
Uma política simples e eficiente:
- 1 retry rápido com backoff pequeno
- Se falhar de novo: marca como “indeterminado” por X minutos
- Faz log de tudo (latência e tipo de erro, por exemplo)
Validar melhor não é apenas evitar erros: é gastar menos, medir melhor e operar com previsibilidade.
Post realizado originalmente no meu blog: freitaschz.com
Nem todos os posts são republicados em outras plataformas, e esta versão pode estar desatualizada em relação à original.
A versão definitiva sempre estará disponível no blog e, se achar interessante, recomendo conferir outros conteúdos por lá 🙂