Los errores al normalizar correos pueden causar colisiones de cuentas. Aprende qué es seguro normalizar (y qué no) respecto a puntos, etiquetas + y mayúsculas.
La normalización de correo electrónico es reescribir lo que un usuario escribió en una forma más consistente para almacenamiento o comparación, como recortar espacios o convertir a minúsculas una parte de la dirección. Se vuelve arriesgada cuando la normalización cambia la identidad, por ejemplo al eliminar puntos o quitar +tags, porque eso puede hacer que dos direcciones diferentes parezcan iguales en tu base de datos.
Recortar espacios al inicio y al final y eliminar caracteres invisibles de un copy-paste suelen ser seguros porque corrigen artefactos de entrada, no la identidad. Convertir a minúsculas la parte del dominio también suele ser seguro porque los dominios se tratan como insensibles a mayúsculas en la práctica.
Convertir a minúsculas la parte del dominio es una buena práctica por defecto. Convertir a minúsculas la parte local (antes de @) es arriesgado porque las normas permiten sensibilidad a mayúsculas y algunos sistemas pueden tratar [email protected] diferente a [email protected], aunque muchos proveedores no lo hagan.
No elimines puntos por defecto. El comportamiento de puntos al estilo Gmail no es universal, y muchos sistemas de correo empresarial o autoalojados consideran los puntos significativos, por lo que [email protected] y [email protected] pueden ser personas distintas.
No es seguro como regla global. Muchos proveedores entregan [email protected] al mismo buzón que [email protected], pero otros tratan la parte local completa como distinta, y organizaciones pueden enrutar el correo de forma diferente según la etiqueta.
Trata las coincidencias normalizadas como una pista, no como prueba. Mantén las cuentas separadas a menos que el usuario demuestre que controla la dirección (por ejemplo, verificando la propiedad del correo) y crea un flujo deliberado para resolver direcciones parecidas en lugar de adjuntarlas automáticamente a un usuario existente.
Guarda el correo original exactamente como se escribió para auditorías, soporte y envío. Guarda un valor separado limpio para búsqueda y comparaciones para poder ajustar reglas después sin perder historial ni reescribir accidentalmente lo que el usuario proporcionó.
Usa la versión normalizada solo como conveniencia para encontrar una cuenta, no como identificador único. Si permites búsqueda insensible a mayúsculas o coincidencias relajadas, asegúrate de que el paso final verifique la propiedad antes de permitir restablecer una contraseña o acceder a una cuenta.
Supón que pueden ser diferentes a menos que tengas pruebas sólidas y específicas por dominio. Tratar [email protected] como igual a [email protected] (o asumir que los alias siempre apuntan al mismo buzón) es una suposición que puede fusionar usuarios no relacionados.
Valida la entregabilidad por separado de las reglas de identidad. Usa comprobaciones como validación de sintaxis, verificación de dominio y registros MX, y detección de correos desechables sin reescribir la dirección; herramientas como Verimail (verimail.co) se centran en estos pasos de validación y te permiten conservar la dirección original del 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:
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.
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:
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.
Algunos pasos de limpieza resuelven problemas reales de entrada sin cambiar el significado de la dirección.
Las medidas más seguras son:
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?".
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.
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:
+... a menos que tengas una razón específica, limitada y bien probada para un dominio concreto.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:
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.
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:
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.
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:
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.
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:
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.