Todo código base tiene una: una expresión regular, copiada de Stack Overflow, que «valida» direcciones de correo. Parece una comprobación, pero responde a una pregunta que casi nadie se está haciendo en realidad. Una regex puede decirte que una cadena tiene forma de dirección de correo. No puede decirte si la dirección existe, si acepta correo o si no provocará un rebote definitivo en tu próxima campaña, y eso es lo único que importa.
La respuesta corta#
Una regex valida la sintaxis, no la entregabilidad. definitely-fake@gmail.com es
una dirección de correo perfectamente válida según cualquier regex jamás escrita, y rebotará
en cuanto le envíes algo. Peor aún: las regex a las que recurre la gente o bien rechazan
direcciones reales (demasiado estrictas) o bien aceptan disparates (demasiado laxas), y la que es
técnicamente correcta tiene miles de caracteres y aun así no puede confirmar un
buzón. Usa una comprobación de sintaxis sencilla para detectar erratas de dedo en el input y luego
verifica la entregabilidad con una comprobación de DNS y SMTP, que es un problema de red, no
de coincidencia de patrones.
La regex que has visto y lo que deja pasar#
Aquí está el arquetipo, alguna variante de esto vive en la mayoría de proyectos:
const re = /^[^@\s]+@[^@\s]+\.[^@\s]+$/;
re.test("definitely-fake@gmail.com"); // true ← will hard-bounce
re.test("typo@gmial.com"); // true ← typo'd domain, bounces
re.test("info@company-that-folded.com"); // true ← dead domain
Las tres pasan. Las tres son no entregables. La regex hizo su trabajo a la perfección y no te dijo nada útil, porque la sintaxis y la entregabilidad son preguntas distintas. Cada dirección que una regex puede ver es una cadena; que haya una persona leyendo el correo detrás es un hecho sobre internet, no sobre la cadena.
El laberinto del RFC 5322#
«Vale», dice el razonamiento, «usaré una regex correcta». La gramática formal de
una dirección de correo está definida por el RFC 5322, y una regex que realmente la implementa
es célebremente monstruosa: miles de
caracteres, y permite cosas que nunca querrías aceptar, como partes locales
entrecomilladas con espacios ("a b"@example.com) y comentarios dentro de la dirección.
De ahí se derivan dos problemas. Primero, la regex estricta acepta más de lo que quieres, no menos: valida contra una especificación de 2008, no contra «direcciones a las que los servidores de correo reales van a entregar». Segundo, ni siquiera una coincidencia impecable con el RFC 5322 puede decirte si el dominio tiene un servidor de correo o si el buzón existe. Has invertido un esfuerzo enorme en responder a la pregunta fácil con más precisión, mientras que la pregunta difícil, ¿llegará el correo?, sigue completamente intacta.
Las tres cosas que una regex fundamentalmente no puede hacer#
Ningún patrón, por ingenioso que sea, puede llegar al otro lado de la red. Una regex no puede:
- Comprobar que el dominio puede recibir correo.
user@company-that-folded.comtiene sintaxis válida sobre un dominio sin registros MX. Solo una consulta DNS revela el dominio muerto. - Confirmar que el buzón existe.
noreply-9f2x@gmail.comtiene sintaxis válida para una cuenta que nunca se creó. Solo una conversación SMTP con Gmail puede decirte que no está ahí. - Detectar un dominio catch-all. Un servidor catch-all acepta todas las direcciones, así que ni siquiera una comprobación SMTP en vivo puede confirmar un buzón concreto, y una regex no tiene ni idea de que el dominio se comporta así.
Estas no son carencias de una regex en particular; están fuera de lo que cualquier regex puede hacer, porque son preguntas sobre servidores, no sobre cadenas.
Qué hacer de verdad: validar por capas#
La entregabilidad es una tubería de comprobaciones cada vez más costosas, y la sintaxis es solo la primera etapa, la barata (el panorama completo está en cómo funciona la verificación de correo):
- Sintaxis — una comprobación sencilla en el input para detectar erratas evidentes. Esta es la única capa a la que pertenece una regex.
- Dominio y MX — una consulta DNS para confirmar que el dominio puede recibir correo siquiera. Consulta las guías de Node.js y Python para ver código funcional.
- Sondeo SMTP del buzón — la conversación de entrega que realmente confirma el buzón, más la detección de catch-all. Esto necesita un servidor de correo con una reputación de IP limpia y una limitación de tasa cuidadosa, por lo que la mayoría de equipos recurren a una API de verificación en lugar de construirlo.
La comprobación de sintaxis que vale la pena conservar#
Para la capa 1, no te fabriques a mano el RFC 5322. La jugada pragmática es el input de correo HTML5 en el navegador (que aplica gratis el patrón del estándar vivo de la WHATWG) y una comprobación corta y permisiva en el servidor:
// Pragmatic: rejects fat-finger errors, accepts the addresses real
// mail servers actually deliver to. Not a deliverability check.
const SYNTAX = /^[^\s@"]+(?:\.[^\s@"]+)*@[^\s@.]+(?:\.[^\s@.]+)+$/;
SYNTAX.test("jane@example.com"); // true
SYNTAX.test("not-an-email"); // false
SYNTAX.test("a@@b.com"); // false
Úsala para dar retroalimentación instantánea mientras se escribe, nada más. Trata un aprobado como «vale la pena comprobarlo en serio», nunca como «válida».
Recorrer el resto del camino#
Una vez que pasa la sintaxis, la verificación de verdad es un trabajo de red. Puedes construir las capas
de DNS y SMTP tú mismo (las guías por lenguaje de arriba muestran hasta dónde puedes llegar),
pero confirmar buzones en vivo a escala tropieza con el puerto 25 bloqueado en la mayoría de
hosts, la reputación de IP y el greylisting, que es
donde una API gestionada se gana su sitio. El endpoint
POST /verify de Qualisend ejecuta toda la tubería y devuelve un veredicto
de cuatro vías (deliverable | risky | undeliverable | unknown) con un código de motivo, de modo que
tu código actúa en función de si el buzón existe y no de si la cadena tiene
una @.
Preguntas frecuentes#
¿Existe una regex correcta para validar correos electrónicos?#
No en el sentido que la gente querría. Existe una regex que implementa el RFC 5322, pero tiene
miles de caracteres, acepta formas exóticas que nunca querrías admitir y aun así
no puede confirmar que la dirección sea entregable. Para uso práctico, un patrón corto y
permisivo (o el input HTML5 type="email") para detectar erratas es la cantidad justa de
regex; lo demás es un problema de DNS y SMTP.
¿Por qué mi regex rechaza direcciones de correo válidas?#
Porque los patrones estrictos codifican suposiciones que no son ciertas: que los dominios de
nivel superior tienen entre 2 y 3 letras (no es así: .email, .io, .marketing), que los signos
más o los puntos no se permiten en la parte local (sí se permiten) o que los nuevos gTLD
no existen. Una regex demasiado estricta es una causa habitual de registros perdidos. Sé
permisivo con la sintaxis y verifica la entregabilidad por separado.
¿La validación de correo de HTML5 comprueba si la dirección es real?#
No. La validación type="email" del navegador es una comprobación de sintaxis: una versión más amable y
estandarizada de la misma coincidencia de patrones. Detecta arrobas @ ausentes
y errores evidentes en el input, pero nunca contacta con el servidor de correo, así que
no puede decirte si el dominio o el buzón existen.
¿Qué debería usar en lugar de regex para validar correos?#
Hazlo por capas: una comprobación de sintaxis permisiva para dar retroalimentación instantánea, una consulta DNS/MX para descartar dominios muertos y un sondeo SMTP del buzón para confirmar la entrega. Las dos primeras puedes construirlas tú mismo; para la capa SMTP usa una API de verificación, ya que hacerlo de forma fiable requiere reputación de IP de envío y limitación de tasa que una regex nunca podría ofrecer.
¿Quieres ver la diferencia entre «sintaxis válida» y «se entregará de verdad»?
El plan gratuito incluye 100 créditos de verificación que ejecutan la tubería
completa (sintaxis, DNS y el sondeo SMTP del buzón), así que puedes ver cómo una
dirección aprobada por regex vuelve como undeliverable. La
referencia de la API tiene ejemplos para copiar y pegar en siete lenguajes.
