Direcciones de correo internacionalizadas: qué falla en producción

Por qué los correos que parecen válidos fallan en producción

Una dirección de correo puede parecer normal y aun así fallar en cuanto llega a un sistema real. La razón principal es que lo que la gente ve como un carácter puede almacenarse como bytes distintos, procesarse de forma diferente por bibliotecas o rechazarse en servidores de correo antiguos.

Un ejemplo típico es algo como søren@exämple.com. Puede ser una dirección legítima, pero toca varios puntos frágiles a la vez: Unicode en la parte local, un nombre de dominio internacionalizado y una infraestructura de correo que quizá no lo soporta.

Los fallos también aparecen lejos del formulario de registro. Puedes aceptar la dirección y luego fallar al enviar un restablecimiento de contraseña porque tu proveedor de correo (o un relay intermedio) no soporta SMTPUTF8. O tu regex la acepta, pero tu paso de "pasar a minúsculas y recortar" la convierte en algo distinto a lo que el usuario pretendía.

Los rechazos falsos son costosos porque a menudo son silenciosos. La gente abandona el registro, prueba con otro correo o abre tickets de soporte difíciles de reproducir. Si tienes audiencia global, rechazar direcciones internacionalizadas también puede dar la impresión de que no soportas su idioma.

Aceptar por error te cuesta de otra forma. Direcciones malas generan rebotes, menor entregabilidad y listas desordenadas. Algunas entradas con apariencia válida son deliberadamente maliciosas: dominios desechables, cuentas de rol usadas para abuso o trampas de spam que dañan la reputación del remitente.

El objetivo no es "aceptar todo" ni "bloquear todo". Es aceptar a usuarios reales mientras detienes entradas obviamente dañinas, usando comprobaciones que reflejen cómo funciona el correo: separar la visualización del almacenamiento, verificar la alcanzabilidad del dominio (no solo la existencia de @) y evitar transformaciones agresivas que reescriban silenciosamente lo que el usuario escribió.

Qué cuenta como una dirección de correo internacionalizada

Una dirección tiene dos partes separadas por @: la parte local (antes de @) y el dominio (después de @). Las direcciones internacionalizadas pueden incluir caracteres Unicode en cualquiera de las dos partes, y el soporte en el mundo real varía según qué lado use Unicode.

El caso más común es un nombre de dominio internacionalizado (IDN). El usuario ve un dominio escrito en su escritura, como maria@bücher.example o li@例子.公司. Bajo el capó, muchos sistemas convierten ese dominio a una forma ASCII (a menudo llamada punycode) para que las búsquedas DNS y las comprobaciones MX funcionen de forma fiable.

El caso más complicado es Unicode en la parte local, como jó[email protected] o ユーザー@domain.com. Esto entra en Email Address Internationalization (EAI) y normalmente se entrega usando SMTPUTF8. Incluso si la dirección es válida según los estándares modernos, algunos servidores de correo, bibliotecas antiguas y herramientas posteriores la rechazan. Eso significa que puedes aceptarla en el registro y aun así fallar al intentar enviar.

Una forma práctica de pensar en el soporte hoy:

• Los dominios Unicode son ampliamente utilizables porque pueden representarse en ASCII para DNS.
• Las partes locales Unicode tienen soporte menos consistente de extremo a extremo (formulario, base de datos, CRM, proveedor de correo y buzón deben manejarlas).
• Las escrituras mixtas y los caracteres que se parecen aumentan el riesgo de fraude.
• La visualización y el almacenamiento fallan cuando el software asume "un carácter = un byte".

Por eso una regex sí/no no es suficiente. Una regex puede rechazar usuarios legítimos (por ejemplo, bloqueando todo no ASCII) o aceptar direcciones a las que no puedes entregar realmente.

Una validación mejor trata cada lado por separado. Para el dominio, normaliza y convierte a ASCII para las comprobaciones DNS. Para la parte local, necesitas una decisión de política: ¿soportas SMTPUTF8 completamente, lo permites con advertencia o lo bloqueas porque tu pila de correo no puede entregarlo con fiabilidad?

IDN y punycode: el lado del dominio

