Validar un correo electrónico parece trivial hasta que te topas con direcciones como `usuario+etiqueta@sub.dominio.co` o `"nombre con espacios"@ejemplo.com`, ambas técnicamente válidas según el RFC 5322. Este validador de email comprueba la sintaxis local en el navegador, sin llamadas externas, y explica qué parte de la dirección falla cuando el formato no es correcto: el nombre local, el símbolo arroba o el dominio.
La sintaxis real de un email según RFC 5322
El estándar que define el formato de un correo es mucho más permisivo de lo que la mayoría de formularios asume: permite comillas, puntos consecutivos entre comillas, y caracteres especiales como !#$%&'*+-/=?^_\{|}~` en la parte local sin comillas. En la práctica, casi ningún proveedor de correo real permite todo ese rango, así que los validadores útiles aplican un subconjunto pragmático del RFC en lugar de la gramática completa, que generaría falsos positivos con direcciones sintácticamente legales pero inexistentes.
Parte local, arroba y dominio: qué se comprueba en cada tramo
La parte local (antes de la @) admite letras, números y algunos símbolos, con un máximo práctico de 64 caracteres según RFC 5321. El dominio debe tener al menos un punto, cada etiqueta entre puntos debe empezar y terminar con carácter alfanumérico, no puede superar 63 caracteres por etiqueta ni 253 en total, y el TLD final debe tener al menos dos caracteres alfabéticos. El validador señala en qué tramo está el error para que la corrección sea inmediata.
Direcciones con subdominios, más (+) y punycode
Direcciones como pedidos+urgente@facturacion.miempresa.com son perfectamente válidas: el + es un separador de etiqueta que Gmail y otros proveedores usan para filtrar correo automáticamente, y no debe eliminarse en la validación. Los dominios internacionalizados (IDN) se codifican en punycode, con el prefijo xn--, por ejemplo xn--nxasmq6b para caracteres no latinos; el validador acepta esta forma como válida aunque no sea legible a simple vista.
Por qué la validación de formato no garantiza que el correo exista
Una dirección puede tener sintaxis perfecta y no existir, o pertenecer a un dominio sin servidor de correo configurado. La única forma de confirmar que un email puede recibir mensajes es comprobar sus registros MX con una consulta DNS, o enviar un correo de verificación con enlace de confirmación (double opt-in). La validación de formato es el primer filtro, barato y sin coste de red, pero nunca sustituye a la verificación real en flujos de alta de usuarios.
Errores comunes al validar con expresiones regulares caseras
La regex más citada en internet (^[\w.-]+@[\w.-]+\.\w+$) rechaza direcciones legítimas con +, con TLD de más de 3 letras como .travel o .photography, y con subdominios de correo como mail.empresa.com. También suele fallar con dominios de un solo carácter en cada etiqueta o con nuevos gTLD extensos. Usa siempre un validador probado contra casos reales, no una regex improvisada, sobre todo si el correo se usa para facturación o notificaciones legales.
Uso combinado con el validador de IP y otras herramientas del sitio
En formularios de contacto o registro que también piden datos técnicos, es habitual validar el email junto a otros campos como una IP de origen (con el validador de IP) o un dominio (con herramientas de DNS lookup). Mantener cada validación como una función independiente y pura facilita testear cada regla por separado y reutilizarla tanto en frontend como en backend, evitando duplicar lógica distinta en cada capa.
Casos de uso comunes
- Validar el campo email de un formulario de registro antes de enviarlo al backend.
- Depurar por qué una dirección corporativa con subdominio es rechazada por un sistema legado.
- Limpiar una lista de correos importada de un CSV detectando entradas mal formadas.
- Comprobar si un email con etiqueta (+) es sintácticamente válido antes de filtrarlo.
- Enseñar a un equipo de soporte a distinguir un error de formato de un problema de entrega.
Buenas prácticas
- Combina siempre la validación de formato con un double opt-in por correo real.
- No rechaces el símbolo + en la parte local: es un uso legítimo y extendido.
- Limita la longitud total a 254 caracteres según el máximo práctico de RFC 5321.
- Normaliza a minúsculas el dominio (no la parte local, que puede ser sensible a mayúsculas).
- Verifica registros MX en el backend antes de dar por válida una dirección crítica de facturación.