Guías
Cómo validar direcciones en un formulario de registro
Compruebe el formato en el navegador, verifique la dirección desde el servidor y confirme el control del buzón antes de conceder accesos que dependan de él. Distinga la incertidumbre de los errores claros.
Qué hacer con cada respuesta
Los mismos cuatro resultados siempre. La instrucción cambia con la situación, porque con ella cambia lo que cuesta equivocarse.
| Resultado | Qué hacer aquí |
|---|---|
| Entregable | Continúe el registro. Si el acceso o la recuperación de la cuenta dependen del buzón, pida confirmación: un resultado entregable no demuestra quién lo controla. |
| Con riesgo | Lea la acción y los motivos devueltos. Un dominio catch-all o una dirección genérica pueden ser legítimos. Continúe con confirmación cuando corresponda; aplique una regla aparte para direcciones desechables si lo exige su política de pruebas gratuitas. |
| No entregable | Pida una corrección antes de terminar un registro que dependa del correo. Explique el problema de la dirección y conserve el valor escrito para que la persona pueda editarlo. |
| Desconocido | Permita seguir con confirmación del buzón. No hay una respuesta clara; eso no demuestra que la dirección sea inválida. Compruébela después si el flujo lo necesita. |
Empiece por el formato en el navegador
Use un campo de correo con una etiqueta visible y explique los errores junto al campo. El navegador puede detectar la falta de @ o un dominio incompleto, pero no la existencia de un buzón. Conserve el valor escrito para que corregirlo solo requiera una edición.
Valide al enviar. Si también comprueba cuando la persona sale del campo, evite llamadas a la API en cada pulsación. Si cambia el valor, descarte el resultado de la dirección anterior: una respuesta tardía no debe marcar como inválida una dirección ya corregida.
Tome la decisión en el servidor
El endpoint de registro envía la dirección a POST /v1/verifications con una credencial bearer guardada en el servidor. Repita allí las comprobaciones de entrada necesarias, porque un cliente puede omitir la validación del navegador. La página de la API de verificación de correo explica la petición y la respuesta completa.
Lea juntos status, action y reason_codes. Las acciones son allow, allow_with_email_confirmation y reject. La tabla anterior propone una política de registro; no establece una relación fija entre estado y acción.
Proponga la corrección sin cambiar la dirección
INVALID_SYNTAX y DNS_NXDOMAIN pueden explicar un problema claro de formato o dominio. LIKELY_DOMAIN_TYPO señala una posible corrección. Muestre la propuesta junto a la dirección escrita y deje que la persona la acepte o conserve el original. Un dominio poco habitual puede ser intencionado.
Después de corregir, verifique la dirección nueva y asocie el resultado a ese valor. No cambie el dominio sin avisar, no elimine etiquetas con signo más ni trate una dirección genérica como una errata.
Gestione las comprobaciones pendientes y los errores
Una verificación completa puede devolver pending con id y retry_after_ms. Espere el intervalo y consulte GET /v1/verifications/{id} con la misma credencial. Repita solo mientras siga pendiente y ponga un límite de espera al formulario. No hay callbacks.
Cuando se agote el plazo, aplique su regla alternativa, como continuar con confirmación y terminar la comprobación después. No presente ese tiempo agotado como un resultado unknown de la API ni como una dirección inválida. Los errores HTTP también describen un problema de la petición o del servicio, no un veredicto sobre la dirección. La página de verificación en tiempo real explica la espera.
Confirme el control del buzón
Emvero no envía un correo de confirmación. Una comprobación SMTP completa se detiene antes de enviar el mensaje; incluso una respuesta positiva del servidor no prueba que quien se registra controle el buzón. Envíe su propia confirmación cuando el acceso o la recuperación dependan de ese control y haga cumplir la condición en el servidor.
Para prevenir abusos, añada controles adecuados a las cuentas repetidas y los bots. DISPOSABLE_DOMAIN puede orientar su política de correo, pero no demuestra fraude. La guía sobre abuso de pruebas gratuitas trata esa decisión.
Reason codes que deciden algo aquí
Estos códigos forman parte del vocabulario de la API y explican una comprobación. Las notas también indican qué valores no devuelve la política de verificación o el sondeo actual.
INVALID_SYNTAX | La dirección no está bien formada |
LIKELY_DOMAIN_TYPO | El dominio parece una errata |
DNS_NXDOMAIN | El dominio no existe |
DISPOSABLE_DOMAIN | Proveedor de direcciones desechables |
Términos que conviene conocer antes
Sintaxis de una dirección
Reglas de formato comprobadas antes de consultar la red. Un formato válido no demuestra que funcionen el dominio o el buzón.
Dirección de correo desechable
Una dirección de un proveedor de correo temporal. La señal del dominio informa sobre la duración de uso y sirve para aplicar reglas; no demuestra un fallo de entrega.
Greylisting
Una negativa SMTP temporal pide al remitente que vuelva a intentarlo. Un intento posterior puede aportar más evidencia.
La decisión que hay detrás
Pruébelo con una dirección que ya conozca.
El verificador gratuito devuelve el resultado completo: cada etapa, cada reason code, sin ocultar nada.