Un IDN (Internationalized Domain Name) es un dominio que usa caracteres no ASCII, como acentos o escrituras no latinas. La gente ve y escribe la forma Unicode, pero DNS se basa en ASCII. Esa discrepancia es donde empiezan muchos bugs en producción.

Para buscar registros MX, verificar un dominio o incluso hacer una comprobación DNS básica, normalmente necesitas la forma ASCII del dominio. Esa conversión se hace con las reglas IDNA y produce punycode, que a menudo comienza con xn--. Así que un usuario puede introducir un dominio que le parece normal, pero tus logs, la base de datos o un proveedor aguas arriba pueden mostrar una versión xn--....

El punycode aparece en sitios que debes prever y manejar:

• Búsquedas DNS y de registros MX
• Llamadas a APIs de validación o deliverability
• Logs y herramientas de seguridad (para que los analistas puedan copiar y pegar con seguridad)
• Almacenamiento y deduplicación (para que un mismo dominio no se guarde dos veces en formas diferentes)

Dos errores comunes:

• Validar solo el dominio en Unicode como cadena y nunca convertirlo antes de las comprobaciones DNS.
• Rechazar cualquier dominio con caracteres no ASCII, lo que bloquea usuarios legítimos.

También hay un ángulo de seguridad. Caracteres de escrituras mezcladas y los "confusables" pueden crear dominios que se parecen visualmente a una marca de confianza. Normalmente no deberías bloquear todos los IDN por esto, pero sí es razonable tratarlos como de mayor riesgo en contextos como pagos, restablecimientos de contraseña o acceso de administrador.

Un enfoque práctico es aceptar lo que escribe el usuario y luego normalizar internamente:

• Aceptar el dominio en Unicode en el campo de entrada.
• Convertir el dominio a ASCII (punycode) para las comprobaciones DNS y MX.
• Almacenar ambas formas cuando sea posible: Unicode para mostrar, ASCII para comprobaciones técnicas y emparejamientos consistentes.
• Marcar patrones sospechosos (escrituras mezcladas, confusables) para revisión adicional o verificación de seguridad.

Normalización Unicode: por qué el mismo texto no siempre es el mismo

Unicode permite escribir nombres y palabras de muchos idiomas, pero también significa que el "mismo" carácter puede representarse de más de una forma. Si comparas cadenas por bytes crudos, o almacenas una forma y luego recibes otra, puedes obtener duplicados, inicios de sesión fallidos y confusos errores de "correo ya en uso".

Un ejemplo sencillo son los caracteres acentuados. La letra "é" puede ser un único punto de código (U+00E9), o dos puntos de código: "e" (U+0065) más un acento combinante (U+0301). Para una persona se ven idénticos, pero tu base de datos puede tratarlos como distintos.

NFC vs NFKC (y por qué importa)

La normalización convierte texto en una forma consistente.

• NFC (Normalization Form C) compone caracteres cuando es posible. Suele conservar la intención del usuario y hace fiables las comparaciones de igualdad.
• NFKC va más lejos convirtiendo caracteres de compatibilidad en equivalentes más simples (por ejemplo, algunas formas de ancho completo). Esto puede mejorar la consistencia, pero también puede cambiar el significado e interactuar mal con suplantaciones y confusables si se aplica sin cuidado.

Para el manejo de correos, NFC suele ser el valor predeterminado más seguro para comparaciones de "hacer iguales".

Manejo de mayúsculas: qué pasar a minúsculas (y qué no)

Las reglas de mayúsculas difieren entre las dos partes de una dirección:

• Parte del dominio (a la derecha de @): es seguro tratarla como insensible a mayúsculas. Pasarla a minúsculas es estándar.
• Parte local (a la izquierda de @): técnicamente es sensible a mayúsculas, aunque muchos proveedores lo ignoran. Pasarla a minúsculas puede fusionar dos direcciones distintas en algunos sistemas.

Un enfoque práctico: pasar a minúsculas y normalizar el dominio; mantener la parte local tal como la introdujo el usuario, pero también almacenar una forma canónica para comparaciones.

Cuándo normalizar (y cuándo preservar)

Normaliza en los momentos donde la consistencia importa:

