17 jul 2025·8 min
Direcciones de correo internacionalizadas: qué falla en producción
Las direcciones de correo internacionalizadas pueden fallar en el registro por IDN, normalización Unicode y falta de SMTPUTF8. Aprende pasos seguros de validación.
Las direcciones de correo internacionalizadas pueden fallar en el registro por IDN, normalización Unicode y falta de SMTPUTF8. Aprende pasos seguros de validación.
Una expresión regular solo puede evaluar la forma del texto, no si el dominio puede recibir correo ni si tu infraestructura puede entregarlo. Las regex tienden a ser demasiado estrictas (bloqueando dominios internacionalizados válidos) o demasiado laxas (aceptando entradas que rebotarán o fallarán después).
Si tienes una audiencia global, permitir Unicode en la parte del dominio suele ser seguro porque puede convertirse a una forma ASCII para las comprobaciones DNS. Unicode en la parte local es una decisión mayor: debes confirmar que toda tu cadena de entrega soporta SMTPUTF8; si no, corres el riesgo de inscripciones que no pueden recibir verificación o restablecimientos.
Mantén lo que el usuario escribió para mostrarlo, pero convierte el dominio a su forma ASCII antes de hacer búsquedas DNS o MX. Almacenar la forma ASCII junto a la original ayuda a deduplicar de forma consistente y evita desajustes entre bibliotecas que tratan los IDN de distinta manera.
Normaliza desde temprano, idealmente antes de validar, comparar o aplicar unicidad, para que entradas visualmente idénticas no creen cuentas separadas. NFC es una opción práctica porque reduce problemas de “mismo aspecto, distintos bytes” sin reescribir caracteres tan agresivamente como NFKC.
Pon en minúsculas la parte del dominio porque, en la práctica, los nombres de dominio no distinguen mayúsculas. Evita poner en minúsculas la parte local por defecto, ya que en algunos sistemas puede ser sensible a mayúsculas y minúsculas y esto puede causar sorpresas con reglas de caso no ASCII.
Almacena tanto la entrada original como una forma canónica que uses para comparaciones, búsquedas y restricciones de unicidad. La forma canónica suele estar recortada de espacios alrededor, normalizada a NFC y con el dominio en minúsculas y convertido a ASCII cuando sea necesario; la forma para mostrar se mantiene amigable para el usuario.
Primero haz una comprobación de sintaxis, luego verifica que el dominio se pueda resolver y busca registros MX usando la versión ASCII del dominio. Esto atrapa errores tipográficos y dominios muertos, pero no prueba que una bandeja de entrada específica exista, así que combina estas comprobaciones con la confirmación de propiedad por correo.
A menudo falla porque el canal de salida lo rechaza, no porque tu app lo aceptara. Una causa común es la falta de soporte SMTPUTF8 en algún punto entre tu app, tu proveedor de correo y relays intermedios, lo que puede romper la entrega para partes locales con caracteres no ASCII aunque la dirección sea válida.
Recorta espacios obvios alrededor, pero ten cuidado al “limpiar” para no eliminar caracteres Unicode que podrían ser significativos. También ayuda detectar y advertir sobre caracteres ocultos como espacios de ancho cero para que el usuario corrija la entrada en lugar de quedar bloqueado silenciosamente.
Úsalo para sustituir lógicas de validación frágiles e inconsistentes por una única llamada API que compruebe la sintaxis conforme al RFC, verifique el dominio, busque registros MX y señale entradas de riesgo como dominios desechables. Es especialmente útil cuando quieres decisiones rápidas y consistentes en el registro sin mantener tu propia canalización multi-etapa.
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ó.
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:
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?
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:
Dos errores comunes:
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:
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.
La normalización convierte texto en una forma consistente.
Para el manejo de correos, NFC suele ser el valor predeterminado más seguro para comparaciones de "hacer iguales".
Las reglas de mayúsculas difieren entre las dos partes de una dirección:
@): es seguro tratarla como insensible a mayúsculas. Pasarla a minúsculas es estándar.@): 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.
Normaliza en los momentos donde la consistencia importa:
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.
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:
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.
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.
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.
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.
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.
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).
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.
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:
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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:
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: