Gestiona direcciones con + en registros sin bloquear usuarios reales. Aprende normalización segura para dedupe, reglas de almacenamiento y controles de validación.
Sí. Muchos usuarios reales dependen de la plus addressing como [email protected], y muchos proveedores entregan esos correos al mismo buzón que [email protected]. Trátalo como una elección de formato normal, no como una señal de alarma.
La gente usa etiquetas para filtrar correos en carpetas, rastrear dónde se usó una dirección y separar distintos registros. Bloquear + suele rechazar clientes cuidadosos y legítimos.
La opción más segura es almacenar y mostrar el correo exactamente como lo escribió el usuario, y enviar a esa cadena exacta. Cambiarla puede romper filtros de bandeja, confundir a los usuarios y generar problemas de soporte más adelante.
No deduplices quitando +tag del campo principal de correo. Si necesitas deduplicar, crea una “clave de comparación” interna separada y deja la dirección original intacta para envío y visualización.
Usa como identificador principal exactamente el correo que se usó al registrarse. Si alguien introduce una variación diferente que solo coincide mediante una clave normalizada, pídeles que verifiquen la posesión en lugar de iniciar sesión silenciosamente.
Normaliza con cautela: recorta espacios al inicio y final, rechaza caracteres de control y pasa a minúsculas el dominio. Aplica reglas sobre la parte local (por ejemplo, quitar +tag) solo para dominios que tengas en una lista blanca y entiendas, y usa esa lógica solo en una clave de dedupe separada.
Un patrón de verificación demasiado estricto que solo permita letras, números y puntos antes de @ es una causa común. Usa validación compatible con RFC y evita expresiones regulares caseras que traten + como inválido.
No. El soporte depende de la configuración del dominio receptor, no solo de la marca del proveedor. Asume que puede funcionar, valida señales de entregabilidad y evita reglas rígidas del tipo “+ siempre funciona” o “+ nunca funciona”.
Un +tag suele indicar un buzón normal, pero puede usarse para crear muchas direcciones “aparentemente únicas” para el mismo buzón. Gestiona ese riesgo con reglas de producto y controles de comportamiento (verificación, límites de tasa, puntuación de riesgo), no prohibiendo +.
Valida alcance y riesgo: sintaxis, comprobaciones de dominio, registros MX y detección de proveedores desechables, a la vez que aceptas direcciones etiquetadas legítimas. Mantén los resultados de la validación (estado, motivo, marca temporal) separados de la cadena de correo almacenada para no reescribir lo que ingresó el usuario.
Mucha gente usa correos como [email protected]. La parte +tag es una etiqueta (también llamada subdirección). Muchos proveedores entregan ese correo al mismo buzón que [email protected], pero la etiqueta permite al usuario marcar dónde se usó la dirección.
Las personas usan etiquetas por razones prácticas: filtrado (reglas que mueven mensajes a carpetas), seguimiento (identificar qué sitio filtró o vendió una dirección) y separar registros (para que cada cuenta parezca distinta). Es especialmente común entre usuarios de Gmail y Fastmail.
Los problemas aparecen cuando un formulario de registro trata + como inválido o sospechoso. Eso bloquea clientes legítimos y cuidadosos. Otro error común es eliminar la etiqueta y almacenar solo la dirección base. Eso puede colapsar varios registros en una sola cuenta y provocar problemas confusos de inicio de sesión y recuperación más adelante.
Modos de fallo comunes:
+ aunque puedan recibir mensajes.name+billing@... y name+personal@... en un solo usuario.Trata la plus addressing como una opción de formato, no como prueba de fraude. Acepta direcciones que puedan recibir correo y deduplica solo cuando sea realmente seguro. La regla más simple que evita la mayoría de los problemas: conserva el correo original exactamente como lo ingresó el usuario y, si necesitas uno, crea una clave separada usada solo para comparar.
Si ejecutas validación de correo (por ejemplo, con un proveedor como Verimail), la validación debe centrarse en entregabilidad y señales de riesgo, no en castigar +tags que muchos usuarios legítimos usan.
La plus addressing es una forma de añadir una etiqueta a un correo sin crear un nuevo buzón. El patrón habitual es [email protected], donde la parte después de + ayuda al usuario a etiquetar dónde se usó la dirección.
Una dirección de correo tiene dos partes principales: la parte local y el dominio. En [email protected], name+tag es la parte local y example.com es el dominio.
Tres ideas que a menudo se confunden:
+.sales@ y hello@), gestionadas por el proveedor o el propietario del dominio.Qué cuenta como “el mismo buzón” depende del proveedor receptor y de la configuración del dominio. Técnicamente, [email protected] y [email protected] son cadenas distintas. Algunos proveedores entregan ambos al mismo buzón, pero no todos lo hacen, y el comportamiento puede variar según el dominio.
Por eso la opción más segura por defecto es tratar la dirección completa que escribió el usuario como significativa. Si alguien se registra con [email protected], puede esperar que futuros mensajes sigan llegando a la carpeta filtrada que configuró.
Ejemplo: un cliente usa [email protected] para boletines y [email protected] para facturas. Si tu app elimina +news y +billing, puedes fusionar dos intenciones distintas en una sola cuenta y generar confusión (y tickets de soporte) después.
La plus addressing es común, pero no universal. Muchos buzones principales aceptan direcciones como [email protected] y las entregan al mismo buzón que [email protected]. Otros tratan la parte + de forma distinta o no la soportan.
Un detalle importa más que la marca: la regla la define el dominio receptor. Incluso dentro de una misma empresa, dominios distintos pueden tener ajustes de enrutamiento distintos. Hardcodear “+ siempre funciona” o “+ nunca funciona” acabará bloqueando a usuarios reales.
Algunos dominios soportan +tags solo para ciertos buzones. Otros permiten separadores distintos. Algunos sistemas de reenvío pasan por elementos que quitan o reescriben partes de la dirección local. Trata el subaddressing como una característica “posible” a menos que puedas verificarla.
Qué no asumir en todos los dominios:
jane.doe vs janedoe) a menos que sepas que el dominio se comporta así.+tag para decisiones de entrega (enviar correo al usuario).Un valor predeterminado seguro es sencillo: acepta el correo que escribió el usuario, valídalo y mantenlo exactamente como fue ingresado para el envío. Si necesitas deduplicar, guarda un segundo valor “normalizado para dedupe” por separado.
Si alguien se registra como [email protected] porque quiere filtrar los correos de incorporación, rechazarlo te hace perder un cliente real. Sobrescribirlo con [email protected] puede ser igual de malo, porque ya no estarás enviando a la dirección que esperan.
Un enfoque práctico es aceptar la dirección, luego validar sintaxis y configuración del dominio (incluyendo registros MX) y finalmente aplicar comprobaciones de desechables y riesgo. Una API de validación de correo como Verimail puede confirmar que la dirección está bien formada y que el dominio está configurado para recibir correo, mientras mantienes la dirección original intacta para envío.
Almacena lo que el usuario escribió y envía a esa misma dirección. La gente usa etiquetas por razones reales (filtrar recibos, separar registros de trabajo y personales), y reescribir la dirección puede romper la entrega o complicar el soporte cuando el usuario dice: “Me registré con [email protected].”
Al mismo tiempo, muchos productos quieren un segundo valor que ayude a detectar duplicados y mantener las cuentas ordenadas. Ahí es donde pertenece la normalización: en una clave interna separada, no en el correo al que envías.
Un modelo de datos práctico mantiene dos campos con trabajos distintos:
Mantén la información de verificación separada de ambos. La validación no es parte de la dirección en sí, es una propiedad de la dirección en un punto en el tiempo. Almacena cosas como estado (válido, riesgoso, inválido), un motivo (por ejemplo, dominio sin MX) y una marca temporal.
La normalización debe ser conservadora. Pasar a minúsculas el dominio suele ser seguro. Pasar a minúsculas la parte local suele ser seguro en la práctica, pero sé consistente y evita sorpresas. Lo más importante: no elimines la +tag a menos que sea solo para una clave interna y solo cuando estés seguro de que no fusionará a personas distintas.
Ejemplo concreto: almacena [email protected] como el correo original, pero guarda una clave como [email protected] para coincidencias solo si esa transformación es segura para ese dominio. Los mensajes seguirán llegando donde el usuario lo espera, mientras tu sistema puede detectar duplicados potenciales sin reescribir la dirección de entrega.
Acepta direcciones reales (incluyendo plus addressing) mientras sigues detectando duplicados creando una clave de dedupe separada, no reescribiendo lo que el usuario tipeó.
Un enfoque práctico:
Recortar y sanear la entrada. Quita espacios al inicio y al final. Rechaza caracteres de control (tabs, saltos de línea, nulos) que puedan ocultar otra dirección o romper registros y correos.
Ejecutar cheques básicos de sintaxis, pero no prohíbas +. Una parte local válida puede incluir + y otros caracteres. Enfócate en problemas evidentes como falta de @, partes vacías o espacios ilegales.
Normalizar el dominio con cuidado. Pasa el dominio a minúsculas y normalízalo de forma consistente. Si soportas dominios internacionalizados, conviértelos usando un proceso estándar para que exämple.com y su forma ASCII mapeen al mismo dominio.
Aplica reglas sobre la parte local solo cuando controles el riesgo. No quites +tag globalmente. Si quieres deduplicar [email protected] con [email protected], hazlo solo para dominios que permitas explícitamente y puedas verificar que se comportan así.
Crea una clave de dedupe estable y deja el original intacto. Almacena ambos valores: el original para envío y visualización, y la clave normalizada para coincidencias.
Ejemplo: si alguien se registra como [email protected], guarda [email protected] como correo de contacto. Construye una clave de dedupe como [email protected] solo si example.com está en una lista blanca para quitar +tags. Si no, mantén la clave más cercana al original, por ejemplo [email protected].
Si usas una API de validación como Verimail, valida primero y luego normaliza. Ese orden te ayuda a evitar “arreglar” una dirección mala y convertirla en algo que parezca válido pero que no vaya a entregar.
Trata el correo que una persona escribe como su etiqueta de identidad, no como algo que puedas reescribir libremente. Con plus addressing, dos cadenas pueden enrutar al mismo buzón, pero no siempre son la misma “cuenta” desde la perspectiva del usuario.
Al registrarse, acepta +tags y muestra la dirección exactamente como la ingresaron (incluida la parte +). Eso tranquiliza a la gente de que no “arreglaste” su correo.
Para el inicio de sesión, una regla simple evita sorpresas: permite que los usuarios inicien sesión con exactamente el correo que usaron al crear la cuenta. Si alguien intenta una variación distinta (como quitar la etiqueta) y solo encuentras una coincidencia vía una clave normalizada, no inicies sesión silenciosamente. Pídeles que confirmen la posesión, por ejemplo iniciando sesión de la forma habitual o completando un paso de verificación por correo.
La fusión debe requerir prueba, no solo “estas normalizan a la misma cadena.” Opciones habituales y seguras:
Ejemplo: Alex se registra como [email protected] para una prueba de un boletín. Meses después, un compañero escribe [email protected] en un dispositivo compartido. Fusionar automáticamente solo por normalización puede dar acceso a la persona equivocada.
Decide desde el principio si +tags cuentan como identidades únicas. Algunos equipos tratan cada dirección invitada como distinta para seguimiento, pero previenen múltiples cuentas a menos que la invitación se reclame mediante un correo confirmado.
Si validas correos durante el registro, mantiene la frontera clara: la validación ayuda con la entregabilidad y el riesgo, mientras las decisiones de identidad (inicio de sesión, fusión, invitaciones) deberían seguir reglas de producto explícitas.
La forma más rápida de perder buenos registros es tratar una dirección válida como “rara”. La plus addressing es normal para personas que filtran correo, rastrean dónde compartieron una dirección o mantienen registros separados.
Un bug común es un regex que solo permite letras, números, puntos y guiones antes de @. Eso bloquea [email protected] aunque sea válido para muchos proveedores. Si tus reglas de validación fueron escritas hace años, este suele ser el culpable.
Otro error es quitar la +tag y usar la versión modificada para envío. Si el usuario escribió [email protected], debes almacenar y enviar exactamente lo que ingresó. Quitar la etiqueta también puede romper reglas de bandeja que dependen de ella.
El manejo de puntos es especialmente arriesgado. Algunos servicios ignoran puntos en la parte local (sam.smith@... vs samsmith@...), pero muchos no. Asumir insensibilidad a puntos en todos lados puede fusionar buzones distintos.
Un tema más sutil es la inconsistencia de reglas entre sistemas. Si tu flujo de registro acepta [email protected], pero tu herramienta de facturación quita la etiqueta mientras la de marketing la conserva, la misma persona puede aparecer como múltiples contactos o fusionarse incorrectamente.
Comprobaciones rápidas de “no hagas esto”:
+ en la parte local.La normalización no es verificación. Usa la normalización solo para dedupe cuidadoso. Utiliza un validador real (por ejemplo, Verimail) para atrapar errores tipográficos, dominios inválidos y direcciones desechables sin bloquear a usuarios legítimos con +tag.
Un +tag suele ser signo de un usuario cuidadoso, no de un atacante. La gente usa etiquetas para filtrar correo o para ver qué sitio filtró su dirección.
Los atacantes aún pueden abusar de alias para crear muchas cuentas, porque algunos proveedores tratan [email protected] como el mismo buzón. Eso puede eludir reglas de “una cuenta por correo” si tu sistema considera cada +tag como identidad nueva.
La solución no es prohibir +tags. Eso bloquea usuarios reales y no evita el abuso en proveedores que soportan otros estilos de alias (puntos, alias de dominio, catch-alls). Decide qué estás protegiendo: creación de cuentas en volumen, promociones o identidad.
Centra la fricción en el comportamiento, no en el formato. Por ejemplo: limita la tasa de registros sospechosos, exige verificación por correo para registros de mayor riesgo y vigila muchos registros que mapean al mismo buzón en poco tiempo.
Si necesitas separar “identidad” de “método de contacto”, no hagas del correo tu única clave. Trata la cuenta como su propio registro y el correo como puntos de contacto que pueden añadirse, verificarse y eliminarse. Eso facilita soportar buzones compartidos, direcciones de rol y cambios legítimos de correo.
Detectar correos desechables importa más que prohibir +tags. Un buzón desechable está pensado para registros desechables; un +tag suele ser un buzón normal. Herramientas como Verimail pueden ayudar identificando proveedores desechables conocidos, trampas de spam y direcciones inválidas mientras siguen aceptando direcciones etiquetadas legítimas.
La mayoría de los problemas reales con la plus addressing son autoinfligidos: un regex demasiado estricto o una regla de dedupe que fusiona silenciosamente cuentas que deberían permanecer separadas.
Empieza por aceptar. Tu validador debe permitir + en la parte local (antes de @). Evita atajos de regex que asuman solo letras, números, puntos y guiones bajos. Si usas una librería, confirma que sigue las reglas RFC en lugar de un patrón casero.
Luego, separa la entrega de la deduplicación. Siempre almacena el correo original exactamente como lo escribió el usuario para visualización y envío. Si creas una clave normalizada para dedupe, mantenla separada y documenta las reglas para que soporte e ingeniería tomen las mismas decisiones.
Una lista de comprobación previa al lanzamiento:
+ en la parte local.Para señales de alcance y disponibilidad de buzón, valida antes de forzar pasos como “verifica tu correo para continuar.” Un validador puede ayudarte a evitar bloquear usuarios reales por errores tipográficos o dominios muertos.
Finalmente, ejecuta un conjunto de pruebas simple: [email protected], [email protected] y [email protected]. Confirma que pueden registrarse, iniciar sesión, restablecer contraseña y recibir mensajes sin sorpresas.
Un caso común: una app B2B ofrece pruebas gratuitas. Un administrador en Acme prueba el producto para distintos clientes y usa etiquetas como [email protected], [email protected] y [email protected] para mantener reglas de bandeja ordenadas. Eso es un comportamiento normal de plus addressing y los mensajes siguen entregándose al mismo buzón.
El problema empieza cuando la dedupe es demasiado agresiva. Si quitas todo lo que viene después de + y tratas todos esos registros como el mismo usuario, puedes bloquear a la gente. El administrador intenta crear otra prueba, pero tu app piensa que la cuenta ya existe y bloquea el registro. Luego el restablecimiento de contraseña se envía a la primera prueba, no a la que están viendo.
Un enfoque más seguro es separar “identidad de entrega” de “identidad de cuenta.” Almacena el correo original exactamente como fue ingresado. Guarda una forma normalizada solo como ayuda para coincidencias, revisión o analítica. Luego:
[email protected], pero exige confirmación por correo antes de activar la prueba.Para soporte, ayuda mostrar ambos campos en el perfil de usuario y en los registros: “Correo ingresado” y “Normalizado para dedupe.” Eso facilita explicar qué pasó y arreglarlo rápidamente.
Si aceptas +tags pero los manejas de forma distinta en registro, inicio de sesión y herramientas internas, seguirás creando duplicados y confundiendo a los usuarios. La solución más rápida es documentar tus reglas y aplicarlas en todos los lugares donde aparezca el campo de correo.
Una política simple funciona bien para la mayoría de equipos: almacena el correo exactamente como lo escribió el usuario y usa solo un valor normalizado separado para emparejar y reportar. Eso te permite deduplicar sin romper la entrega ni sorprender a alguien que depende de las etiquetas.
Lista de despliegue:
Si quieres una implementación que se centre en señales de alcance y riesgo (sin rechazar +tags legítimos), Verimail (verimail.co) ofrece una API de validación de correo que combina comprobaciones de sintaxis, verificación de dominio y MX, y detección de desechables y listas negras.
Una vez que los cambios estén en producción, mide resultados para detectar regresiones y ajustar reglas. Sigue la tasa de rechazo en registros y sus motivos, la tasa de rebotes en confirmaciones, la tasa de cuentas duplicadas según tu clave normalizada y los tickets de soporte que mencionen cuentas duplicadas o registros fallidos. Mantén una pequeña muestra de direcciones rechazadas (anonimizadas) y revísalas. Si ves muchos dominios reales bloqueados, tus reglas de validación o normalización son demasiado agresivas.