Validador de email (sintaxis + detección de erratas)
Escribe un email para verificar si la sintaxis es válida y detectar erratas como 'gmial.com' → 'gmail.com'. Desglosa parte local, dominio, TLD y avisa de violaciones de límites RFC.
- Parte local
- user
- Dominio
- example.com
- TLD
- com
- Tag plus (+)
- —
Cómo funciona
Qué hace este validador (y qué no puede)
La validación de sintaxis de email comprueba si 'nombre@dominio.tld' sigue las reglas estructurales del RFC 5322. Usamos una regex pragmática que detecta casi todas las erratas reales manteniéndose flexible para direcciones legítimas con tags plus, puntos y TLDs inusuales.
Lo que NO puede hacer: confirmar que la dirección realmente recibe correo. Eso requiere enviar un email real o hacer una comprobación SMTP, ambos requieren código de servidor y arriesgan falsos positivos (dominios catch-all, greylisting). La validación de sintaxis detecta erratas barato; comprobaciones de entregabilidad necesitan otro enfoque.
Detección de erratas comunes
Vigilamos erratas en los principales proveedores gratis — 'gmial.com' en lugar de 'gmail.com', 'yaho.com' en lugar de 'yahoo.com', etc. Aproximadamente el 95% de erratas en alta de email son erratas de dominio en estos pocos proveedores. Detectarlas en cliente ahorra un email de bienvenida rebotado y un incómodo 'comprueba tu dirección'.
Si construyes un formulario de alta, ejecuta la misma lógica antes de enviar. Muestra una sugerencia '¿Quisiste decir...?' y deja al usuario aceptar o anular. Los flujos maduros lo hacen rutinariamente; mejora notablemente la entregabilidad.
Reglas de la parte local
Tag plus ('user+filter@gmail.com'): ampliamente soportado por proveedores principales. Úsalo para crear direcciones únicas para distintas altas manteniendo una sola bandeja.
Puntos ('user.name@gmail.com'): Gmail los trata como la misma dirección (los puntos se ignoran), pero otros proveedores pueden tratarlos como distintos. No confíes en la equivalencia de puntos fuera de Gmail.
Longitud: RFC 5321 limita la parte local a 64 caracteres y la dirección completa a 254. Avisamos cuando se exceden — la mayoría de servidores rechazan direcciones más largas.
Sensibilidad a mayúsculas: por RFC la parte local distingue mayúsculas pero la mayoría de proveedores la tratan sin distinción. El dominio nunca distingue.
Preguntas frecuentes
›¿Confirma que el email existe?
No — solo sintaxis. Confirmar que existe la bandeja requiere comprobación SMTP en servidor o enviar email de verificación. Esta herramienta detecta erratas barato.
›¿Por qué aceptó 'a@b.co'?
Porque técnicamente es sintaxis válida. El TLD '.co' es real (Colombia). La validación por sintaxis no puede filtrar TLDs reales pero raros.
›¿Y emails con unicode (p.ej. 用户@例え.jp)?
Las direcciones internacionalizadas son válidas según RFC 6531 pero la regex usada aquí no las acepta. La mayoría de backends de formularios tampoco. Para validación con unicode, usa una librería dedicada.
›¿Qué es un tag plus?
Cualquier cosa entre + y @ es tratada por Gmail y muchos proveedores como parte del enrutamiento. user+toolify@gmail.com va a user@gmail.com pero puedes filtrar por el sufijo +toolify.
›¿Por qué Gmail ignora los puntos?
Política histórica de Gmail. user.name@gmail.com y username@gmail.com entregan a la misma bandeja. Otros proveedores (Yahoo, Outlook) los tratan como distintos.
›¿Cuál es el email válido más largo?
254 caracteres totales según RFC 5321. Parte local ≤ 64. La mayoría de servidores rechazan más largos.
›¿Los datos salen del navegador?
No. La validación corre localmente; nada se envía a un servidor.
›¿Puedo validar en bulk?
No en esta herramienta — pega una dirección a la vez. Para listas, usa un script o servicio dedicado de validación masiva (con consentimiento de los titulares).
Herramientas relacionadas
Última actualización: