Las direcciones de correo electrónico parecen simples, pero arrastran décadas de historia, normas y excepciones que las hacen mucho más complicadas de lo que cualquier desarrollador quisiera admitir. Este artículo desmonta, una por una, las creencias erróneas más comunes sobre cómo gestionarlas en aplicaciones reales.
La primera gran mentira es que basta con una expresión regular para validar un correo. El autor explica por qué esta práctica sigue viva en 2026 a pesar de los costes de rendimiento, la fragilidad de los motores de regex y la rápida obsolescencia de cualquier patrón. Frente a ello, recomienda validar solo lo mínimo —asegurarse de que hay un «algo@algo»— y, sobre todo, verificar la dirección enviando un correo de confirmación.
La segunda mentira asume que los proveedores respetan las especificaciones. En la práctica, software como Postfix, Dovecot o Gmail implementan los RFC de forma desigual: SMTPUTF8, la internacionalización del correo, lleva años parcialmente soportada y Dovecot aún no lo incorpora. El artículo muestra un caso concreto: una dirección con 80 bytes en la parte local, formalmente inválida según la sección 4.5.3.1.1 del RFC 5321, que en realidad se entrega sin problemas.
La tercera mentira es que los correos solo admiten caracteres ASCII. El estándar RFC 6531, publicado en 2012, permite caracteres Unicode en la parte local, lo que habilita direcciones internacionalizadas, aunque la adopción por parte de clientes y proveedores sigue siendo irregular.
En conjunto, el texto es una guía divulgativa y técnicamente rigurosa dirigida a desarrolladores y equipos de producto que diseñan formularios, APIs o sistemas de autenticación por correo. Su conclusión es clara: en lugar de invertir esfuerzo en validar formatos, conviene verificar la propiedad del buzón y confiar en que el servicio de envío hará el resto.