Usa esta lista de verificación de sintaxis de email compatible con RFC para detectar casos límite como cadenas entre comillas, plus addressing y subdominios antes del lanzamiento.
Usa un parser dedicado cuando puedas. Las regex suelen perder casos límite como local parts entre comillas, etiquetas “+” y dominios con múltiples etiquetas, por lo que o bien rechazan usuarios reales o bien aceptan entradas rotas.
La sintaxis pregunta: “¿Está escrito en un formato válido de email?”. La política pregunta: “¿Queremos permitirlo en nuestro producto?”. Sepáralas para no bloquear direcciones válidas por intentar reducir registros de riesgo.
No. “Compatible con RFC” significa principalmente que la cadena puede ser analizada como una dirección de email. No demuestra que el dominio exista, que tenga registros MX o que el buzón pueda recibir correo.
Recorta espacios al inicio y al final primero, luego rechaza caracteres de control como tabulaciones y saltos de línea. No “normalices” eliminando caracteres internos, porque eso puede cambiar la dirección que el usuario escribió realmente.
Permítelo por defecto. [email protected] es un formato normal y ampliamente usado; bloquearlo suele crear fricción innecesaria en el registro sin mejorar la seguridad por sí mismo.
Sí. Los subdominios son comunes, y los dominios pueden tener múltiples puntos como sub.example.co.uk. Un validador que asume “solo un punto” en el dominio rechazará muchas direcciones reales.
Aplica “exactamente un @”, con al menos un carácter a cada lado. No dividas por el primer @ e ignores el resto, y no aceptes entradas que contengan varios @ tal cual.
Decídelo intencionadamente. Son válidos según la normativa, pero son raros y pueden romper sistemas posteriores que asumen un formato más simple. Si los rechazas, trátalo como una decisión de política y muestra un mensaje claro.
Ayudan a evitar entradas abusivas o peligrosas y reducen casos límite extraños. Límites prácticos comunes: 254 caracteres en total, 64 para la parte local, 253 para el dominio y 63 por etiqueta de dominio.
Usa códigos de razón que mapeen fallos específicos, como CONTROL_CHAR, PARSE_FAIL, LENGTH o DOMAIN_LABEL. Esto hace que los tickets de soporte y la depuración sean mucho más sencillos que un genérico “email inválido”.
Las direcciones de correo parecen sencillas hasta que intentas validarlas. Muchos errores en producción vienen de tratar un email como “unas letras, una @ y un punto”, y luego confiar en una regex rápida. Las direcciones reales permiten más variación de la que esperan la mayoría de los formularios, y pequeñas decisiones de parseo pueden convertir una dirección válida en un error de “inválida”.
Una confusión común es mezclar dos preguntas diferentes:
Si quieres reducir registros de riesgo, quizá bloquees ciertos patrones. Si tu objetivo es evitar rechazar usuarios reales, primero debes acertar con la sintaxis y luego aplicar tu política encima. Mantener esas capas separadas es la diferencia entre un validador en el que puedes confiar y uno que silenciosamente te hace perder registros.
Rechazar emails válidos rompe cosas reales. Alguien introduce una dirección perfectamente válida con plus addressing o un subdominio, tu formulario dice “inválido” y se van. Pierdes el registro y ni siquiera recoges datos suficientes para depurar lo ocurrido.
Aceptar emails malos rompe otras cosas. Las direcciones inválidas aumentan los rebotes, lo que puede dañar tu reputación de envío y la entregabilidad. También atraen registros de baja calidad y fraude cuando atacantes llenan formularios con basura.
La mayoría de fallos en producción se reducen a unos pocos patrones: regex demasiado estrictas (o demasiado laxas), división incorrecta alrededor de @, recortes o “normalización” demasiado agresivos, y mezclar comprobaciones de sintaxis con comprobaciones de entregabilidad.
Ejemplo: alguien se registra con [email protected]. Un validador simplista lo rechaza porque espera solo un punto en el dominio. La dirección puede ser completamente válida, pero el usuario nunca llega a la confirmación.
Este artículo se centra en la sintaxis: si una dirección está escrita en un formato válido. No demuestra que el buzón exista ni que el dominio pueda recibir correo. Esas comprobaciones pertenecen a capas posteriores.
“Compatible con RFC” trata sobre todo de sintaxis: ¿se puede parsear esta cadena como una dirección de correo según las reglas de RFC 5322? Eso es útil, pero solo es la primera puerta. Una dirección sintácticamente válida puede seguir siendo no entregable, insegura o de baja calidad.
Piensa en la validación por capas:
Una canalización práctica sería: parsear la sintaxis, verificar lo básico del dominio y luego aplicar tu política (bloquear dominios desechables conocidos, trampas de spam y otras señales de riesgo). La sintaxis por sí sola nunca debe pretender garantizar entregabilidad.
Para formularios de registro, “compatible con RFC” suele significar aceptar formatos reales comunes (etiquetas +, subdominios, TLDs más largos) y evitar rechazar direcciones válidas solo porque parezcan poco familiares.
Algunos equipos deliberadamente endurecen las reglas. Eso puede ser razonable, pero debe ser una elección de política deliberada, documentada y probada. Por ejemplo, aún podrías rechazar:
@ o ausencia de parte local o dominioEscenario: [email protected] puede ser válido sintácticamente. Si el dominio no tiene registros MX, lo detectarías en la capa de dominio. Si es un proveedor desechable conocido, eso es política.
La mayoría de bugs en validación ocurren porque el validador adivina. Antes de coger una regex, deja clara la estructura: una parte local, un único @ y una parte de dominio.
@. Es donde viven los casos complejos: etiquetas +, puntos y a veces cadenas entre comillas.@. Sigue las reglas de etiquetas de dominio y puede ser internacionalizada.Mantener esas piezas separadas hace la lógica más fácil de razonar y mucho más sencilla de probar.
Las direcciones reales pueden incluir caracteres no ASCII en la parte local (EAI) y dominios no ASCII (IDN). Decide de antemano lo que soportas.
Si aceptas solo ASCII, rechaza lo no ASCII temprano con un mensaje claro. Si aceptas IDNs, normalmente validarás el dominio en su forma compatible con ASCII (punycode) internamente.
Los límites de longitud ayudan a evitar casos límite y protegen tus formularios del abuso. Límites usados comúnmente en la práctica:
Haz una limpieza básica antes de parsear: recorta espacios al inicio y al final, y rechaza direcciones con espacios internos a menos que soporte explícitamente partes locales entre comillas. No conviertas la parte local a minúsculas (puede ser sensible a mayúsculas), pero convertir el dominio a minúsculas suele ser seguro.
Plus addressing es cuando alguien añade una etiqueta después de un signo +, como [email protected]. La gente lo usa para filtrar correo y rastrear registros, así que rechazarlo añade fricción sin beneficio.
Trata + como un carácter normal en la parte local (fuera de cadenas entre comillas). Aunque algunos proveedores ignoran la etiqueta para la entrega, sigue siendo parte de la dirección tal y como fue escrita.
Muchos equipos aceptan un “subconjunto seguro” en la parte local (letras, dígitos y algunos separadores como ., _, -, +). Eso cubre la mayoría de direcciones reales y simplifica la implementación.
Las reglas RFC permiten más puntuación, pero ampliar el conjunto aceptado solo ayuda si puedes hacerlo correctamente y mantener pruebas sólidas.
En la forma no entrecomillada común, los puntos están permitidos en la parte local, pero no en cualquier lugar:
[email protected] es inválido[email protected] es inválidoNo incorpores comportamientos específicos de proveedores en la sintaxis. Algunos proveedores tratan firstlast y first.last como el mismo buzón, pero eso no es una regla de sintaxis.
Algunos casos rápidos que vale la pena probar:
[email protected] (etiqueta +)[email protected] (punto)[email protected] (punto inicial)[email protected] (doble punto)[email protected] (etiqueta + con subdominio)Las cadenas entre comillas existen porque las reglas de email tuvieron que cubrir sistemas más antiguos y nombres de buzones inusuales. Aparecen en la parte local cuando la dirección necesita caracteres que de otro modo serían ilegales o ambiguos.
Una parte local entre comillas está envuelta en comillas dobles, como "john smith"@example.com. Dentro de las comillas se permiten espacios. Si necesitas una comilla doble literal o una barra invertida dentro de las comillas, debe escaparse con una barra invertida.
Lo confuso es que las reglas cambian dentro de las comillas. Dos puntos seguidos son normalmente inválidos en una parte local sin comillas, pero están permitidos dentro de una cadena entre comillas. Eso significa que "a..b"@example.com puede ser válido aunque [email protected] deba rechazarse.
Para los registros, tienes una elección real:
Cualquiera de las dos es defendible. Lo que causa errores es rechazarlas accidentalmente con una regex de la que dependías sin querer.
Casos de prueba que son sintácticamente válidos:
"john smith"@example.com"a..b"@example.com"john\\\"smith"@example.com"back\\\\slash"@example.com"weird()[],:;\u003c\u003e@\"@example.comLas cadenas entre comillas solo afectan la parte local. Aún necesitas validar el dominio por separado.
Muchos validadores fallan en el dominio. Los subdominios son normales y comunes. [email protected] no debe sorprender a tu parser.
Un enfoque simple es validar el dominio como etiquetas separadas por puntos y luego aplicar unas pocas reglas sencillas.
Para la mayoría de registros de consumidores, estas reglas funcionan bien:
Requerir “al menos un punto” suele ser un buen filtro de errores tipográficos para direcciones públicas, pero puede ser una decisión de política si soportas dominios internos.
La colocación de puntos es donde se esconden los errores. Estos deben fallar rotundamente:
[email protected][email protected], [email protected].[email protected][email protected], [email protected]a@sub_domain.exampleLa mayoría de errores de “email inválido” provienen de validadores que hacen suposiciones en lugar de seguir reglas coherentes.
El espacio en blanco es un gran ejemplo. Copiar/pegar puede añadir espacios iniciales, finales, tabs, espacios sin separación o un salto de línea oculto. Si validas antes de recortar, rechazas una dirección válida. Si “normalizas” demasiado (por ejemplo quitando todos los espacios en cualquier sitio), puedes cambiar el significado de una dirección.
Otro escollo es partir alrededor de @ de forma ingenua. Quieres una regla clara: exactamente un separador @, con al menos un carácter en cada lado. No aceptes basura dividiendo en el primer @ y ignorando el resto, y no causes crasheos ni errores confusos dividiendo en cada @.
Algunas librerías también soportan parcialmente características RFC como comentarios (por ejemplo john.smith(comment)@example.com). El soporte parcial puede ser peor que el rechazo consistente porque crea desajustes entre frontend y backend.
Señales de alarma a vigilar:
@ sin imponer “exactamente uno”Los parecidos Unicode son complicados. Incluso si soportas direcciones internacionalizadas, ayuda registrar casos sospechosos y mostrar un error claro cuando algo parezca raro.
Un validador fiable no es un patrón ingenioso. Es un pequeño conjunto de reglas aplicadas en el orden correcto.
Recorta espacios al inicio y al final, luego rechaza caracteres de control (tabs, saltos de línea, bytes nulos). Decide cómo tratas espacios Unicode no estándar. Sé explícito sobre si soportas no-ASCII.
Un enfoque solo con regex a menudo rechaza direcciones válidas o acepta rotas. Usa un parser que entienda parte local vs dominio y sepa cómo manejar cadenas entre comillas si decides soportarlas.
Mantén el parseo separado de la política. El parseo responde “¿es sintácticamente válido?”; la política responde “¿lo permitimos en nuestro producto?”.
Tras el parseo, aplica límites duros y comprobaciones básicas de sentido del dominio (límites de longitud, no etiquetas vacías, no guiones al inicio o final, permitir subdominios bien formados). Esto atrapa entradas que pueden parsearse técnicamente pero causarán problemas más adelante.
Decide intencionadamente sobre casos límite como partes locales entre comillas. Si las bloqueas, dilo y muestra un mensaje claro. Si las permites, añade pruebas para caracteres escapados y espacios.
Lo más importante es mantener las mismas reglas en web, móvil y backend para que los usuarios no vean errores inconsistentes.
Cuando soporte pregunte por qué se rechazó un email, “inválido” no ayuda. Registra un conjunto pequeño de códigos de motivo (por ejemplo: CONTROL_CHAR, PARSE_FAIL, LENGTH, DOMAIN_LABEL). Esto facilita diagnosticar picos y ayuda a encontrar problemas como un teclado iOS que inserta un salto de línea oculto.
Un validador solo es tan bueno como las pruebas que aseguran su comportamiento. Mantén un conjunto pequeño de “debe pasar” basado en registros reales, un conjunto de “debe fallar” para rechazos universales y un conjunto de casos límite para trampas del parser.
Ejemplos que deben pasar:
Ejemplos que deben fallar:
plainaddress (falta @)alex@ (falta dominio)@example.com (falta parte local)[email protected] (doble punto en la parte local)Si decides soportar cadenas entre comillas, añade pruebas explícitas como "john..doe"@example.com y "john\\\"doe"@example.com. Si decides no soportarlas, ten las pruebas igualmente, pero márcalas como rechazos por política para que la decisión quede visible.
No te quedes solo en pasar/fallar. Almacena códigos de razón esperados para que las fallas sean accionables.
{ \"input\": \"[email protected]\", \"expected\": \"fail\", \"reason\": \"LOCALPART_DOT_SEQUENCE\" }
Ejecuta la misma suite donde sea que valides: web, móvil, backend y cualquier flujo de autenticación de terceros. Ahí es donde suelen aparecer los desajustes.
Si quieres menos errores en registros y menos tickets de “por qué no funciona este email?”, mantén tus reglas de sintaxis cortas y consistentes. Un umbral práctico se ve así:
@, con al menos un carácter a cada ladoToma una decisión única y documentada pronto: si aceptas partes locales entre comillas como "john smith"@example.com. Son válidas según RFC 5322, pero raras en registros y a menudo mal manejadas por sistemas posteriores.
Después de la sintaxis, añade las comprobaciones que la sintaxis no cubre: verifica que el dominio exista, revisa registros MX y filtra proveedores desechables y trampas de spam conocidas. Si prefieres no mantener esas capas tú mismo, Verimail (verimail.co) es una API de validación de emails que ejecuta comprobaciones de sintaxis junto a verificación de dominio, búsqueda MX y coincidencia con listas de desechables y bloqueos, para que puedas mantener tu lógica de registro consistente sin convertir todo en una sola regex.