20 dic 2025·6 min
Lista de verificación de validación de sintaxis de correo compatible con RFC para registros
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.
Por qué la validación de sintaxis de email provoca tantos errores
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:
- Lo que permiten los estándares (reglas de sintaxis)
- Lo que tu producto quiere aceptar (tu política)
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.
Qué significa “compatible con RFC” (y qué no significa)
“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.
Sintaxis vs comprobaciones de dominio vs existencia del buzón
Piensa en la validación por capas:
- Sintaxis: ¿Está la dirección formateada correctamente (caracteres, separadores, reglas de comillas)?
- Dominio: ¿Puede el dominio recibir email (DNS, registros MX)?
- Existencia del buzón: ¿Existe ese buzón exacto? Esta es la capa más difícil, porque muchos servidores de correo no la confirman.
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.
Qué significa “compatible con RFC” en la práctica
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:
- Falta de
@o ausencia de parte local o dominio - Caracteres de control, espacios invisibles o saltos de línea pegados
- Etiquetas de dominio que empiecen o terminen con un guion
- Unicode que no soportes de extremo a extremo
- Entradas extremadamente largas (fija un máximo para prevenir abusos)
Escenario: [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.
Conoce las partes de una dirección de email antes de validar
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.
- La parte local es todo lo anterior a
@. Es donde viven los casos complejos: etiquetas +, puntos y a veces cadenas entre comillas. - La parte de dominio es todo lo posterior a
@. 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.
ASCII vs direcciones internacionalizadas (a alto nivel)
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.
Límites de longitud a imponer
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:
- Longitud total: 254 caracteres
- Parte local: 64 caracteres
- Parte de dominio: 253 caracteres
- Cada etiqueta de dominio: 63 caracteres
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 y puntos: casos comunes para soportar
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.
Caracteres de la parte local: subconjunto seguro vs conjunto completo
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.
Puntos: qué permite la sintaxis (y qué hacen los proveedores)
En la forma no entrecomillada común, los puntos están permitidos en la parte local, pero no en cualquier lugar:
- No punto inicial:
[email protected]es inválido - No punto final
- No puntos consecutivos:
[email protected]es inválido
No 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)
Cadenas entre comillas: el caso límite que la mayoría de parsers falla
Mantén alta la calidad de tu lista
Añade validación de email de nivel empresarial que ayuda a proteger la reputación del remitente y el ROI de marketing.
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:
- Soportar completamente las cadenas entre comillas (y probarlas a fondo), o
- Rechazarlas a propósito porque son raras y pueden romper sistemas posteriores
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.com
Las cadenas entre comillas solo afectan la parte local. Aún necesitas validar el dominio por separado.
Dominios y subdominios: qué permitir y qué bloquear
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.
Qué permitir (y por qué)
Para la mayoría de registros de consumidores, estas reglas funcionan bien:
- Varias etiquetas (subdominios) están bien.
- Las etiquetas pueden contener letras y dígitos, y pueden incluir guiones en el interior (no en los extremos).
- Las etiquetas tienen entre 1 y 63 caracteres, y el dominio completo no es absurdamente largo (muchos sistemas limitan a 253).
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.
Qué bloquear (fallos que “parecen válidos”)
La colocación de puntos es donde se esconden los errores. Estos deben fallar rotundamente:
- Puntos consecutivos:
[email protected] - Punto inicial o final:
[email protected],[email protected]. - Etiquetas vacías por divisiones incorrectas:
[email protected] - Etiqueta que empieza o termina con guion:
[email protected],[email protected] - Caracteres inválidos en una etiqueta (guiones bajos son un error común):
a@sub_domain.example
Errores comunes de parseo que crean falsos rechazos
Pruébalo con tráfico real
Valida hasta 100 emails al mes en el plan gratuito, sin tarjeta de crédito.
La 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:
- Recortar solo espacios ASCII, pero no tabs, espacios sin separación o saltos de línea finales
- Partir por
@sin imponer “exactamente uno” - Aceptar con una regex permisiva y luego fallar después con un error vago
- Resultados diferentes entre entornos (web vs móvil vs backend)
- Ignorar parecidos de Unicode (por ejemplo una “а” cirílica que parece una “a” latina)
Los parecidos Unicode son complicados. Incluso si soportas direcciones internacionalizadas, ayuda registrar casos sospechosos y mostrar un error claro cuando algo parezca raro.
Paso a paso: construye un validador de sintaxis en el que puedas confiar
Un validador fiable no es un patrón ingenioso. Es un pequeño conjunto de reglas aplicadas en el orden correcto.
1) Limpia la entrada
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.
2) Parsear con un parser con conocimiento RFC (no solo regex)
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?”.
3) Aplica límites y reglas de etiquetas de dominio
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.
4) Elige tu política de estricta y escríbela
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.
5) Registra fallos con códigos de motivo
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.
Casos de prueba para incluir en tu suite de validación
Aplica las capas de verificación correctamente
Combina sintaxis, verificación de dominio, comprobación MX y listas negras en un solo lugar.
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:
- `` (cadena vacía)
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.
Lista rápida de comprobación y siguientes pasos
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í:
- Exactamente un
@, con al menos un carácter a cada lado - No espacios ni caracteres de control (a menos que soportes explícitamente partes locales entre comillas)
- Longitud dentro de límites comunes (parte local hasta 64, dirección completa hasta 254)
- Dominio bien formado (no puntos consecutivos, no etiquetas vacías, no guion al inicio o final de una etiqueta)
- Las etiquetas + y los subdominios se permiten por defecto
Toma 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.
Preguntas frecuentes
¿Por qué es tan propenso a errores validar emails con una regex?
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.
¿Cuál es la diferencia entre validación de sintaxis y política de aceptación?
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.
¿Significa “compatible con RFC” que un email es entregable?
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.
¿Qué limpieza de entrada debo hacer antes de validar un email?
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.
¿Mi formulario de registro debería permitir plus addressing (como [email protected])?
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.
¿Son válidos subdominios como [email protected]?
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.
¿Cómo debo manejar múltiples signos @ en un input de email?
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.
¿Necesito soportar local parts entre comillas como "john smith"@example.com?
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.
¿Qué límites de longitud debería aplicar para las direcciones de email?
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.
¿Cómo puedo registrar fallos de validación para que sean realmente útiles?
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”.