O que Torna um E-mail Válido? Regras Técnicas e Validação
A maioria dos devs usa uma regex simples para validar e-mails, mas a realidade é mais complexa. Este guia cobre as regras da RFC 5321/5322, exemplos surpreendentes, regex balanceada para uso real, validação por DNS MX, suporte a IDN/Unicode e detecção de e-mails descartáveis.
Por Vitor Morais
Fundador do MochaLabz ·
Valide e-mails em massa, no navegador
Detecte formato inválido, domínios descartáveis e typos comuns — sem enviar dados.
Usar validador de e-mail →Validar e-mail parece um problema simples — todo dev escreve uma regex em 30 segundos. Mas a realidade técnica é surpreendentemente complexa. As RFCs 5321 e 5322 permitem endereços que parecem inválidos, e ao mesmo tempo strings que parecem válidas podem não chegar a lugar nenhum. Este guia cobre a estrutura formal de um e-mail, os caracteres permitidos, exemplos que surpreendem, a abordagem prática para validação em produção (regex balanceada + MX + verificação) e os erros mais frequentes.
A estrutura de um endereço de e-mail
Todo endereço tem duas partes separadas pelo caractere @:
usuario.nome+tag@subdominio.exemplo.com.br
└────────┬───────┘ └─────────┬─────────┘
parte local domínio
(até 64 chars) (até 253 chars)
Total do e-mail: até 254 caracteres (RFC 5321)- Parte local: tudo antes do @. Identifica a caixa específica dentro do servidor.
- @: separador obrigatório. Aparece exatamente uma vez (exceto dentro de aspas).
- Domínio: servidor que recebe a mensagem. Tem labels separados por ponto, terminando em TLD.
Regras da parte local (RFC 5321 §4.5.3.1)
A parte local pode conter:
- Letras (a-z, A-Z) e dígitos (0-9).
- Caracteres especiais:
! # $ % & ' * + - / = ? ^ _ ` { | } ~. - Ponto
.— mas não no início, fim ou consecutivo. - Entre aspas (
"..."): qualquer caractere, incluindo espaço, parêntese, vírgula. Mas servidores reais frequentemente rejeitam.
Comprimento máximo da parte local: 64 caracteres.
Regras do domínio
- Composto por labels separados por ponto (label = string alfanumérica de até 63 chars; pode ter hífen mas não no início ou fim).
- Comprimento total do domínio: até 253 caracteres.
- Deve ter pelo menos 2 labels (TLD + nome):
example.com. Entre 2 e 127 labels totais. - Pode ser endereço IP literal entre colchetes:
user@[192.168.1.1]— válido tecnicamente, mas raramente aceito por servidores reais.
E-mails válidos que surpreendem
Estes endereços são tecnicamente válidos pela RFC, embora pareçam estranhos:
user+tag@gmail.com ✅ plus addressing (alias)
user.name@domain.com ✅ ponto interno
"first last"@domain.com ✅ aspas + espaço
user@[192.168.1.1] ✅ IP literal
admin@example.museum ✅ TLD longo
ana@café.com.br ✅ IDN (RFC 6531)
用户@例え.jp ✅ Unicode parte local + domínio
"@"@example.com ✅ @ literal entre aspas
disposable!#$%@example.com ✅ caracteres especiais permitidos
a@b.co ✅ super curto
abc@x.x.x.x.x.x.x.x.x.com ✅ múltiplos subdomíniosE-mails inválidos comuns
user@ ❌ sem domínio
@domain.com ❌ sem parte local
user..name@d.com ❌ pontos consecutivos na parte local
.user@d.com ❌ ponto no início
user.@d.com ❌ ponto no fim
user@domain ❌ sem TLD
user name@d.com ❌ espaço sem aspas
user@@domain.com ❌ dois @ fora de aspas
user@-domain.com ❌ label começando com hífen
user@domain.com. ❌ ponto trailing no domínio (alguns aceitam)
user@.domain.com ❌ ponto no início do domínioValidação na prática: 4 níveis de rigor
A escolha do nível depende do quanto você precisa garantir que o e-mail é entregável:
| Critério | O que verifica | Custo | Quando usar |
|---|---|---|---|
| 1. Regex balanceada | Formato básico | Microssegundos | Feedback em formulário (sempre) |
| 2. Regex + lista de domínios | Formato + bloqueio de descartáveis | Microssegundos | Cadastros que precisam ser "sérios" |
| 3. + DNS MX lookup | Domínio aceita e-mail? | 50–500 ms | Lista de marketing, redução de bounce |
| 4. + Verificação por envio | E-mail é entregável e do usuário? | Async (não bloqueia) | Confirmar identidade, signup sério |
A regex balanceada para uso real
A regex 100% conforme RFC 5322 tem 6.000+ caracteres e é inutilizável. A regex que recomendamos para 99% das aplicações:
// JavaScript — regex balanceada (cobre 99% dos casos reais)
const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
function isValidEmail(email: string): boolean {
if (!email) return false;
const trimmed = email.trim().toLowerCase();
if (trimmed.length > 254) return false; // RFC max
return EMAIL_REGEX.test(trimmed);
}
// Versão um pouco mais rígida (ainda sem cobrir 100% RFC)
const STRICT = /^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i;
// HTML5: input type="email" usa uma regex parecida (limitada)
<input type="email" required />Por que NÃO usar regex super complexa
A regex perfeita aceita "@"@example.com como válido (e tecnicamente é). Em produção, isso é ruim: confunde o usuário, cria estranhezas em logs, abre vetor de ataque. A regex balanceada é mais restritiva que a RFC, mas captura 99% dos e-mails reais sem aceitar lixo.
Validação no HTML (input type=“email”)
<form>
<input
type="email"
name="email"
required
pattern="[^\s@]+@[^\s@]+\.[^\s@]+"
autoComplete="email"
inputMode="email"
placeholder="seu@email.com"
/>
</form>
<!-- O navegador faz validação básica automaticamente.
pattern adiciona regex custom.
inputMode="email" mostra teclado correto no mobile. -->Validação por DNS MX (verifica se domínio aceita e-mail)
Antes de aceitar uma lista de e-mails, vale fazer lookup DNS para confirmar que o domínio tem servidor de e-mail configurado:
// Node.js
import { resolveMx } from 'dns/promises';
async function hasMxRecord(email: string): Promise<boolean> {
const domain = email.split('@')[1];
if (!domain) return false;
try {
const records = await resolveMx(domain);
return records.length > 0;
} catch {
return false;
}
}
// Uso
await hasMxRecord('test@gmail.com'); // true
await hasMxRecord('test@gnail.com'); // false (typo)
await hasMxRecord('test@dominio-morto.com'); // falseOtimização
Cache os resultados de MX por 24h em Redis — domínios não mudam configuração de e-mail toda hora. Reduz custo e latência em ~99% dos lookups subsequentes.
Detecção de typos comuns (Gmail.com → Gnail.com)
Erros de digitação em domínios populares são comuns. Use algoritmo de distância de Levenshtein contra lista dos top 50 provedores:
const POPULAR_DOMAINS = [
'gmail.com', 'yahoo.com.br', 'hotmail.com', 'outlook.com',
'icloud.com', 'live.com', 'uol.com.br', 'bol.com.br',
'terra.com.br', 'globo.com', 'protonmail.com',
];
function levenshtein(a: string, b: string): number {
// implementação clássica omitida por brevidade
// — use lib como fastest-levenshtein
}
function suggestCorrection(email: string): string | null {
const domain = email.split('@')[1]?.toLowerCase();
if (!domain || POPULAR_DOMAINS.includes(domain)) return null;
for (const popular of POPULAR_DOMAINS) {
if (levenshtein(domain, popular) <= 2) {
return email.replace(domain, popular);
}
}
return null;
}
suggestCorrection('ana@gnail.com'); // 'ana@gmail.com'
suggestCorrection('joao@hotmial.com'); // 'joao@hotmail.com'E-mails internacionalizados (IDN — RFC 6531)
Desde 2012, e-mails podem conter Unicode tanto na parte local quanto no domínio. Suporte é desigual:
| Critério | Recebe IDN? | Envia IDN? |
|---|---|---|
| Gmail | ✅ Sim | Parcial |
| Outlook / Microsoft 365 | ✅ Sim | Sim |
| Yahoo Mail | ⚠️ Limitado | Não |
| iCloud | ⚠️ Limitado | Não |
| Servidores corporativos típicos | Geralmente não | Geralmente não |
Para suportar IDN, use libs específicas como email-addresses (Node) ou email-validator (Python). Regex simples vai rejeitar caracteres não-ASCII.
Plus addressing: o + que ninguém deveria bloquear
Gmail (e muitos outros) ignoram tudo após + na parte local para fins de entrega. Útil para criar aliases:
ana@gmail.com ← caixa principal
ana+newsletter@gmail.com ← chega na mesma caixa
ana+amazon@gmail.com ← chega na mesma caixa
ana+empresa.x@gmail.com ← chega na mesma caixa
// Vantagem: usuário rastreia quem vendeu o e-mail dele.
// Se receber spam em ana+amazon@gmail.com, sabe que Amazon vazou.
// ❌ ERRADO: bloquear + na validação
const BAD = /^[^+]+@[^+]+$/; // rejeita plus addressing
// ✅ CORRETO: aceitar + normalmente
const OK = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;E-mails descartáveis
Domínios como mailinator.com, guerrillamail.com, 10minutemail.com e tempmail.org oferecem caixas temporárias. Para serviços que precisam validar identidade real, vale bloquear:
// Lista mantida pela comunidade no GitHub:
// disposable-email-domains/disposable-email-domains
// (mais de 100k domínios listados em 2026)
import disposable from 'disposable-email-domains';
const DISPOSABLE = new Set(disposable);
function isDisposable(email: string): boolean {
const domain = email.split('@')[1]?.toLowerCase();
return Boolean(domain && DISPOSABLE.has(domain));
}
isDisposable('user@mailinator.com'); // true
isDisposable('user@gmail.com'); // falsePonderação
Bloquear descartáveis filtra fakes mas pode irritar usuários legítimos que valorizam privacidade. Para SaaS sério (B2B, financeiro): vale bloquear. Para newsletter, blog, conteúdo aberto: pode soltar.
Verificação por envio (a única forma 100% certa)
Regex e MX validam formato e domínio; só verificação por envio confirma que o usuário tem acesso à caixa. Padrão clássico:
- Usuário cadastra com e-mail.
- Sistema gera token único e envia link/código por e-mail.
- Usuário clica no link ou cola o código no app.
- Sistema marca o e-mail como verificado no banco.
- Funcionalidades sensíveis (transferência, mudança de senha) exigem e-mail verificado.
Erros comuns na validação de e-mail
Anti-padrões frequentes
- Bloquear + na parte local: impede plus addressing, irrita usuários técnicos.
- Bloquear .co (domínios de 2 letras): colombianos e startups com .co são válidos.
- Aceitar duplicatas case-sensitive: user@gmail.com e User@Gmail.com viram contas diferentes. Normalize sempre para lowercase.
- Validar só no front-end: qualquer cliente pode burlar. Sempre valide no backend também.
- Não aceitar TLDs novos: .dev, .app, .io, .ai são válidos. Não restrinja a uma lista.
- Confiar em SMTP VRFY: a maioria dos servidores desabilitou esse comando — não use.
- Catchall domains: alguns domínios aceitam QUALQUER endereço — verificação por envio é o único jeito certo nesses casos.
Padrão recomendado (resumo)
- No formulário: regex balanceada + sugestão de typo (Gnail → Gmail) para feedback rápido.
- No backend: mesma regex (defesa em profundidade) + opcionalmente bloqueio de descartáveis.
- Antes de promover usuário: verificação por envio de código.
- Em listas grandes (e-mail marketing): adicione lookup MX em background para reduzir bounce.
- Sempre normalize: trim + toLowerCase antes de armazenar e comparar.
Para implementação prática em código, veja como validar e-mail em JavaScript e como limpar lista de e-mails inválidos.
Checklist da validação correta de e-mail
- ✅ Regex balanceada (não ultra-permissiva nem ultra-restritiva).
- ✅ Aceita
+(plus addressing). - ✅ Aceita TLDs longos e novos (.dev, .museum, .photography).
- ✅ Normaliza para lowercase + trim antes de armazenar.
- ✅ Sugestão de correção de typo em domínios populares.
- ✅ Lookup MX em background para listas grandes.
- ✅ Bloqueio de descartáveis quando faz sentido para o produto.
- ✅ Verificação por envio antes de funcionalidades sensíveis.
- ✅ Validação tanto no front quanto no backend.
- ✅ Suporte a IDN (Unicode) se a aplicação atende mercados internacionais.
Perguntas frequentes
Qual a diferença entre RFC 5321 e RFC 5322 na validação de e-mail?+
RFC 5321 define o protocolo SMTP — o formato que servidores aceitam para entregar mensagens. RFC 5322 define o formato de mensagem (cabeçalho, corpo). Em validação prática, RFC 5321 é mais relevante porque define o que servidor SMTP aceita receber. RFC 5322 permite ainda mais variantes, mas servidores reais (Gmail, Outlook) frequentemente rejeitam coisas que RFC 5322 permite.
Existe uma regex perfeita para validar e-mail?+
Existe — a regex 100% conforme RFC 5322 tem mais de 6000 caracteres e é inutilizável na prática. Para apps reais, use uma regex balanceada que cobre 99% dos casos válidos sem aceitar lixo: /^[^\s@]+@[^\s@]+\.[^\s@]+$/. Para validar de verdade, faça verificação por e-mail (envia link/código para o endereço).
Posso validar e-mail só com regex no formulário?+
Não. Regex valida formato (existe @? tem TLD?), mas não valida existência. test@example.com passa em qualquer regex e não existe. Para garantir que o e-mail é entregável: (1) regex no front para feedback rápido, (2) consulta DNS MX para verificar se domínio aceita e-mail, (3) verificação por envio de código para o endereço. Os três juntos cobrem 95% dos casos.
user+tag@gmail.com é válido?+
Sim. O Gmail (e muitos outros provedores) usa plus addressing: tudo após o + é ignorado para entrega, mas mantido como parte do endereço. Útil para criar aliases (newsletter+amazon@gmail.com chega na caixa de newsletter@gmail.com). Sua regex de validação NUNCA deve rejeitar +. Bloquear isso é bug clássico que irrita usuários técnicos.
E-mails com letras maiúsculas são diferentes de minúsculas?+
Tecnicamente, RFC 5321 diz que a parte local PODE ser case-sensitive (User@gmail.com ≠ user@gmail.com em teoria). Na prática, todos os principais provedores tratam como case-insensitive. O domínio é sempre case-insensitive. A boa prática é normalizar para lowercase antes de armazenar para evitar duplicação de cadastro.
E-mails internacionalizados (IDN) são suportados?+
Desde 2012 (RFC 6531/6532), e-mails podem ter caracteres Unicode tanto na parte local quanto no domínio (ex: ana@café.com.br, 用户@例え.jp). Mas o suporte é incompleto: Gmail e Outlook aceitam recebimento, mas a maioria dos servidores corporativos ainda não. Se sua aplicação precisa internacionalização, use libs específicas; regex simples vai rejeitar.
Por que validar contra MX record (DNS)?+
Validação MX confirma que o domínio tem servidor de e-mail configurado para receber mensagens. Detecta typos comuns (gnail.com em vez de gmail.com), domínios mortos e e-mails fakes. Custo: 1 lookup DNS (~50-200ms). Benefício: reduz drasticamente bounce rate em listas de e-mail marketing. Para alta escala, faça em background, não bloqueando o cadastro.
Vale a pena bloquear e-mails descartáveis?+
Depende do produto. Para produtos B2B sérios e SaaS com plano gratuito, sim — descartáveis pulam a barreira de "verificar e-mail" e geram contas fakes. Para produtos onde o cadastro é casual (newsletter, conteúdo aberto), bloquear pode irritar usuários legítimos que usam alias temporário por privacidade. Use listas mantidas (disposable-email-domains no GitHub) e atualize mensalmente.
Continue lendo
Como Validar E-mail em JavaScript (2026): Regex, HTML5 e Validação Real
Guia completo para validar e-mails em JavaScript: regex prático, HTML5 type=email, validação no frontend vs backend, bibliotecas e como confirmar se o endereço existe.
Como Limpar Lista de E-mails Inválidos (2026): Guia Completo para Evitar Bounce
Guia definitivo de limpeza de lista de e-mails: tipos de bounce, ferramentas de validação em massa, processo passo a passo, reputação de domínio e como manter lista limpa.
Validação de Documentos Brasileiros em Formulários (2026): CPF, CNPJ, CEP, Telefone
Guia completo de validação de documentos BR em formulários web: CPF, CNPJ, CEP, telefone, RG, PIS. Máscara em tempo real, regex, frontend vs backend e UX recomendada.
Regex para Validação de Formulários (2026): E-mail, CPF, Telefone, CEP
Coleção de regex prontas para campos brasileiros: e-mail, CPF, CNPJ, telefone, CEP, URL, data, senha forte, cartão. Inclui máscara em tempo real, integração React e ReDoS.