Validador de Email

Como usar?

Informe o endereço de email no campo acima. A validação segue as regras da RFC, separa cada parte do endereço (local, domínio e TLD) e avisa quando encontra erros de digitação que costumam passar despercebidos.

Como funciona a validação de email

Um endereço de email tem duas partes separadas por um único @: a parte local (antes do @) e o domínio (depois). A sintaxe é definida pelas RFC 5321 (SMTP) e RFC 5322 (formato de mensagem). Pela RFC 5321 §4.5.3.1, a parte local é limitada a 64 octetos e o domínio a 255 octetos, mas o caminho completo, incluindo os colchetes angulares, não pode passar de 256 octetos — então o limite prático do endereço é 254 caracteres, não os 320 que os limites individuais sugerem ingenuamente.

Esta ferramenta verifica apenas a validade estrutural — um único @, uma parte local não vazia formada pelos caracteres ASCII que a RFC permite um domínio cujos rótulos são letras, dígitos e hífens terminando em um TLD de duas letras ou mais, e os dois tetos acima — 64 octetos na parte local, 254 caracteres no endereço inteiro. Os pontos precisam seguir a regra do dot-atom da RFC 5322: podem ficar entre átomos, nunca no começo, no fim nem dobrados, então [email protected], [email protected] e [email protected] são recusados. Ela não confirma que a caixa postal existe. Para isso seria preciso consultar o registro MX no DNS e depois fazer um handshake SMTP RCPT TO contra o servidor receptor — e mesmo isso é cada vez menos confiável: a maioria dos provedores responde "OK" para qualquer endereço e devolve a mensagem silenciosamente depois, para evitar ataques de enumeração.

Os três níveis de validação

Existem três camadas práticas. A validação sintática (o que esta página faz) pega erros de digitação como @ faltando, um segundo arroba, caracteres ilegais, ponto fora de lugar ou dobrado, domínio sem ponto nenhum ou um TLD com menos de duas letras. A validação DNS vai um passo além e confirma que o domínio tem registro MX ou A — útil para pegar quem digitou gmial.com sem querer. A verificação SMTP abre uma conexão TCP até o servidor MX e tenta um RCPT TO sem enviar a mensagem; as políticas anti-spam modernas (Google, Outlook, Apple) tornam essa abordagem instável e ainda podem listar negativamente o seu IP.

A parte local na verdade aceita um conjunto surpreendentemente amplo de caracteres pela RFC 5321 — incluindo +, ., -, _ e até strings entre aspas com espaços. Muitas regexes encontradas no Stack Overflow rejeitam endereços perfeitamente válidos. O HTML5 inclusive define propositalmente um padrão mais restrito, que recusa alguns endereços válidos pela RFC em troca de pegar erros de digitação do mundo real.

Perguntas frequentes

Por que meu email passa aqui mas o site rejeita? Muitos sites aplicam regras mais apertadas que a RFC — podem proibir o sinal +, exigir TLDs genéricos ou bloquear domínios de email descartáveis. Validade não é a mesma coisa que aceitação.

[email protected] é um endereço real? Sim — o sufixo +tag é válido pela RFC e o Gmail (assim como Outlook e Fastmail) roteia para a caixa base preservando a tag, o que permite filtrar mensagens ou detectar vazamentos.

Esta ferramenta envia algum email? Não. A validação roda inteiramente no seu navegador — nada é enviado para servidor nem para API de terceiros.

E endereços internacionalizados (EAI)? A RFC 6531 permite Unicode tanto na parte local quanto no domínio (josé@niño.es). O suporte entre provedores melhorou muito desde 2020, mas continua irregular — muitos sistemas de email antigos ainda rejeitam caracteres não-ASCII.