Peligros de la normalización de correo: puntos, etiquetas + y reglas de mayúsculas

Por qué la normalización de correos puede romper cuentas de usuario

"Normalizar un correo" significa tomar lo que un usuario escribió y reescribirlo en una forma más consistente antes de almacenarlo o compararlo. Eso puede ser tan simple como recortar espacios, o tan agresivo como eliminar puntos, quitar etiquetas + o aplicar reglas específicas de proveedores.

El riesgo es simple: una pequeña reescritura puede convertir dos direcciones diferentes en el mismo valor almacenado. Cuando eso ocurre, tu sistema puede fusionar identidades por accidente. Los restablecimientos de contraseña pueden llegar a la bandeja equivocada, un usuario puede acabar dentro de la cuenta de otro y tu rastro de auditoría se vuelve difícil de confiar.

Una colisión común se ve así: el Usuario A se registra con [email protected] y el Usuario B con [email protected]. Si tu sistema quita los puntos en la parte local (antes del @), ambos se convierten en la misma cadena, aunque muchos sistemas de correo los traten como buzones diferentes.

Estas colisiones son difíciles de detectar porque rara vez fallan de forma visible:

• Ambos registros parecen válidos.
• El segundo registro puede asociarse a una cuenta existente.
• El problema aparece semanas después, cuando los logs son más difíciles de interpretar.
• Desenredar datos fusionados (facturación, pedidos, permisos) es doloroso.

El objetivo no es adivinar la dirección "real". El objetivo es evitar errores obvios y typos sin cambiar la identidad. Un valor por defecto más seguro es almacenar la dirección original tal como fue escrita, aplicar solo limpiezas conservadoras para comparaciones y manejar las comprobaciones de entregabilidad por separado.

Qué es la normalización (y qué no es)

La normalización trata de hacer las direcciones lo bastante consistentes para almacenarlas y compararlas. La trampa es tratar "consistente" como "la misma persona".

A menudo se mezclan dos trabajos distintos:

• Limpieza de formato: pequeñas correcciones que no cambian a quién pertenece la dirección.
• Reglas de identidad: suposiciones de que dos cadenas distintas deberían mapear a la misma cuenta.

Una dirección de correo tiene dos partes: la parte local (antes del @) y la parte del dominio (después del @). La mayoría de las sorpresas vienen de la parte local, porque los proveedores y los servidores de las empresas pueden interpretarla de forma diferente.

Los equipos suelen intentar cosas como recortar espacios, convertir a minúsculas, quitar puntos y eliminar +tags. El problema clave es que no existe una "forma canónica segura" universal para todos los proveedores. Algunos ignoran los puntos, otros no. Algunos soportan plus addressing, otros tratan el + como un carácter normal. Incluso la sensibilidad a mayúsculas se define de una manera en las normas y se maneja de otra en la práctica.

Un patrón más seguro es: conserva el valor en bruto, crea una clave de comparación separada con solo las transformaciones que puedes defender y nunca permitas que esa clave fusione cuentas en silencio.

Limpiezas seguras que rara vez causan problemas

Algunos pasos de limpieza resuelven problemas reales de entrada sin cambiar el significado de la dirección.

Las medidas más seguras son:

• Recortar espacios al inicio y al final (incluyendo saltos de línea de copiar/pegar).
• Eliminar caracteres invisibles que a veces aparecen desde hojas de cálculo o aplicaciones de mensajería.
• Pasar a minúsculas solo la parte del dominio (los dominios son efectivamente insensibles a mayúsculas en la práctica).
• Conservar la entrada original almacenada por separado para soporte y auditoría.

Conservar ambas versiones importa. Usa la versión limpia para búsquedas y validación, pero guarda la cadena exacta que introdujo el usuario para que soporte pueda responder: "¿Qué escribió el usuario?" y "¿Qué cambiamos?".

Puntos en la parte local: cuándo importan

Un mito común es que los puntos en las direcciones de correo nunca importan. Esa idea proviene principalmente de Gmail.

Gmail trata los puntos en la parte local como opcionales, así que [email protected] y [email protected] llegan al mismo buzón. Algunas configuraciones de Google Workspace se comportan de forma similar, pero no puedes asumir eso para todos los dominios.

Fuera de Gmail, los puntos pueden ser absolutamente significativos. Muchos sistemas de correo tratan la parte local como texto exacto, por lo que [email protected] y [email protected] pueden ser personas distintas.

Recomendación: no elimines puntos a menos que estés realmente seguro de que el dominio sigue las reglas de puntos al estilo Gmail y estés cómodo con el riesgo de identidad. Si intentas reducir duplicados, trata las coincidencias sin puntos como una "coincidencia posible" que aún necesita prueba del usuario.

Etiquetas "+": útiles para usuarios, riesgosas para la identidad

Las etiquetas + (plus addressing) se ven como [email protected]. La gente las usa para rastrear registros, encaminar recibos y filtrar correo.

La trampa es asumir que alex+news@... siempre es lo mismo que alex@.... Algunos proveedores ignoran la etiqueta y entregan al buzón base. Otros tratan la dirección completa como distinta, o las empresas pueden enrutar el correo de forma diferente según la etiqueta.

Si quitas etiquetas + durante la limpieza, puedes crear colisiones que los usuarios no pretendían. Por ejemplo, alguien podría crear cuentas separadas como [email protected] y [email protected]. Si almacenas ambas como [email protected], puedes fusionar perfiles y enviar restablecimientos o notificaciones al lugar equivocado.

