Regex para Validação de Email: Padrões Que Realmente Funcionam

A validação de email é um dos casos de utilização mais comuns de regex — e um dos mais mal compreendidos. A especificação RFC 5321 para endereços de email é surpreendentemente complexa, e nenhum regex único consegue validá-la completamente. Mas padrões práticos que cobrem 99,9% dos endereços de email reais são alcançáveis e úteis.

O Padrão Simples (Suficientemente Bom)

Para a maioria das aplicações, este padrão funciona bem:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

O que corresponde: Um ou mais caracteres permitidos, seguidos de @, seguidos de um domínio com pelo menos um ponto e um TLD de 2+ letras.

JavaScript:

const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
emailRegex.test('user@example.com');  // true
emailRegex.test('user@.com');          // false

Teste este padrão com o nosso Testador de Regex.

Por Que a Validação Perfeita com Regex É Impossível

A especificação de email (RFC 5321/5322) permite estruturas que são válidas mas essencialmente nunca utilizadas na prática:

"john..doe"@example.com           // Quoted local part with consecutive dots
user@[192.168.1.1]                // IP address as domain
"very.(),:;<>[]".VERY."very@\ "very".unusual"@strange.example.com

Um regex que trate todos os endereços válidos segundo o RFC tem milhares de caracteres e ainda pode não cobrir todos os casos limite. A abordagem prática: utilize um regex simples para validação básica de formato e depois verifique se o email realmente existe enviando uma confirmação.

Análise do Padrão

Parte Local (antes do @)

[a-zA-Z0-9._%+-]+

• Letras (maiúsculas e minúsculas)
• Dígitos
• Pontos, sublinhados, percentagem, mais, hífen
• Um ou mais caracteres

Erros comuns:

• Permitir pontos no início ou no fim (tecnicamente inválido)
• Permitir pontos consecutivos (tecnicamente inválido sem aspas)
• Ser demasiado restritivo (bloquear caracteres válidos como + utilizado em aliases do Gmail)

Parte do Domínio (após o @)

[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

• Caracteres alfanuméricos, pontos, hífens
• Pelo menos um ponto
• TLD de 2+ caracteres alfabéticos

Erros comuns:

• Restringir o comprimento do TLD a 3-4 caracteres (.museum, .photography existem)
• Não permitir hífens em nomes de domínio
• Não tratar subdomínios (user@mail.example.co.uk)

Padrões Melhores

Padrão HTML5

A especificação HTML5 define este padrão para <input type="email">:

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$

Este é mais permissivo na parte local e mais rigoroso quanto aos comprimentos dos rótulos de domínio.

Padrão Prático Recomendado

^[^\s@]+@[^\s@]+\.[^\s@]{2,}$

Este padrão minimal simplesmente garante: sem espaços, um @, pelo menos um ponto após o @, TLD de 2+ caracteres. É intencionalmente permissivo — captura entradas obviamente erradas sem rejeitar endereços incomuns mas válidos.

Implementação Específica por Linguagem

JavaScript

function isValidEmail(email) {
  // Basic regex check
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/;
  if (!regex.test(email)) return false;
  
  // Additional checks
  if (email.length > 254) return false;  // RFC 5321 limit
  const [local] = email.split('@');
  if (local.length > 64) return false;   // RFC 5321 limit
  
  return true;
}

Python

import re

def is_valid_email(email: str) -> bool:
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    if not re.match(pattern, email):
        return False
    if len(email) > 254:
        return False
    local, domain = email.rsplit('@', 1)
    if len(local) > 64:
        return False
    return True

Para Além do Regex: Validação Adequada de Email

O regex é apenas a primeira linha de defesa. Uma estratégia de validação completa:

1. Verificação de formato (regex): Rejeitar formatos obviamente inválidos
2. Verificação de comprimento: Parte local ≤ 64 caracteres, total ≤ 254 caracteres
3. Verificação DNS: Verificar se o domínio tem registos MX
4. Deteção de email descartável: Bloquear serviços de email temporário se necessário
5. Email de confirmação: A única forma de verdadeiramente verificar um email — enviar uma mensagem e confirmar que o utilizador a recebe

// DNS MX record check (Node.js)
const dns = require('dns');
const [, domain] = email.split('@');
dns.resolveMx(domain, (err, addresses) => {
  if (err || !addresses.length) {
    console.log('Domain has no email server');
  }
});

Erros Comuns a Evitar

1. Padrões demasiado restritivos: Bloquear user+tag@gmail.com (endereçamento com mais) ou user@subdomain.example.com
2. Sensibilidade a maiúsculas/minúsculas: As partes locais de email podem ser sensíveis a maiúsculas/minúsculas segundo o RFC, mas na prática, trate-as como insensíveis
3. Remoção de espaços: Remova sempre espaços em branco antes da validação — " user@example.com " deve passar
4. Domínios internacionais: .münchen e 用户@例え.jp são válidos em email internacionalizado

Para mais padrões regex, consulte a nossa Folha de Consulta Regex.

FAQ

Devo validar email com regex no cliente ou no servidor?

Ambos. A validação do lado do cliente fornece feedback instantâneo (melhor experiência de utilizador). A validação do lado do servidor é obrigatória por segurança (as verificações do cliente podem ser contornadas). Nunca confie apenas na validação do lado do cliente.

Por que é que alguns sítios web rejeitam o meu endereço de email válido?

Padrões regex demasiado restritivos são a causa habitual. Endereços com + (aliases do Gmail), TLDs longos (.technology) ou subdomínios são frequentemente rejeitados por validação deficiente. Se mantém um sítio web, utilize regex permissivo e verifique com um email de confirmação.

Recursos Relacionados

• Testador de Regex — Teste padrões de validação de email em tempo real
• Folha de Consulta Regex — Referência completa de padrões regex
• Guia de Validação de JSON Schema — Validar campos de email em JSON com format: email