Regex para Validación de Email: Patrones que Realmente Funcionan

La validación de email es uno de los casos de uso más comunes de regex — y uno de los más malinterpretados. La especificación RFC 5321 para direcciones de correo electrónico es sorprendentemente compleja, y ningún regex individual puede validarla completamente. Pero los patrones prácticos que cubren el 99.9% de las direcciones de email reales son alcanzables y útiles.

El Patrón Simple (Suficientemente Bueno)

Para la mayoría de las aplicaciones, este patrón funciona bien:

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

Lo que coincide: Uno o más caracteres permitidos, seguidos de @, seguidos de un dominio con al menos un punto y un 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

Prueba este patrón con nuestro Probador de Regex.

Por Qué la Validación Perfecta con Regex Es Imposible

La especificación de email (RFC 5321/5322) permite estructuras que son válidas pero esencialmente nunca se usan en la práctica:

"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

Un regex que maneje todas las direcciones válidas según RFC tiene miles de caracteres y aún puede no cubrir todos los casos límite. El enfoque práctico: usa un regex simple para validación básica de formato, luego verifica que el email realmente exista enviando una confirmación.

Desglose del Patrón

Parte Local (antes de @)

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

• Letras (mayúsculas y minúsculas)
• Dígitos
• Puntos, guiones bajos, porcentaje, más, guión
• Uno o más caracteres

Errores comunes:

• Permitir puntos al inicio o final (técnicamente inválido)
• Permitir puntos consecutivos (técnicamente inválido sin comillas)
• Ser demasiado restrictivo (bloquear caracteres válidos como + usado en alias de Gmail)

Parte del Dominio (después de @)

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

• Caracteres alfanuméricos, puntos, guiones
• Al menos un punto
• TLD de 2+ caracteres alfabéticos

Errores comunes:

• Restringir la longitud del TLD a 3-4 caracteres (.museum, .photography existen)
• No permitir guiones en nombres de dominio
• No manejar subdominios (user@mail.example.co.uk)

Mejores Patrones

Estándar HTML5

La especificación HTML5 define este patrón 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 es más permisivo en la parte local y más estricto con las longitudes de etiquetas de dominio.

Patrón Práctico Recomendado

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

Este patrón mínimo simplemente asegura: sin espacios, un @, al menos un punto después de @, TLD de 2+ caracteres. Es intencionalmente permisivo — captura entradas obviamente incorrectas sin rechazar direcciones inusuales pero válidas.

Implementación Específica por Lenguaje

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

Más Allá de Regex: Validación Correcta de Email

Regex es solo la primera línea de defensa. Una estrategia de validación completa:

1. Verificación de formato (regex): Rechaza formatos obviamente inválidos
2. Verificación de longitud: Parte local ≤ 64 caracteres, total ≤ 254 caracteres
3. Verificación DNS: Verifica que el dominio tenga registros MX
4. Detección de email desechable: Bloquea servicios de email temporales si es necesario
5. Email de confirmación: La única forma de verificar verdaderamente un email — envía un mensaje y confirma que el usuario lo recibe

// 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');
  }
});

Errores Comunes a Evitar

1. Patrones demasiado restrictivos: Bloquear user+tag@gmail.com (direccionamiento plus) o user@subdomain.example.com
2. Sensibilidad a mayúsculas: Las partes locales del email pueden ser sensibles a mayúsculas según RFC, pero en la práctica, trátalas como insensibles
3. Recorte de espacios: Siempre recorta espacios en blanco antes de validar — " user@example.com " debería pasar
4. Dominios internacionales: .münchen y 用户@例え.jp son válidos en email internacionalizado

Para más patrones regex, consulta nuestra Hoja de Referencia de Regex.

Preguntas Frecuentes

¿Debo validar email con regex en el cliente o en el servidor?

Ambos. La validación del lado del cliente proporciona retroalimentación instantánea (mejor UX). La validación del lado del servidor es obligatoria por seguridad (las verificaciones del cliente pueden ser eludidas). Nunca confíes solo en la validación del lado del cliente.

¿Por qué algunos sitios web rechazan mi dirección de email válida?

Los patrones regex demasiado restrictivos son la causa habitual. Direcciones con + (alias de Gmail), TLDs largos (.technology) o subdominios a menudo son rechazados por validación deficiente. Si mantienes un sitio web, usa regex permisivo y verifica con un email de confirmación en su lugar.

Recursos Relacionados

• Probador de Regex — Prueba patrones de validación de email en tiempo real
• Hoja de Referencia de Regex — Referencia completa de patrones regex
• Validación de JSON Schema — Valida campos de email en JSON con format: email