Validador de correo electrónico

¿Qué es un validador de correo electrónico?

Un validador de correo responde si una cadena está bien formada como dirección de correo electrónico. Los formularios de registro usan uno para cazar erratas antes de que cuesten un restablecimiento de contraseña, las listas de distribución para que no se disparen los rebotes, y quien programa acude a uno cuando una expresión regular copiada de internet ha empezado a rechazar a un cliente cuya dirección es perfectamente legal.

El problema es que no hay una sola respuesta, y son las propias especificaciones las que lo dicen. La norma HTML define qué acepta un campo <input type=email> y describe su propia definición, con esas palabras, como «una violación deliberada de RFC 5322», el estándar de internet para el formato de los mensajes. Da tres motivos: RFC 5322 es demasiado estricta antes de la arroba, demasiado vaga después y demasiado laxa al permitir comentarios, espacios y cadenas entrecomilladas que dejarían perpleja a casi cualquier persona.

Las tres quejas se sostienen al comprobarlas, y la consecuencia es lo que esta página existe para enseñar: ninguna de las dos normas contiene a la otra. Cada una acepta direcciones que la otra rechaza. Por eso esta herramienta da los dos veredictos uno al lado del otro y nombra la regla que decidió.

Cómo usarlo

1. Pega tus direcciones, una por línea. Sirve una sola y sirve una lista de miles. Las líneas en blanco se saltan en vez de contarse como fallos, y los espacios sobrantes se recortan, así que pegar una columna de una hoja de cálculo hace lo que esperas.
2. Lee las dos etiquetas de cada fila. Una es la regla de los formularios HTML, la que decide si el navegador dejará enviar el campo. La otra es RFC 5322, la que implementa una biblioteca de correo. Cuando discrepan, la fila queda marcada, porque ese es el caso que interesa conocer.
3. Lee el motivo de debajo. Sea cual sea la norma que rechazó la dirección, la línea inferior dice qué regla lo hizo: un punto mal colocado, una parte local entrecomillada, un comentario entre paréntesis, un guion al borde de una etiqueta de dominio. Un veredicto sin motivo no sirve de mucho cuando hay que decidir si se arregla la dirección o el validador.

Dónde se separan las dos normas

Tres direcciones de aspecto corriente son válidas para la regla HTML e inválidas para RFC 5322, y las tres tienen que ver con los puntos. RFC 5322 construye la parte anterior a la arroba con un «dot-atom»: trozos de texto unidos por puntos sueltos. Así que un punto doble, uno inicial o uno final rompen la gramática. El patrón de HTML simplemente permite puntos en cualquier sitio de esa tirada de caracteres, de modo que john..doe@example.com pasa un formulario del navegador y falla un analizador estricto.

Bastantes más van en sentido contrario. RFC 5322 deja que la parte anterior a la arroba sea una cadena entrecomillada, así que "john..doe"@example.com es legal: las comillas convierten los puntos en datos y no en estructura. Admite comentarios entre paréntesis casi en cualquier posición, con lo que john.doe(comment)@example.com se analiza sin problema. Permite que el dominio sea una dirección literal entre corchetes, tanto user@[192.168.0.1] como la forma IPv6. Y su gramática de dominio no tiene regla alguna sobre las etiquetas, que es a lo que la norma HTML llama «demasiado vaga»: user@-example.com y una etiqueta de dominio de 64 caracteres son sintácticamente correctas para RFC 5322 y las dos las rechaza el navegador.

La lectura práctica es que la regla de HTML es un compromiso deliberado, no un error. Es más estrecha donde la RFC es permisiva con cosas que nadie escribe, y más ancha donde la RFC es quisquillosa con cosas que la gente sí escribe. Si validas un campo de formulario, imitar al navegador suele ser lo correcto. Si escribes un analizador de correo, no lo es.

Límites honestos

Ninguna de las dos columnas dice si el correo llegaría de verdad. Esa es una tercera pregunta entera —si el dominio existe, si tiene servidor de correo, si el buzón existe, si aceptará el mensaje— y exige consultas DNS y una conversación SMTP. Una página que corre en tu navegador no puede hacer nada de eso, así que esta herramienta no lo finge. Quien afirme comprobar la entregabilidad sin enviar un mensaje o está adivinando a partir de una lista de dominios conocidos o está haciendo el trabajo en un servidor al que le estás entregando tu lista.

Los límites de longitud merecen conocerse y son más raros de lo que parecen. RFC 5321 topa la parte anterior a la arroba en 64 octetos y el dominio en 255. Los 254 caracteres totales que usa toda biblioteca de validación no aparecen en el cuerpo de ninguna RFC: salen de una errata verificada contra RFC 3696 que los deduce del límite de 256 octetos de un forward-path menos los dos ángulos que una ruta está obligada a llevar alrededor de la dirección. Una errata anterior decía 256 y se corrigió exactamente en esos dos caracteres. Sigue la aritmética un paso más y sale algo curioso: 64 más uno más 255 son 320, holgadamente por encima de 254, así que los dos máximos parciales no pueden alcanzarse nunca a la vez en una dirección real.

Aquí las longitudes se cuentan en octetos y no en caracteres, porque es lo que dice la RFC. Para una dirección ASCII corriente son el mismo número, pero un carácter acentuado ocupa dos bytes y un emoji cuatro, así que una dirección de aspecto corto puede ser más larga en el cable de lo que parece en pantalla.

Las dos normas implementadas aquí son solo ASCII, y eso es una limitación real y no un descuido. Las direcciones internacionalizadas —con caracteres no ASCII antes o después de la arroba— las definen especificaciones posteriores, y el soporte entre programas de correo es lo bastante desigual como para que darlas por válidas sin más fuese otra forma de mentir. Cuando aparece una, la herramienta dice qué carácter la provocó en vez de fallar en silencio.

Algo que esta herramienta no hace a propósito es adivinar erratas. Sugerir que gmial.com quería ser gmail.com exige una lista de proveedores populares, y una lista así es una foto fija que envejece sin avisar y acaba corrigiendo a quien de verdad usa un dominio más pequeño.

¿Por qué es gratis?

Porque no cuesta nada mantenerlo. Las dos normas están implementadas en tu navegador, así que las direcciones que pegas no salen de tu máquina, lo cual importa aquí más que en casi cualquier otra página: una lista de correo es justo lo que no conviene subir al servidor de un desconocido para que la revise.

No hay cuenta, no hay tope de cuántas direcciones puedes comprobar de una vez y no hay nada reservado para un plan de pago. La implementación se contrasta con un analizador real de RFC 5322 y no con expectativas escritas a mano, y con la propia expresión regular publicada por la norma HTML, así que los veredictos de esta página son de los que se pueden defender.