Caso real

Regex para e-mail: formato, grupos e limites de validação

Uma expressão de e-mail é útil para rejeitar erros óbvios e ensinar estrutura, mas confirmação por mensagem continua sendo a prova de que a caixa existe.

Ideia central: Regex valida ou encontra padrões de texto. Quando houver regra de negócio, cálculo ou semântica, use código complementar em vez de forçar tudo para dentro da expressão.
EM 30 SEGUNDOS

O que você precisa decidir antes do padrão

Use Regex para verificar se o texto tem uma estrutura de e-mail plausível. Não use a expressão como prova de que a caixa postal existe.

Pense no problema antes de escrever Regex

Um padrão fica mais simples quando a regra já está clara. Para este caso, siga esta sequência:

  1. 01Separe o endereço em três partes que você realmente precisa observar: usuário, domínio e sufixo.
  2. 02Exija o caractere @ apenas uma vez no ponto de separação.
  3. 03Defina uma regra simples para o TLD e deixe validações de existência para confirmação por e-mail.

Uma Regex didática e legível

Para muitos formulários educacionais, uma expressão razoável é:

^(?<usuario>[\w.%+-]+)@(?<dominio>[\w.-]+)\.(?<tld>[A-Za-z]{2,})$

Os três grupos nomeados permitem visualizar usuário, domínio e TLD separadamente no Raio-X.

Casos que devem passar e falhar

Passa:
dev@site.com
marcello.dev+news@empresa.com.br

Falha:
@site.com
dev@site
nome com espaco@site.com

Não teste apenas exemplos felizes. É nos casos negativos que um padrão permissivo demais aparece.

Por que não tentar implementar toda a RFC em uma Regex

A sintaxe completa de endereços de e-mail possui detalhes pouco úteis para a maioria dos formulários. Uma Regex enorme pode ficar difícil de revisar e ainda não prova que o endereço recebe mensagens.

Em cadastro real, valide um formato razoável, normalize o que fizer sentido e confirme a propriedade enviando um link ou código.

No backend e no frontend

Use a mesma intenção de validação nos dois lados, mas trate o backend como fonte de verdade. O frontend melhora a experiência; ele não impede requisições feitas fora da interface.

Como ler o padrão em partes

Em vez de memorizar a expressão inteira, leia cada bloco pela responsabilidade que ele cumpre:

^ e $obrigam a expressão a avaliar o valor inteiro, evitando aceitar texto extra antes ou depois.
(?...)isola a parte antes do @ e permite enxergá-la separadamente no Raio-X.
@é tratado como caractere literal e marca a divisão central do endereço.
(?...)captura o domínio, mas não tenta provar que esse domínio realmente existe.
(?[A-Za-z]{2,})exige ao menos duas letras no final, uma regra didática útil, não uma implementação completa dos padrões de e-mail.
QUANDO USAR

Onde Regex agrega valor aqui

É uma boa escolha para feedback rápido em formulários, filtros de texto e exercícios de captura. Em cadastro real, combine com validação no servidor e confirmação por mensagem.

ARMADILHAS

Erros comuns

  • Tentar reproduzir toda a especificação de e-mail em uma única Regex gigantesca.
  • Aceitar espaços silenciosamente ou validar apenas com um contains("@").
  • Confiar somente no frontend: o backend ainda precisa validar o formato recebido.
  • Confundir formato válido com endereço existente.

Teste e pratique

Use o Playground para experimentar o padrão com seus próprios dados e depois leve o conceito para as fases do jogo, onde os casos positivos e negativos são avaliados automaticamente.

Praticar no jogoAbrir Playground

Continue aprendendo

← Voltar ao hub de Regex