📧 Validador de E-mail

Como funciona a validação de e-mail

Um endereço de e-mail tem o formato parte_local@dominio.tld e deve seguir as regras da RFC 5322, padrão internacional da IETF. A validação mínima pelo lado do cliente (no navegador) verifica:

Arroba (@): exatamente uma ocorrência.
Parte local: 1 a 64 caracteres, letras, números, ponto, hífen, sublinhado e alguns especiais.
Domínio: 1 a 253 caracteres, dividido em rótulos por pontos; cada rótulo começa e termina com letra/número.
TLD: 2 a 24 caracteres alfabéticos (.com, .br, .io, .photography etc.).

O que este validador detecta

✅ Formato RFC 5322 (estrutura sintática).
✅ Presença de arroba e pelo menos um ponto após o domínio.
✅ Erros comuns de digitação (gmial.com, hotnail.com, yaho.com, outllok).
❌ Não verifica se o e-mail existe de fato na caixa postal — isso requer tentativa real de envio ou consulta SMTP, impossível do navegador por motivos de segurança e privacidade.

Erros de digitação frequentes

Validação lado cliente vs servidor

A validação feita pelo navegador (como esta) serve para feedback imediato ao usuário e para bloquear envios claramente malformados. No servidor, deve-se adicionar:

Verificação de DNS MX: confirma que o domínio tem servidor de e-mail.
Double opt-in: o usuário recebe um link de confirmação e precisa clicar para validar.
SMTP handshake: em casos extremos, conecta ao servidor SMTP do destinatário para confirmar se a caixa existe (muitos provedores bloqueiam).
Serviços especializados: Kickbox, ZeroBounce, NeverBounce etc. oferecem APIs pagas com alta precisão.

E-mails descartáveis e temporários

Serviços como 10minutemail, mailinator, temp-mail geram e-mails válidos mas temporários. Para evitar cadastros desses, manter uma lista negra atualizada de domínios descartáveis e checá-la no back-end. No formulário público, considerar CAPTCHA para desincentivar cadastros automáticos.

Formatos válidos mas incomuns

A RFC 5322 é permissiva. São válidos e-mails como: "nome.sobrenome"@exemplo.com, usuário+tag@exemplo.com (Gmail aceita plus-addressing), 1234567890@example.com, e até e-mails com caracteres especiais entre aspas. Na prática, a maioria dos sistemas rejeita essas formas, mas elas existem.

Perguntas Frequentes

• Esta ferramenta confirma se o e-mail recebe mensagens?▾

  Não. Ela valida apenas a estrutura (sintaxe). Para confirmar entrega, é necessário enviar um e-mail real ou usar APIs especializadas (Kickbox, ZeroBounce) que fazem verificação SMTP.

• Acentos funcionam em e-mail?▾

  Tecnicamente sim (EAI - Email Address Internationalization, RFC 6531). Na prática, ainda é arriscado: muitos servidores rejeitam. Prefira endereços só com ASCII.

• Posso confiar na sugestão de correção?▾

  A sugestão corrige erros de digitação dos domínios mais comuns (gmail, hotmail etc). Sempre peça ao usuário para confirmar — um "gmial.com" legítimo não existe, mas um domínio corporativo qualquer pode.

• Qual é o e-mail mais longo possível?▾

  Pela RFC 3696 e 5321: máximo 254 caracteres no total (64 parte local + 1 arroba + 253 domínio, mas com limite prático de 254). Endereços acima disso podem ser recusados.

Buscas relacionadas

validador de e-mail, verificar e-mail válido, email válido ou inválido, validar email javascript, rfc 5322 email, regex email.