Una regla práctica más segura:

• Envía el correo exactamente a lo que el usuario escribió.
• No elimines +... a menos que tengas una razón específica, limitada y bien probada para un dominio concreto.
• Si usas eliminación de etiquetas para deduplicar, nunca fusiones cuentas automáticamente basándote en ello.

Sensibilidad a mayúsculas: normas vs comportamiento real

Las normas de correo permiten que la parte local sea sensible a mayúsculas, lo que significa que [email protected] y [email protected] podrían ser buzones distintos.

En la práctica, muchos proveedores grandes tratan la parte local como insensible a mayúsculas, por eso las direcciones con mayúsculas suelen funcionar. Pero no puedes asumir ese comportamiento en todas partes.

Un enfoque conservador:

• Pasa a minúsculas la parte del dominio.
• Conserva la parte local tal como se introdujo.
• Si ofreces búsqueda insensible a mayúsculas para iniciar sesión, trátala como una comodidad, no como prueba de que dos cuentas son la misma.
• Nunca mezcles cuentas únicamente porque dos cadenas coinciden tras convertirlas a minúsculas.

Las reglas específicas del proveedor pueden sorprenderte

Muchas fallas de normalización empiezan con: "Este proveedor funciona como Gmail." Esa suposición se rompe rápido.

Incluso dentro del ecosistema de Google, el comportamiento no siempre es tan simple como la gente espera. Y una vez que sales de gmail.com, las reglas pueden cambiar por completo.

Los alias, reenvíos y subdominios añaden más confusión. Una persona puede registrarse con un alias que reenvía a su bandeja; otra puede ser la propietaria real de la dirección similar que asumiste equivalente. Tratar [email protected] como igual a [email protected] es adivinanza.

Si piensas que necesitas transformaciones específicas por proveedor, recoge primero evidencia: mira tus casos reales de colisión, limita la regla a dominios concretos y mantén la dirección en bruto disponible para soporte y auditoría.

Un enfoque paso a paso más seguro

Si normalizas demasiado agresivamente, puedes fusionar a dos personas reales en una sola cuenta. El enfoque más seguro es separar almacenamiento, visualización, validación e identidad.

Un flujo práctico:

1. Almacena el correo en bruto exactamente como se ingresó (para auditoría y soporte).
2. Crea una versión limpia para la interfaz y las comparaciones (recortar espacios, eliminar caracteres invisibles, pasar a minúsculas el dominio).
3. Valida la entregabilidad por separado (sintaxis, existencia del dominio, registros MX), sin reescribir la dirección hacia una identidad diferente.
4. Si decides construir una clave de deduplicación (eliminación de puntos/etiquetas, reglas del proveedor), trata las coincidencias como "posibles" y exige prueba antes de vincular cuentas.
5. Diseña un flujo de trabajo para colisiones: si un registro se mapea a una clave existente, detén el proceso y verifica la propiedad en lugar de adjuntar automáticamente.

Ejemplo: alguien se registra como [email protected], luego más tarde prueba con [email protected]. En un proveedor eso podría ser el mismo buzón; en otro podría ser dos buzones distintos. Trátalo como un aviso para verificar, no como motivo para fusionar.

Errores comunes que causan colisiones

La mayoría de las colisiones ocurren cuando una regla que es válida para un proveedor se aplica a todas las direcciones.

Errores frecuentes:

• Eliminar puntos y etiquetas + de forma global.
• Convertir toda la dirección a minúsculas y usarla como la clave única de la cuenta.
• Fusionar cuentas automáticamente cuando una versión normalizada coincide.

Cuando dos registros se mapean a la misma cadena canónica, puedes denegar registros válidos, enviar restablecimientos de contraseña a la persona equivocada y mezclar facturación o permisos entre usuarios.

Lista de comprobación rápida antes de normalizar

Antes de lanzar cualquier regla de normalización, responde dos preguntas: ¿qué estás optimizando (orden, menos duplicados o seguridad) y qué pasa si te equivocas?

Una línea base segura:

• Almacena el correo en bruto y un valor limpio separado.
• Pasa a minúsculas solo el dominio.
• Evita quitar puntos y etiquetas + a menos que esté muy acotado y tengas un plan para colisiones.
• Trata cualquier "coincidencia normalizada" como una señal, no como identidad, a menos que el usuario pruebe control.

Próximos pasos: reducir duplicados sin adivinar

Si los duplicados te están perjudicando, trata el correo como información de contacto, no como una clave de identidad perfecta. Conserva la dirección original para envíos y soporte, y mantén un valor "normalizado para búsqueda" por separado que puedas cambiar después sin perder historial.

Para reducir registros basura sin reescrituras arriesgadas, valida las direcciones durante el registro y verifica la propiedad antes de asociar una dirección a una cuenta. Si quieres una API para esa capa, Verimail (verimail.co) se centra en comprobaciones de validación de correo como sintaxis RFC, verificación de dominio y MX, y detección de correos desechables, sin obligarte a reescribir direcciones de forma que puedan fusionar usuarios.

Mide lo que cambias: tasas de rebote, tasas de confirmación por correo y con qué frecuencia las direcciones parecidas resultan ser personas diferentes. Deja que esos números guíen tu próxima regla, no la folklore del proveedor.