• En la entrada: normaliza a NFC antes de validar y antes de comprobar "ya registrado".
• En almacenamiento: guarda la cadena original (para mostrar y soporte) y una forma canónica (para búsqueda y deduplicación).
• En comparación: compara usando la forma canónica, no la entrada cruda.

Incluso con un buen servicio de validación, tu app necesita una política clara de normalización y mayúsculas para que usuarios legítimos no queden bloqueados por diferencias invisibles de caracteres.

Dónde suelen fallar los sistemas en producción

La mayoría de los errores con direcciones internacionalizadas ocurren en las uniones, donde un sistema hace una suposición distinta a la siguiente. La dirección parece bien al usuario, pero algo en la cadena la cambia, la rechaza o trata como diferentes dos valores que se ven idénticos.

Un fallo común empieza en el formulario de registro. Las reglas en el frontend suelen permitir solo A-Z, 0-9 y unos pocos símbolos. Los teclados móviles insertan puntuación inteligente y el autocompletado añade un espacio final que no ves. El auto-lowercase también se comporta de forma extraña fuera del ASCII básico.

En el backend, pequeños pasos de limpieza pueden ser destructivos. Recortar está bien, pero eliminar "caracteres no imprimibles" puede borrar marcas Unicode válidas. Los límites de longitud son otro problema silencioso: los dominios internacionalizados pueden crecer al convertirse a punycode y puedes chocar con un límite inesperado.

Las bases de datos añaden sus propias trampas. Las reglas de colación y comparación deciden si dos cadenas son iguales. Si un sistema almacena una forma compuesta y otro envía más tarde una forma descompuesta, las comprobaciones de unicidad pueden fallar. Eso puede crear cuentas duplicadas o bloquear a un usuario porque tu consulta de "ya existe" no coincide con lo almacenado.

Los problemas aparecen más en:

• Validación en cliente y widgets de entrada
• Saneamiento en servidor, recortes y límites de longitud
• Colación de base de datos e índices únicos
• Integraciones (CRMs, analítica, herramientas de soporte, procesadores de logs)
• Sistemas de correo saliente que no soportan SMTPUTF8

El correo saliente es donde se vuelve inevitable. Si tu servidor de correo o un relay aguas abajo no soporta SMTPUTF8, puede negarse a enviar a un buzón con caracteres no ASCII en la parte local. Los usuarios pueden registrarse, pero nunca recibir un correo de verificación.

Una cadena de fallos realista se ve así: un usuario se registra con un dominio Unicode, tu app lo almacena, tu CRM lo normaliza de forma distinta y tu proveedor de correo rechaza SMTPUTF8. Ahora tienes un usuario, dos cadenas que no coinciden y un correo de bienvenida que nunca llega.

Paso a paso: un flujo de validación más seguro

Un flujo más seguro empieza separando dos objetivos: no bloquear a personas reales en el registro y almacenar algo que puedas comparar, enviar y soportar después.

1. Preserva la entrada del usuario. Guarda la dirección exactamente como se escribió y luego elimina solo espacios visibles alrededor. Evita ediciones "útiles" como cambiar mayúsculas, quitar acentos, eliminar puntos o eliminar etiquetas con plus. Esas modificaciones pueden convertir silenciosamente una dirección en otra.

2. Haz una comprobación de sintaxis real. Trátala como "¿es esto estructuralmente posible?", no como "seguro que el correo llegará". Las reglas modernas son más amplias que la mayoría de las regex, especialmente cuando hay caracteres internacionales.

3. Decide sobre normalización y unicidad. Guarda la dirección cruda y una forma canónica (a menudo NFC) para comprobaciones de igualdad. Si el correo es clave única en tu sistema, especifica si entradas visualmente idénticas pero codificadas de forma distinta deben contarse como la misma cuenta.

4. Maneja el dominio correctamente. Normaliza el dominio y conviértelo a ASCII (punycode) antes de cualquier trabajo DNS. Luego verifica el dominio y comprueba registros MX (y posiblemente A/AAAA si tu política lo permite).

