Para validar una dirección de correo con JavaScript, usa un campo HTML <input type="email"> con required y llama a checkValidity() para elegir el mensaje que debes mostrar. Aunque el formato sea correcto, quedan por comprobar la existencia del dominio y del buzón, así como el control de este último. La referencia de MDN sobre el campo de correo explica esta limitación.
Un formulario para probar en el navegador
Guarda este ejemplo como archivo HTML y ábrelo en el navegador. Introduce una dirección y selecciona Continue o pulsa Intro. El ejemplo muestra el resultado de la comprobación del formato sin salir del navegador. Antes de usarlo para un registro, conecta el caso de éxito con un controlador propio del servidor. Las etiquetas y los mensajes en inglés son textos de ejemplo que puedes adaptar a tu interfaz.
<form id="email-form" novalidate>
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email"
required aria-describedby="email-feedback">
<p id="email-feedback" aria-live="polite"></p>
<button type="submit">Continue</button>
</form>
<script>
const form = document.querySelector("#email-form");
const email = document.querySelector("#email");
const feedback = document.querySelector("#email-feedback");
email.addEventListener("input", () => {
feedback.textContent = "";
email.removeAttribute("aria-invalid");
});
form.addEventListener("submit", (event) => {
event.preventDefault();
if (!email.checkValidity()) {
const message = email.validity.valueMissing
? "Enter an email address."
: email.validity.typeMismatch
? "Enter an address in email format."
: "Check the email address.";
feedback.textContent = message;
email.setAttribute("aria-invalid", "true");
email.focus();
return;
}
email.removeAttribute("aria-invalid");
feedback.textContent = "Format accepted. Send the address to your server.";
});
</script>
Cómo se muestran los errores
novalidate desactiva la validación automática al enviar el formulario; la llamada explícita a checkValidity() sigue funcionando. valueMissing identifica un campo obligatorio vacío y typeMismatch, un error de formato. La API de validación de restricciones de HTML define estas comprobaciones.
La etiqueta identifica el campo. Si hay un error, el código muestra un mensaje concreto, establece aria-invalid y devuelve el foco al campo. aria-describedby asocia el mensaje con el campo y aria-live="polite" permite que las tecnologías de asistencia accedan a los cambios. Al editar el valor, se borran el mensaje anterior y el estado de error para que la persona pueda volver a intentarlo. La indicación del error no depende del color.
Si los mensajes del navegador bastan para el formulario, configura un envío por POST a tu controlador del servidor. Después, quita novalidate y el controlador de envío de JavaScript. El campo HTML ya comprueba el formato; JavaScript permite decidir aquí el texto y la posición del mensaje.
Pruebas antes de conectar el servidor
Introduce los siguientes valores en el ejemplo. Los resultados corresponden a la validación de este formulario en el navegador, sin peticiones de red.
| Entrada | Resultado en el ejemplo | Qué comprobar |
|---|---|---|
| Campo vacío | Mensaje de valor obligatorio | El foco vuelve al campo y se establece aria-invalid |
alex.example.com |
Error de formato | Se detecta la ausencia de @ |
alex@example.com |
Formato aceptado | No se envía la dirección |
alex+orders@example.com |
Formato aceptado | Se conserva la parte local con la etiqueta tras + |
alex@example |
Formato aceptado | Un formato aceptado no demuestra que exista una ruta pública de correo |
alex@example.com,pat@example.org |
Error de formato | El formulario admite una sola dirección, sin multiple |
Después de un error, corrige el valor y vuelve a enviar el formulario. El mensaje anterior y aria-invalid deberían desaparecer. Prueba tanto el botón como la tecla Intro, porque ambos pueden enviar el formulario.
Los dominios son ejemplos ficticios: RFC 2606 reserva example.com y example.org para documentación. Una dirección de ejemplo aceptada no demuestra que exista un buzón real.
Cuándo conviene una expresión regular propia
En este formulario, mantén las reglas de correo del navegador y usa JavaScript para los mensajes. Una segunda expresión regular añade otra regla que habrá que mantener. Si la aplicación solo acepta direcciones de una organización concreta, documenta esa restricción como un requisito de negocio y aplícala también en el servidor.
Conserva las direcciones aceptadas al pasarlas al servidor. Quitar +orders en el caso de prueba cambiaría el valor introducido. Este ejemplo cubre una dirección según las reglas del campo del navegador. Para admitir formatos poco habituales o internacionalizados, define el alcance por separado y prueba el formulario, el analizador del servidor y el servicio de correo.
Después del formato, valida en el servidor
Envía el valor al servidor de la aplicación por la ruta habitual del formulario o de la API. Valida los datos de forma independiente: un cliente puede saltarse los controles del navegador y enviar una petición directa. La guía de MDN sobre validación de formularios explica este límite.
En el ejemplo, event.preventDefault() cancela el envío. En el punto donde se muestra el mensaje de éxito, puedes añadir la petición de tu aplicación. Comprueba la respuesta antes de avanzar. Si falla, muestra un error que permita volver a intentarlo. El mensaje local de éxito por sí solo no debe crear una cuenta ni marcar una dirección como verificada.
Tras aceptar el formato en el servidor, el siguiente paso depende de lo que necesites saber:
| Pregunta | Siguiente paso adecuado | Qué sigue sin demostrarse |
|---|---|---|
| ¿El texto tiene formato de dirección de correo? | Mensajes en el navegador y validación independiente en el servidor | Existencia del dominio o del buzón |
| ¿Puedo usar la dirección en este flujo? | Recoger desde el servidor evidencia del dominio, del enrutado y, si está disponible, del destinatario | Entrega garantizada o control del buzón |
| ¿Esta persona controla el buzón? | Enviar desde la aplicación un enlace o código de confirmación y pedir una respuesta | Identidad o entrega futura |
La comparación entre validación de sintaxis y comprobación SMTP ayuda a elegir la profundidad de la comprobación. Una verificación completa de Emvero puede recoger evidencia SMTP sobre el destinatario sin enviar un mensaje. Las restricciones del servidor o los tiempos de espera agotados pueden dejar el resultado en unknown; eso no demuestra que la dirección no pueda recibir correo. Llama a la API de verificación de correo desde el servidor para mantener las credenciales privadas.
La guía de validación del formulario de registro explica qué resultados permiten continuar y cuándo conviene pedir una confirmación.