El formato de dirección de correo parece un asunto resuelto, y sin embargo es una fuente constante de errores: campos que rechazan direcciones legítimas, validaciones que aceptan basura y usuarios que no entienden por qué su dirección no vale. La causa de casi todos esos problemas es la distancia entre lo que permite la norma pública y lo que los servicios aceptan en la práctica.
Las dos mitades de una dirección
Toda dirección se divide en dos partes separadas por el signo arroba. A la izquierda está la parte local, la que identifica el buzón dentro del dominio. A la derecha está el dominio, la parte que se consulta para saber dónde entregar el mensaje.
Esa separación importa porque las dos mitades se validan de forma distinta. La parte local admite más variedad de la que la mayoría de la gente imagina, mientras que el dominio sigue reglas de nombres mucho más estrictas. Un formulario que aplique el mismo criterio a las dos mitades se equivocará en alguna de ellas.
También conviene recordar que la dirección identifica un buzón, no a una persona. Dos direcciones distintas pueden acabar en la misma bandeja, y una misma persona puede tener muchas.
¿Cuánto puede medir una dirección de correo?
La norma pública fija tres topes, todos ellos expresados en bytes.
| Elemento | Límite de la norma |
|---|---|
| Parte local | 64 bytes |
| Dominio | 255 bytes |
| Dirección completa, con los ángulos | 256 bytes |
En la práctica, la mayoría de los servicios aceptan menos que eso. La convención de ingeniería más extendida ronda los 254 caracteres para la dirección completa, y muchas aplicaciones imponen topes aún más bajos por comodidad o por herencia de sistemas antiguos.
Esa diferencia explica un malentendido frecuente: una dirección puede cumplir la norma y ser rechazada igualmente. El estándar establece el máximo que el sistema de correo debe soportar, no la obligación de que cada sitio web lo admita.
Lo que la norma permite y muchos servicios rechazan
La lista de formas legales que rara vez funcionan en un formulario real es sorprendentemente larga.
- Una parte local entre comillas, que puede contener espacios y caracteres poco habituales.
- Comentarios entre paréntesis, que la norma contempla y casi nadie escribe.
- Un dominio escrito como dirección numérica entre corchetes en lugar de un nombre.
- Caracteres no latinos en la parte local, admitidos por la extensión de internacionalización del correo.
Ninguna de esas variantes es un error de quien la escribe. Son formas que el estándar contempla y que la mayoría de los servicios no aceptan porque no las necesitan en su día a día.
La conclusión útil es que el término dirección válida es ambiguo. Hay una validez según la norma y otra según el servicio concreto, y las decisiones de diseño deben decir a cuál se refieren.
¿Por qué se rechaza una dirección válida al registrarse?
Casi siempre por una validación demasiado estricta escrita mucho antes de que el problema apareciera. Un patrón copiado de un foro, con una lista de caracteres admitidos que se queda corta, rechaza direcciones perfectamente usables y deja al usuario sin salida.
Hay un segundo motivo, más sutil: algunas comprobaciones se hacen en dos sitios distintos, con criterios ligeramente diferentes. El formulario acepta la dirección y el servidor la rechaza después, y el mensaje de error que ve el usuario no tiene nada que ver con la causa real.
La forma sensata de validar es comprobar lo mínimo imprescindible: que existe el signo arroba, que hay algo a cada lado y que la longitud total está dentro de un margen razonable. Todo lo demás se descubre enviando el mensaje de confirmación, que es la única prueba real de que la dirección funciona.
Mayúsculas, espacios y acentos
La parte local se trata técnicamente como distinta según las mayúsculas, pero en la práctica casi todos los servicios la consideran equivalente y guardan la dirección en minúsculas. Es una simplificación razonable, siempre que sea coherente en todo el sistema y no provoque que una misma persona acabe con dos cuentas.
Los espacios son otra fuente de problemas. Un espacio al final, invisible en la pantalla, basta para que la dirección no exista. Recortar los extremos antes de validar y de guardar evita una categoría entera de incidencias.
Con los acentos y las letras no latinas conviene ser prudente. Aunque la norma los contempla, el soporte real varía mucho de un servicio a otro, y una dirección con acentos puede funcionar en un sitio y fallar en otro. Si tu producto los admite, hazlo de forma consciente y avisa de las limitaciones.
Probar el campo con direcciones de prueba
La mejor manera de descubrir si una validación es demasiado estricta es enfrentarla a casos raros. En el buzón de correo temporal de este sitio se puede generar una dirección real, recibir en ella y comprobar el recorrido completo del formulario sin usar el correo de nadie.
Para revisar los campos que acompañan a la dirección, la página de México resume los formatos de dirección postal y teléfono de ese país, útil cuando el formulario valida varios campos por región.
Notas para quien programa
- No escribas un patrón propio para validar direcciones. Es un problema resuelto y las soluciones caseras fallan en los casos raros.
- Aplica los topes de longitud según la norma, pero deja margen: si tu campo corta a un número redondo más bajo, estarás rechazando direcciones válidas.
- Normaliza antes de guardar. Recorta espacios en los extremos y decide de una vez si vas a distinguir mayúsculas de minúsculas.
- Valida en el servidor y en el cliente con el mismo criterio. Dos reglas distintas producen errores imposibles de explicar al usuario.
- No rechaces una dirección solo porque su dominio no responda. El envío del mensaje de confirmación es la comprobación que cuenta.
- Prueba el campo con las variantes legales de la lista anterior y decide de forma explícita cuáles admites y cuáles no.
Siguientes pasos
Reúne una veintena de direcciones que hayan dado problemas reales y pásalas por tu formulario. Cada rechazo inesperado es una validación que hay que revisar, y casi siempre el arreglo es quitar código en lugar de añadirlo.
Para el paso siguiente del recorrido, la guía sobre pruebas de verificación por correo explica cómo cubrir la confirmación una vez que la dirección ha sido aceptada.
Una dirección de ejemplo sirve para validar un campo, no para acreditar a nadie: no la uses como identidad verdadera.