5. Crea una política para partes locales Unicode. Si tu proveedor de salida no puede entregar SMTPUTF8 de forma fiable, acepta el registro solo si tienes un plan alternativo (verificación en la app, método de contacto alternativo o una advertencia clara antes de prometer entrega por correo).

Conserva un pequeño conjunto de logs sobre resultados de validación para que soporte pueda diagnosticar casos límite sin adivinar.

Validación vs entregabilidad: qué puedes demostrar

La gente suele decir "validación de correo" cuando quieren decir "¿llegará mi mensaje a una persona real?". Eso es entregabilidad, y no puedes probarlo completamente en el registro. Con direcciones internacionalizadas, es aún más fácil confundir "parece válido" con "funcionará en todas partes".

La validación aún puede dar señales fuertes antes de almacenar una dirección o enviar a ella:

• La sintaxis es aceptable (incluyendo reglas SMTPUTF8 cuando corresponda)
• El dominio existe y puede resolverse
• Hay registros MX (o el dominio está configurado para recibir correo)
• La dirección o el dominio parecen de riesgo (por ejemplo, proveedores desechables)

Pero la validación no garantiza que la bandeja exista o aceptará tu mensaje. Muchos proveedores bloquean sondeos de buzones, aceptan correo para usuarios desconocidos y luego rebotan, o cambian políticas sin aviso.

Un enfoque más seguro es en dos etapas:

• Validar en el registro para atrapar problemas obvios, reducir errores tipográficos y prevenir registros de baja calidad.
• Confirmar la propiedad con un paso de verificación por correo (un clic para confirmar). Eso es lo que prueba que el usuario puede recibir correo y controla la dirección.

Para resultados "de alto riesgo", los bloqueos duros suelen crear falsos negativos. La fricción suave suele funcionar mejor: permitir el registro, exigir confirmación antes de acciones clave o pedir una señal adicional solo cuando el riesgo es alto.

Errores comunes que bloquean usuarios legítimos

La forma más rápida de perder registros reales es tratar todo lo que no sea ASCII simple como inválido. Muchos proveedores legítimos soportan dominios internacionalizados y algunos usuarios dependen de ellos.

Error 1: reglas "solo ASCII" demasiado estrictas

Mucho código en producción aún asume que correo significa A-Z, 0-9, puntos y una corta lista de símbolos. Eso falla con dominios IDN y garantiza rechazos falsos en productos globales.

Error 2: pasar todo a minúsculas o normalizar la dirección completa

Poner en minúsculas el dominio está bien. Poner en minúsculas la parte local puede ser arriesgado.

La normalización ayuda, pero aplicarla sin criterio puede sorprender a los usuarios. Normaliza intencionalmente, guarda la entrada original y prueba cómo se comportan los sistemas aguas abajo.

Transformaciones "útiles" comunes que fallan:

• Recortar demasiado (o eliminar caracteres que parecen invisibles)
• Pasar toda la dirección a minúsculas
• Aplicar una única forma de normalización en todas partes sin probar las exportaciones e integraciones
• Eliminar automáticamente puntos o etiquetas con plus (comportamiento específico del proveedor)

Error 3: mostrar punycode a los usuarios

Tu backend puede necesitar punycode para comprobaciones DNS, pero la UI debería mostrar normalmente el dominio en la escritura del usuario. Mostrar xn--... en confirmaciones o errores suele parecer sospechoso, aunque la dirección sea correcta.

Error 4: asumir que las partes locales Unicode siempre funcionan

Aunque una dirección sea válida por especificación, no todos los servidores de correo soportan SMTPUTF8. Si aceptas partes locales Unicode, prepárate para diferencias de entregabilidad entre proveedores.

Error 5: ignorar artefactos de pegar

Copiar y pegar introduce espacios de no separación, caracteres de ancho cero y espacios alrededor del @. Los usuarios no ven estos problemas, pero tu validación sí.

Ejemplo: un usuario pega name@пример.рф con un espacio final. Si validas antes de recortar, lo rechazas. Si sobre-sanitizas, puedes alterar la parte local.

Comprobaciones rápidas antes de lanzar

