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

A validação de email é um dos casos de uso 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 isolado consegue validá-la completamente. Porém, padrões práticos que cobrem 99,9% dos endereços de email reais são totalmente viáveis e úteis.

O Padrão Simples (Bom o Suficiente)

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 ele corresponde: Um ou mais caracteres permitidos, seguido de @, seguido de um domínio com pelo menos um ponto e um TLD de 2 ou mais 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 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 usadas na prática:

"john..doe"@example.com           // Parte local entre aspas com pontos consecutivos
user@[192.168.1.1]                // Endereço IP como domínio
"very.(),:;<>[]".VERY."very@\ "very".unusual"@strange.example.com

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

Detalhamento do Padrão

Parte Local (antes do @)

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

• Letras (maiúsculas e minúsculas)
• Dígitos
• Pontos, sublinhados, porcentagem, 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 muito restritivo (bloqueando caracteres válidos como + usado 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 ou mais 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 ao comprimento dos rótulos do domínio.

Padrão Prático Recomendado

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

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

Implementação por Linguagem

JavaScript

function isValidEmail(email) {
  // Verificação básica com regex
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/;
  if (!regex.test(email)) return false;
  
  // Verificações adicionais
  if (email.length > 254) return false;  // Limite RFC 5321
  const [local] = email.split('@');
  if (local.length > 64) return false;   // Limite RFC 5321
  
  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

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

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 de DNS: Verificar se o domínio possui registros MX
4. Detecção de email descartável: Bloquear serviços de email temporário, se necessário
5. Email de confirmação: A única forma de realmente verificar um email — enviar uma mensagem e confirmar que o usuário a recebeu

// Verificação de registro MX via DNS (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 muito restritivos: Bloquear user+tag@gmail.com (plus addressing) ou user@subdomain.example.com
2. Diferenciação de maiúsculas: Partes locais de email podem diferenciar maiúsculas por RFC, mas na prática, trate como insensível a maiúsculas
3. Espaços extras: Sempre remova espaços antes da validação — " user@example.com " deve ser aceito
4. Domínios internacionais: .münchen e 用户@例え.jp são válidos em email internacionalizado

Para mais padrões regex, veja nosso Guia de Referência Regex.

Perguntas Frequentes

Devo validar email com regex no cliente ou no servidor?

Ambos. A validação no cliente oferece feedback instantâneo (melhor UX). A validação no servidor é obrigatória por segurança (verificações no cliente podem ser contornadas). Nunca confie apenas na validação do lado do cliente.

Por que alguns sites rejeitam meu endereço de email válido?

Padrões regex excessivamente restritivos são a causa usual. Endereços com + (aliases do Gmail), TLDs longos (.technology) ou subdomínios frequentemente são rejeitados por validações mal feitas. Se você mantém um site, use 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
• Guia de Referência Regex — Referência completa de padrões regex
• Guia de Validação JSON Schema — Valide campos de email em JSON com format: email