Detecta correos de registro desechables, mal escritos o sin servidor de correo

Dale a tu formulario de registro una comprobación temprana de cada dirección: sintaxis, dominios desechables/temporales conocidos, si el dominio tiene siquiera un servidor de correo, erratas probables y direcciones de rol, devuelta como un veredicto accept, review o reject con sus motivos. Llama a POST /v1/email/validate desde el propio JavaScript de tu formulario, o verifica listas de forma masiva desde tu backend o el panel.

Lee la referencia de verificación de correo Consulta el flujo de prevención de abuso en registros →

Solicitud y autenticación

Envía un cuerpo JSON { "email": "user@example.com" } a POST /v1/email/validate con una clave publicable restringida por origen en la cabecera X-Api-Key: el mismo tipo de clave y el mismo modelo de orígenes permitidos que GET /v1/geo, así que es seguro llamarlo directamente desde un formulario de registro mientras el visitante escribe o al enviarlo. En el servidor, tu clave secreta desbloquea POST /v1/email/batch (hasta 100 direcciones por solicitud), los trabajos de lista asíncronos de hasta 100.000 direcciones (API o la página Email lists del panel, con CSV de entrada y de salida) y POST /v1/signup/check, que combina la verificación de correo con los indicadores de red de la IP que se registra en una sola puntuación.

Lee el veredicto y después los motivos

verdict es el resultado más grave: reject para sintaxis no válida, un dominio que no existe, un dominio sin servidor de correo o un dominio desechable; review para una errata sospechada, una dirección de rol como info@, un dominio con solo un servidor de correo implícito o una consulta DNS que no se completó; en otro caso, accept. reasons enumera cada condición que se cumplió, para que tu formulario pueda mostrar un mensaje concreto; y cuando didYouMean tiene valor, ofrece la corrección en lugar de un error.

Cuándo llamarlo

Llámalo al salir del campo o al enviar, no en cada pulsación: verificar una dirección todavía incompleta con cada carácter añade solicitudes sin aportar una señal útil y puede hacer parpadear un mensaje de error mientras el visitante aún escribe. Cada llamada cuenta como una solicitud.

Si la solicitud falla

Falla en abierto: deja que el registro continúe si la solicitud de red falla o agota el tiempo, en lugar de bloquear a todos los visitantes por una caída del lado del cliente. En el servidor, una consulta DNS que falla se indica con el motivo dns_unavailable (veredicto review), nunca como error ni como reject. Conserva lo que el visitante ya escribió para que una verificación fallida nunca le haga perder lo introducido.

Cómo se detectan los dominios desechables

Los dominios desechables/temporales conocidos se combinan a partir de tres listas de código abierto mantenidas por la comunidad (consulta fuentes de datos), actualizadas cada pocas horas, con una lista de permitidos para que una entrada errónea de origen nunca pueda marcar a un proveedor importante. También coinciden los subdominios de un dominio de la lista. Los nuevos dominios desechables que aún no figuran en ninguna lista suelen detectarse por su servidor de correo: los servicios desechables apuntan muchos dominios a los mismos pocos hosts de correo, y un dominio cuyo servidor de correo se sabe que atiende dominios de las listas se marca con disposableSource: mx_host. Un proveedor muy reciente en un servidor de correo nuevo puede no marcarse todavía.

Uso y cuota

Cada dirección verificada cuenta como una solicitud contra el límite mensual compartido de tu plan (una verificación individual, cada dirección de un lote, cada dirección distinta de un trabajo de lista), junto con el resto de tu tráfico y con el mismo límite de tasa por minuto. No hay un plan ni un precio de correo aparte. El límite de tasa por minuto cuenta llamadas HTTP, no elementos: un lote de hasta 100 IP o direcciones de correo cuenta como una sola solicitud, mientras que cada elemento sigue contando por separado en el límite mensual de solicitudes.

Lo que esto no verifica