Las direcciones internacionalizadas pueden funcionar de extremo a extremo, pero solo si cada capa está de acuerdo en lo que acepta, almacena y envía. Antes del lanzamiento, ejecuta comprobaciones que repliquen el comportamiento en producción, no solo pruebas unitarias.

Lista práctica antes de enviar

• Confirma que el formulario acepta Unicode donde pretendes (dominio, parte local o ambas). Si no soportas partes locales Unicode, indícalo en el punto de entrada.
• Elige una regla de normalización (a menudo NFC) y aplícala de forma consistente en el navegador, API, jobs en background y herramientas admin.
• Convierte el dominio a ASCII (punycode) antes del trabajo DNS y guarda una forma comparable para que las búsquedas no se desvíen.
• Haz que la unicidad de cuentas coincida con las reglas de inicio de sesión y búsqueda. Decide si direcciones visualmente idénticas pero codificadas distinto deben mapear a un solo usuario.
• Prueba el correo saliente en tu ruta real (proveedor, relay, librería) usando ejemplos con dominio IDN y parte local Unicode.

Comprobaciones que la gente olvida (hasta que llegan tickets de soporte)

Asegúrate de que los logs y herramientas admin pueden mostrar la versión amigable sin convertirla en mojibake o romper exportaciones. También confirma que todos los sistemas que tocan la dirección la manejan: eventos de analítica, sincronización con CRM, payloads de webhooks, exportaciones CSV e ingestión en data warehouse. Muchos fallos ocurren en exportaciones, no en la entrada.

Una prueba concreta: pasa la misma dirección por registro, inicio de sesión, restablecimiento de contraseña y cualquier flujo de fusión de cuentas. Si pasa el registro pero falla después, tienes un desajuste en normalización, almacenamiento o comparaciones.

Escenario de ejemplo y siguientes pasos

Un usuario se registra con marta@bücher.example. Parece normal porque el dominio está en Unicode. Tu sistema debe tratar el dominio como un IDN.

En el lado del dominio, mantén la visualización amigable pero valida la forma segura para DNS. Convierte bücher.example a punycode (xn--bcher-kva.example) antes de hacer búsquedas MX. Si solo compruebas la forma Unicode, algunas librerías DNS fallarán o se comportarán de forma inconsistente.

Ahora la parte sutil: el mismo correo se puede escribir de varias maneras que parecen idénticas. Supón que el usuario escribe márta@bücher.example, pero la "á" puede ser un carácter compuesto o una "a" más un acento combinante. Si solo guardas la entrada cruda, un usuario puede acabar con dos cuentas que se ven iguales en tu interfaz.

La normalización soluciona esto. Normaliza a NFC antes de comparar, almacenar, limitar por tasa o deduplicar, y aplica los mismos pasos en todos los sitios donde se toque la dirección.

La parte local (todo lo antes de @) es donde necesitas una política clara. SMTPUTF8 permite partes locales Unicode, pero no todos los proveedores lo soportan de extremo a extremo. Una política práctica para muchos productos es:

• Aceptar partes locales ASCII por defecto.
• Si la parte local contiene Unicode, aceptarla pero requerir confirmación o mostrar una advertencia clara.
• Si tu producto depende mucho de la entrega por correo (restablecimientos, facturas), bloquear partes locales Unicode salvo que hayas probado el soporte SMTPUTF8 en toda tu pila de correo.

Si quieres un lugar único para ejecutar comprobaciones de sintaxis, verificación de dominio y MX (y filtrar proveedores desechables), una API de validación de correo como Verimail (verimail.co) puede proporcionar esas señales sin depender de una regex frágil.

Siguientes pasos que te mantienen seguro sin rechazar a usuarios reales:

• Documenta tu política para partes locales Unicode (aceptar, advertir o bloquear) y aplícala de forma consistente en web, móvil y herramientas de administración.
• Normaliza a NFC antes de almacenar, comparar o deduplicar.
• Prueba casos límite: dominios IDN, escrituras mezcladas, caracteres compuestos vs descompuestos y entradas pegadas.
• Monitorea resultados: tasa de confirmación, rebotes y errores de "correo ya en uso" tras la normalización.
• Conserva logs suficientes sobre decisiones de validación para depurar rechazos falsos rápidamente.