La validación de correo electrónico en tiempo real comprueba una dirección mientras el usuario aún está en tu formulario. Se ejecuta en los pocos cientos de milisegundos entre «Enviar» y la siguiente pantalla, y responde a una pregunta: ¿debería esta dirección entrar en tu base de datos? Una API de validación de correo electrónico en tiempo real toma esa decisión por ti. Comprueba la sintaxis, el dominio y sus registros MX, las señales de direcciones desechables y de rol, el comportamiento catch-all y, cuando se lo solicitas, el propio buzón. Después devuelve un resultado estructurado que tu código puede utilizar.
Esta guía está dirigida a desarrolladores que están añadiendo ese filtro a un formulario de registro, pago o captación de leads. Explica qué hacen las comprobaciones, cómo llamar a una API, cómo convertir cada estado en una decisión de producto y cómo mantener la rapidez cuando un servidor de correo responde lentamente. Los ejemplos utilizan la API de validación de correo electrónico de BillionVerify, pero las recomendaciones de diseño se aplican a cualquier proveedor.
¿Qué es la validación de correo electrónico en tiempo real?
La validación de correo electrónico en tiempo real es una comprobación que se ejecuta en el momento en que se introduce una dirección, no días después, cuando se envía una campaña. El usuario escribe una dirección. Tu frontend o backend la envía a una API de verificación de correo electrónico. La API responde con un estado como valid, invalid o catchall, además de las señales que lo respaldan. Luego, tu aplicación permite el registro, lo bloquea o pide al usuario que corrija un error tipográfico.
La clave es el momento. Un error tipográfico como gmial.com no cuesta nada corregirlo mientras el usuario todavía está en el formulario. Después de que el correo electrónico de bienvenida rebota, el mismo error tipográfico te cuesta el cliente. Las direcciones incorrectas también perjudican tu reputación del remitente, porque cada rebote permanente indica a los proveedores de buzones que envías mensajes a direcciones no confirmadas. La verificación de correo electrónico en tiempo real las detiene en la entrada.
También ayuda contra el fraude: una comprobación en tiempo real puede marcar una bandeja de entrada desechable antes de que exista la cuenta.
Validación de correo electrónico en tiempo real vs. masiva
Ambos enfoques utilizan las mismas comprobaciones. Se diferencian en cuándo se ejecutan y cuánto tiempo tienen.
- La validación en tiempo real se ejecuta en una dirección a la vez, dentro de una solicitud del usuario. Tiene un límite de tiempo estricto, a menudo muy inferior a un segundo, porque un formulario lento hace perder registros. Evita que los datos incorrectos entren.
- La validación masiva se ejecuta en una lista completa, en segundo plano. Puede tardar minutos u horas, y nadie está esperando frente a una pantalla. Limpia los datos que ya están en tu sistema, por ejemplo, antes de una gran campaña o después de importar un CRM.
La mayoría de los equipos necesitan ambas. Las comprobaciones en tiempo real mantienen limpios los datos nuevos, y una verificación masiva periódica detecta las direcciones que se volvieron inválidas con el tiempo, como las de empleados que dejaron una empresa. Para una comparación más profunda, consulta validación de correo electrónico en tiempo real vs. masiva.
Qué comprueba realmente una verificación en tiempo real
Una API de validación de correo electrónico ejecuta una serie de comprobaciones, de las más económicas a las más costosas. Cada una descarta un tipo diferente de dirección incorrecta.
Sintaxis
La primera comprobación es el formato. ¿Hay exactamente un @? ¿La parte local está formada por caracteres permitidos? ¿El dominio parece un dominio? La sintaxis rechaza errores evidentes, como john@@example o jane.example.com. Es rápida y no necesita una llamada de red. Sin embargo, una sintaxis perfecta no dice nada sobre si el buzón existe.
Registros de dominio y MX
A continuación, la API busca el dominio en DNS. Un dominio sin registros MX no puede recibir correo electrónico, por lo que una dirección allí es inútil por muy correcta que parezca. Esto detecta dominios mal escritos y dominios de empresas inactivos. BillionVerify devuelve los hosts MX encontrados en mx_records, y domain_suggestion puede incluir una corrección probable cuando el dominio parece un error tipográfico de uno común.
Señales de proveedores desechables, de rol y gratuitos
Algunas direcciones existen, pero siguen siendo poco adecuadas para tu producto:
- Las direcciones desechables proceden de servicios de bandejas de entrada temporales y normalmente dejan de funcionar en cuestión de horas. Consulta cómo funciona la detección de correos electrónicos desechables.
- Las direcciones de rol, como
info@osupport@, llegan a un equipo, no a una persona. Normalmente son entregables, pero tienden a generar menos interacción. - Las direcciones de proveedores gratuitos, como Gmail, son normales para los consumidores, pero conviene registrarlas en un formulario B2B.
La API informa de estas señales mediante indicadores (is_disposable, is_role, is_free) para que puedas decidir según el producto.
Dominios catch-all
Algunos servidores de correo aceptan mensajes para cualquier dirección de su dominio, exista o no. En estos dominios catch-all, una comprobación del buzón no puede demostrar que exista una bandeja de entrada específica. Un resultado catch-all no es un resultado negativo. Significa que hay menos certeza, por lo que la puntuación importa más que la etiqueta. La detección de correos electrónicos catch-all explica cómo funciona y por qué es importante.
Comprobación del buzón mediante SMTP
La comprobación más profunda pregunta al servidor de correo del destinatario mediante SMTP si aceptaría un mensaje, sin enviar ninguno. Encuentra direcciones en dominios reales que ya no existen, como el buzón de un antiguo empleado. También es el paso más lento, porque depende del servidor de otra persona. En BillionVerify se controla mediante el parámetro check_smtp. Si lo omites, la API ejecuta la comprobación SMTP; envía check_smtp: false para omitirla.
Reputación del dominio
BillionVerify también puede devolver un objeto domain_reputation con resultados de listas negras para la IP del servidor de correo del dominio. Es solo informativo: no cambia el estado, la puntuación ni el coste.
Cómo llamar a una API de validación de correo electrónico en tiempo real
Con BillionVerify, una sola comprobación en tiempo real es una solicitud HTTPS. La URL base es https://api.billionverify.com/v1, y tu clave de API va en el encabezado BV-API-KEY. Guarda esa clave en tu servidor. Nunca la incluyas en el código del navegador.
Aquí tienes una solicitud mínima, basada en la referencia de API:
curl -X POST https://api.billionverify.com/v1/verify/single \
-H "BV-API-KEY: sk_xxx" \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","check_smtp":true}'
La solicitud acepta tres parámetros:
| Parámetro | Predeterminado | Qué hace |
|---|---|---|
email | obligatorio | La dirección que se validará |
check_smtp | activado | Establece false para omitir la comprobación del buzón SMTP en tiempo real |
force_refresh | false | Omite los resultados almacenados en caché; el resultado actualizado se factura como una comprobación nueva |
Una respuesta exitosa incluye el resultado en una envoltura estándar. Este es un ejemplo abreviado para una dirección entregable:
{
"success": true,
"code": "0",
"message": "Success",
"data": {
"email": "user@example.com",
"status": "valid",
"score": 0.95,
"is_deliverable": true,
"is_disposable": false,
"is_catchall": false,
"is_role": false,
"is_free": false,
"domain": "example.com",
"mx_records": ["mail.example.com"],
"check_smtp": true,
"reason": "smtp_deliverable",
"domain_suggestion": "",
"response_time": 250,
"credits_used": 1
}
}
Si prefieres un SDK, BillionVerify publica SDK oficiales para Node.js, Python, TypeScript, Go, PHP y Java. En Node.js, npm install billionverify-sdk te proporciona un cliente con un método verify; en Python, el paquete es billionverify.
Lectura de la respuesta: estado, puntuación y motivo
El campo status es en el que se basan la mayoría de las ramas del código. Esto es lo que significa cada estado y un valor predeterminado sensato para un formulario de registro:
| Estado | Significado | Valor predeterminado del formulario de registro |
|---|---|---|
valid | El buzón existe y puede recibir correos | Aceptar |
invalid | La dirección no existe o no puede recibir correos | Bloquear y solicitar otra dirección |
disposable | Una bandeja de entrada temporal | Bloquear o aceptar con límites |
catchall | El dominio acepta cualquier dirección | Aceptar y supervisar |
role | Un buzón compartido, como info@ | Aceptar, quizá marcarla para ventas |
unknown | No se pudo confirmar la entregabilidad de correo electrónico | Aceptar y volver a comprobar más tarde |
El score te proporciona una señal más precisa entre 0 y 1. Como guía aproximada, los resultados valid obtienen una puntuación de 0.85 a 1.0, catchall de aproximadamente 0.55 a 0.75, unknown de 0.3 a 0.6, disposable de 0.1 e invalid de 0. Un resultado role conserva la puntuación de la comprobación subyacente. Puedes usar la puntuación para establecer tu propio umbral para casos límite; por ejemplo, aceptar direcciones catch-all solo por encima de cierta puntuación en un formulario de alto valor.
El campo reason explica el veredicto. Un resultado invalid puede incluir invalid_syntax, no_mx_records o mailbox_not_found, y cada uno apunta a un mensaje diferente para el usuario. Un problema de sintaxis significa «comprueba el formato». La ausencia del buzón significa «esta bandeja de entrada no existe». La página de motivos de verificación enumera todos los motivos e indica cuáles de los motivos unknown vale la pena volver a intentar.
Dos campos ayudan directamente al usuario: domain_suggestion puede mostrar una sugerencia como «¿Querías decir gmail.com?», e is_disposable explica por qué se rechazó una dirección desechable.
Diseñar el flujo de registro en torno a un presupuesto de latencia
La parte difícil es integrar la comprobación en un formulario sin ralentizarlo. Empieza con un presupuesto. Decide cuánto tiempo estás dispuesto a retener al usuario, por ejemplo, entre 300 y 500 milisegundos al enviar el formulario. Todo lo demás se deriva de ese número.
El texto del producto de BillionVerify sitúa los resultados en caché por debajo de 200 ms y una comprobación SMTP completa en 1–3 segundos de media. Esa diferencia te deja dos buenos diseños:
- Comprobación completa con tiempo de espera. Llama a la API con SMTP activado y un tiempo de espera de 2–3 segundos. La mayoría de las respuestas llegan a tiempo y te proporcionan un
validoinvalidclaro. Si se agota el tiempo de espera, permite el registro y vuelve a comprobarlo más tarde. - Comprobación rápida ahora, comprobación profunda después. Llama a la API con
check_smtp: false. Esto solo resuelve los casos claros: sintaxis incorrecta, un dominio sin registros MX y direcciones desechables y de rol. Una dirección de un dominio activo devuelveunknowncon el motivosmtp_unverifiable, lo cual es esperado. Acéptala y ejecuta después una segunda llamada con SMTP activado desde una tarea en segundo plano. Si el buzón no existe, marca la cuenta y pide al usuario que confirme su dirección.
Algunos hábitos de frontend también ayudan:
- Valida al perder el foco o al enviar el formulario, no con cada pulsación. Comprobar
j,jo,johdesperdicia llamadas y créditos. - Ejecuta primero comprobaciones locales de sintaxis para ahorrar un viaje de ida y vuelta en errores evidentes.
- Llama a la API desde tu backend. Tu servidor almacena la clave de API y registra el resultado; el navegador solo muestra el resultado.
Para consultar detalles de UX, como el texto, la ubicación de los errores y cuándo mostrar una sugerencia, visita verificación de correo electrónico durante el registro.
¿Fallo abierto o fallo cerrado? Cómo gestionar los tiempos de espera y las incertidumbres
El patrón que funciona para la mayoría de los productos es: fallar de forma cerrada ante errores claros y de forma abierta ante la incertidumbre.
- Fallar de forma cerrada significa bloquear el registro. Hazlo cuando la API indique que la dirección es claramente incorrecta:
invalidconinvalid_syntaxono_mx_records, o una direccióndisposableen un formulario donde las cuentas desechables causen problemas. - Fallar de forma abierta significa permitir el acceso al usuario y hacer un seguimiento más tarde. Hazlo cuando la respuesta sea incierta: un estado
unknown, un dominio catch-all o cuando tu propio tiempo de espera se agote antes de que responda la API.
¿Por qué no bloquear también las direcciones inciertas? Detrás de muchas de ellas hay personas reales. Los servidores de correo corporativo suelen aplicar greylisting o limitar la tasa de las comprobaciones SMTP, por lo que bloquearlas provoca registros reales perdidos. Acepta la dirección, etiqueta el registro y vuelve a comprobarlo más tarde.
Establece un tiempo de espera del lado del cliente para tu llamada a la API que coincida con tu presupuesto de latencia. Cuando se agote, trata el resultado como unknown: acepta, guarda una marca y programa una nueva comprobación en segundo plano. Reintenta los resultados unknown más tarde, no dentro de la solicitud.
Ejemplo: Validar un correo electrónico al registrarse en Node.js
El siguiente esquema muestra la comprobación rápida (diseño 2) en un controlador de registro. Utiliza el endpoint REST documentado y los campos de respuesta, un tiempo de espera y las reglas de permitir o bloquear descritas anteriormente. Adapta los nombres a tu framework.
const BLOCK = new Set(['invalid', 'disposable']);
async function checkEmail(email) {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 400);
try {
const response = await fetch('https://api.billionverify.com/v1/verify/single', {
method: 'POST',
headers: {
'BV-API-KEY': process.env.BV_API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({ email, check_smtp: false }),
signal: controller.signal,
});
const body = await response.json();
if (!body.success) return { allow: true, recheck: true };
const { status, reason, domain_suggestion } = body.data;
if (BLOCK.has(status)) {
return { allow: false, reason, suggestion: domain_suggestion };
}
return { allow: true, recheck: status === 'unknown' || status === 'catchall' };
} catch {
// Timeout or network error: fail open and re-check in the background.
return { allow: true, recheck: true };
} finally {
clearTimeout(timer);
}
}
Sin SMTP, la mayoría de las direcciones reales devuelven unknown y reciben la marca recheck. Después de guardar la cuenta, un trabajo en segundo plano llama al mismo endpoint con SMTP activado para cada registro marcado con recheck. El tutorial de Node.js explica una configuración más completa, incluido el SDK oficial. La misma solicitud funciona desde Python o cualquier lenguaje con un cliente HTTP.
Límites, almacenamiento en caché y coste
Una comprobación en tiempo real se ejecuta en tu flujo de registro, por lo que sus límites se convierten en tus límites. Planifica teniendo esto en cuenta.
Límites. BillionVerify protege su capacidad con límites por cuenta. Cuando alcanzas uno, la API devuelve HTTP 429 con el código 1003 y un encabezado Retry-After. Reduce la frecuencia y vuelve a intentarlo, y mantén activa tu propia regla de apertura ante fallos para que un límite nunca bloquee a un usuario real.
Almacenamiento en caché. Los resultados se almacenan en caché, por eso las comprobaciones repetidas responden rápidamente. Volver a comprobar una dirección que tu cuenta verificó en las últimas 24 horas es gratis. Usa force_refresh: true solo cuando realmente necesites una respuesta actualizada, porque omite la caché y se factura como una comprobación nueva.
Coste. Una comprobación individual normalmente utiliza 1 crédito, que se muestra en credits_used. Todos los resultados unknown son gratuitos, al igual que los errores de sintaxis. Valida al enviar el formulario en lugar de hacerlo con cada pulsación de tecla y no vuelvas a comprobar una dirección que hayas verificado recientemente. BillionVerify te proporciona 20 créditos gratuitos cada día que inicias sesión, hasta 600 al mes, suficientes para crear y probar una integración. Los paquetes de créditos de pago aparecen en la página de precios.
Más allá del formulario: lotes, archivos y webhooks
La validación en tiempo real cubre las nuevas direcciones una por una. Para todo lo demás, la misma API ofrece otros puntos de entrada:
- Lotes pequeños.
POST /verify/bulkcomprueba hasta 50 direcciones en una sola solicitud, lo que resulta adecuado para una sincronización con un CRM o una pantalla de importación. - Listas grandes.
POST /verify/fileacepta un archivo CSV, TXT o XLSX y lo procesa en segundo plano. - Webhooks. En lugar de consultar repetidamente el estado de un trabajo de archivo, registra un webhook para los eventos
file.completedyfile.failed. Consulta la guía sobre webhooks de verificación de correo electrónico para conocer las comprobaciones de firma y los reintentos. - Comprobaciones solo de direcciones desechables.
POST /verify/disposableresponde únicamente a la pregunta sobre si la dirección es desechable y no utiliza créditos.
Una configuración habitual: comprobaciones en tiempo real en cada formulario, un lote nocturno para los registros marcados con recheck y un trabajo de archivo antes de las campañas grandes.
Lista de comprobación de validación de correo electrónico en tiempo real
Antes de publicar, repasa esta lista:
- La clave de API reside en el servidor, nunca en el navegador.
- La sintaxis se comprueba localmente antes de la llamada a la API.
- La ruta de solicitud utiliza
check_smtp: falsey un tiempo de espera que se ajusta a tu presupuesto de latencia. invalidydisposabletienen mensajes de error claros y específicos.unknown,catchally los tiempos de espera permiten el paso y se ponen en cola para volver a comprobarlos.domain_suggestionproporciona una sugerencia para corregir errores tipográficos.- Las respuestas 429 aplican un retroceso sin bloquear a los usuarios.
- Los resultados se almacenan con el registro del usuario, para que puedas medir las tasas de rebote más adelante.
Preguntas frecuentes
¿Qué es una API de validación de correo electrónico en tiempo real?
Una API de validación de correo electrónico en tiempo real comprueba una única dirección de correo electrónico mientras un usuario envía un formulario y devuelve un resultado en una fracción de segundo. Ejecuta comprobaciones de sintaxis, dominio, MX, correos desechables, roles y catch-all, y opcionalmente una comprobación del buzón mediante SMTP, para que tu aplicación pueda aceptar, bloquear o marcar la dirección antes de que llegue a tu base de datos.
¿En qué se diferencia la validación de correo electrónico en tiempo real de la validación masiva?
La validación de correo electrónico en tiempo real comprueba una dirección a la vez dentro de una solicitud del usuario y debe responder rápidamente. La validación masiva comprueba una lista completa en segundo plano y puede tardar mucho más. Usa comprobaciones en tiempo real para mantener limpios los datos nuevos y comprobaciones masivas para limpiar los datos que ya tienes.
¿Debería ejecutar la comprobación SMTP en cada registro?
Depende de tu presupuesto de latencia. La comprobación SMTP es la que confirma un buzón, por lo que, sin ella, la mayoría de las direcciones reales devuelven unknown. Si puedes esperar entre 2 y 3 segundos, ejecútala al enviar el formulario con un tiempo de espera. Si no, ejecuta la comprobación rápida con check_smtp: false y realiza la comprobación SMTP en una tarea en segundo plano.
¿Qué debo hacer con los resultados catch-all y unknown?
Acéptalos y vuelve a comprobarlos más tarde. Un dominio catch-all acepta cualquier dirección, por lo que una comprobación del buzón no puede demostrar que la bandeja de entrada existe, y un resultado unknown significa que la comprobación no pudo finalizar. Bloquear a estos usuarios hace perder registros reales; etiquetarlos y volver a comprobarlos mantiene tus datos limpios sin perjudicar la conversión.
¿Puedo llamar a la API de comprobación de correo electrónico desde el navegador?
No. Eso expone tu clave de API. Llama a la API desde tu backend y devuelve únicamente la decisión.
¿Qué tan rápida es la verificación de correo electrónico en tiempo real?
Con BillionVerify, los resultados almacenados en caché se devuelven en menos de 200 ms y una comprobación SMTP completa tarda entre 1 y 3 segundos de media. Por eso, la comprobación rápida sin SMTP debe formar parte de la ruta de la solicitud y la comprobación SMTP debe ejecutarse en segundo plano.
¿Cuánto cuesta una API de validación de correo electrónico?
En BillionVerify, una única comprobación normalmente utiliza 1 crédito, y cada resultado unknown es gratuito. Obtienes 20 créditos gratuitos cada día que inicias sesión, hasta 600 al mes, y los paquetes de créditos de pago están disponibles en la página de precios. force_refresh omite la caché y se factura como una comprobación nueva.
Empieza a validar correos electrónicos en tiempo real
La validación de correos electrónicos en tiempo real significa menos rebotes, menos cuentas falsas y menos usuarios perdidos por un error tipográfico. Haz una comprobación rápida en la ruta de solicitud, traslada la comprobación lenta al segundo plano y permite que los fallos claros bloqueen mientras los resultados inciertos pasen. Crea una cuenta gratuita de BillionVerify, obtén una clave API y realiza tu primera llamada a la API de validación de correo electrónico desde la documentación anterior.