Patron regex para validación de correo con casos de prueba. Cubre cumplimiento RFC 5322, errores comunes y por qué el regex solo no es suficiente.
alice.chen@company.co.ukíndice 17bob+tag@gmail.comíndice 42test@sub.domain.example.orgíndice 113El patrón de arriba coincide con la gran mayoría de las direcciones de correo del mundo real. Requiere una parte local no vacia usando caracteres alfanumericos y ._%+-, seguida de @, un dominio que contiene al menos un punto, y un TLD de dos o más letras. Coincide con: user@example.com, alice.chen@company.co.uk, bob+tag@gmail.com. NO coincide con: invalid@, @missing-local.com, no-at-sign.com, user@.com.
| Parte | Patron | Que coincide |
|---|---|---|
| Ancla de inicio | ^ |
Inicio de cada línea (con bandera m) |
| Parte local | [a-zA-Z0-9._%+\-]+ |
Letras, digitos y ._%+-, uno o más |
| Arroba | @ |
@ literal |
| Etiquetas de dominio | [a-zA-Z0-9.\-]+ |
Nombre de dominio permitiendo puntos y guiones |
| Punto antes de TLD | \. |
Punto literal |
| TLD | [a-zA-Z]{2,} |
Dos o más letras |
| Ancla de fin | $ |
Fin de cada línea (con bandera m) |
No permitir el signo + en la parte local es el problema más frecuente. Gmail y muchos otros proveedores dirigen user+tag@gmail.com a la misma bandeja de entrada que user@gmail.com.
No permitir TLD de multiples niveles es el segundo error más comun. Un patrón que termina con \.[a-zA-Z]{2,3} rechaza alice@company.co.uk porque trata .co como el TLD.
No anclar el patrón con ^ y $ significa que una cadena como esto no es un correo pero contiene uno@example.com coincide con la parte incrustada.
Los navegadores aplican su propio patrón a <input type="email">.
Un regex puede confirmar que una dirección se parece a un correo. Pero no puede decirte si el dominio tiene registros MX funcionales, si el buzon existe o si el usuario controla la dirección. El enfoque estándar para cualquier flujo que requiera una dirección de correo real:
Nothing you paste leaves this tab. Every tool runs entirely in your browser — no upload, no server, no account.