Cada comprobación es a nivel de dominio o de dirección. Watch-IP nunca contacta con el servidor de correo del destinatario, así que un resultado no establece que el buzón exista, que el correo vaya a llegar ni que pertenezca a la persona que se registra. Un veredicto accept significa «no se encontró ningún problema», no una dirección cuyo funcionamiento esté confirmado; para eso, usa un correo de confirmación.

Campos de respuesta

syntaxValid: Si la dirección es sintácticamente válida.
isDisposable: Si el dominio coincide con un proveedor desechable/temporal conocido, directamente, a través de un dominio padre o a través de su servidor de correo. Siempre false cuando syntaxValid es false.
disposableSource: list, parent_domain o mx_host: por qué isDisposable es true; null en otro caso.
mx: El estado del servidor de correo del dominio (found, implicit, none, null_mx, no_domain o unknown) y su host MX principal.
didYouMean: Una corrección probable de errata, como gmial.com → gmail.com, o null.
isRoleAccount / isFreeProvider: Indicadores de dirección de rol (admin@, info@, noreply@…) y de proveedor de correo de consumo. El de proveedor gratuito es solo informativo.
normalizedEmail / canonicalEmail: La dirección en minúsculas y la misma sin +tags (ni puntos de Gmail) para detectar cuentas duplicadas.
verdict / reasons: accept, review o reject, más cada código de motivo que se cumplió; consulta la referencia para ver la lista completa.

Actúa según el veredicto

JavaScript del formulario de registro

async function checkEmail(email) {
  const response = await fetch('https://api.watch-ip.com/v1/email/validate', {
    method: 'POST',
    headers: { 'X-Api-Key': 'YOUR_PUBLISHABLE_KEY', 'Content-Type': 'application/json' },
    body: JSON.stringify({ email }),
  });
  if (!response.ok) return { state: 'unknown' }; // falla en abierto: no bloquees el registro por un error de red

  const result = await response.json();
  if (result.didYouMean) return { state: 'suggest', suggestion: result.didYouMean };
  if (result.verdict === 'reject') return { state: 'reject', reasons: result.reasons };
  return { state: 'ok' }; // accept o review: deja pasar el registro y márcalo en tu backend
}

Muestra un mensaje distinto por motivo (invalid_syntax, disposable_domain y no_mail_server requieren acciones correctivas diferentes por parte del visitante) y ofrece didYouMean como corrección con un clic.

Preguntas frecuentes

¿Verifica que el buzón exista?

No. Comprueba la sintaxis, las listas y los registros DNS de servidor de correo del dominio, y la forma de la dirección. Nunca contacta con el servidor de correo ni confirma que el buzón concreto sea real: un reject por no_mail_server se refiere a todo el dominio.

¿Un accept demuestra que el correo funciona?

No. accept significa que ninguna comprobación encontró un problema, no que la dirección vaya a recibir correo con seguridad ni que pertenezca a la persona que se registra. Usa un correo de confirmación cuando lo necesites.

¿Pueden los usuarios eludir la validación del navegador?

Sí. Cualquier comprobación en el navegador, incluida esta, se puede eludir desactivando JavaScript o llamando directamente a tu endpoint de registro. Aplica en tu backend cualquier decisión que importe: POST /v1/signup/check está pensado para eso.

¿Puedo limpiar una lista existente?

Sí. Sube un CSV en la página Email lists del panel, o envía hasta 100.000 direcciones a POST /v1/email/jobs con tu clave secreta, y luego descarga un CSV de resultados con un veredicto y motivos por fila. Los duplicados se cobran una vez, y las subidas y los resultados se eliminan a los 7 días.

¿Cómo se cuentan las solicitudes?

Una solicitud por dirección verificada, contra el límite mensual compartido de tu plan. Los duplicados dentro de un trabajo de lista cuentan una vez; una verificación de registro cuenta como una solicitud.