Preguntas frecuentes

La verificación de emails encuentra las direcciones que rebotarían antes de que les envíes nada. Importa porque una tasa de rebote alta daña tu reputación de remitente y empuja el resto de tus correos hacia el spam. Técnicamente, consiste en establecer si una dirección puede recibir correo realmente, sin enviarle nada. Una comprobación inspecciona la sintaxis de la dirección, confirma que el dominio existe y publica registros MX, abre una conversación con el servidor de correo receptor y le pregunta si aceptaría un mensaje para ese buzón. El resultado es un veredicto, no una garantía, porque algunos servidores receptores se niegan deliberadamente a responder a esa pregunta.

Los proveedores de correo como Gmail y Outlook vigilan qué parte de tus correos rebota. Enviar a direcciones que no existen les indica una lista antigua, comprada o mal recopilada, hábitos típicos de spammers, y empiezan a confiar menos en tu dominio. Menos confianza significa más correos filtrados a spam, incluidos los que van a clientes reales y activos. El daño recae en tu dominio y tu IP de envío, no en las direcciones malas, por eso un solo envío descuidado puede afectar a todo lo que envíes después.

Normalmente tres cosas, más o menos en este orden. Los proveedores de correo retrasan tus mensajes o los mandan a spam. Tu plataforma de email lo nota, porque una tasa de rebote alta pone en riesgo su propia reputación compartida, y puede revisar, limitar o pausar tu cuenta hasta que limpies la lista. Después, recuperarse lleva tiempo: un dominio dañado tiene que recuperar la confianza con envíos limpios y constantes durante semanas, y algunos equipos se rinden y pasan a un dominio nuevo. Verificar antes de enviar sale mucho más barato que cualquiera de esos pasos.

En la práctica ambas palabras se usan para lo mismo, y todos los proveedores del sector las emplean indistintamente. Cuando se hace una distinción, validación significa comprobar que una dirección está bien formada y que su dominio es real, mientras que verificación añade la comprobación a nivel de buzón contra el servidor receptor. BounceIntel hace las dos cosas en una sola llamada y te dice qué etapa produjo el veredicto.

No. La comprobación se detiene antes de la entrega. Abre una conversación SMTP con el servidor receptor, pregunta si aceptaría un mensaje para esa dirección y cierra la conexión antes de transmitir ningún cuerpo de mensaje. El titular del buzón no ve nada ni recibe nada.

Para buzones normales en los grandes proveedores, una verificación es fiable y el veredicto se puede seguir. La precisión se degrada en dos situaciones concretas y conocidas: los dominios catch-all, que aceptan correo para todas las direcciones y por tanto no permiten confirmar una en particular, y los servidores que aplican greylisting o se niegan de otro modo a responder al tráfico de verificación. Informamos de ambos como veredictos propios en lugar de disolverlos en un porcentaje. No publicamos una cifra de precisión destacada, porque ninguna cifra del sector es verificable de forma independiente, y un número que no puedes comprobar no es un dato.

Los datos de contacto se degradan de forma continua, así que la respuesta útil es una periodicidad y no una operación única. Verifica en el punto de captura para que no entre nada malo, y vuelve a verificar cualquier segmento antes de escribirle si lleva dormido más de unos meses. Una lista que lleva un año sin verificarse debe tratarse como desconocida hasta que se compruebe.

No, y cualquier proveedor que lo prometa está describiendo algo que no se puede construir. Un buzón puede cerrarse entre el momento en que lo verificas y el momento en que envías. Un buzón lleno puede rechazar un mensaje una hora después de aceptar una verificación. La verificación retira las direcciones que nunca iban a funcionar, que son la gran mayoría de los rebotes evitables, y te dice cuáles de las restantes son inciertas.

Entregable significa que el buzón existe y acepta correo: envía. De riesgo significa que la dirección es real pero algo aconseja cautela, por ejemplo una cuenta genérica o un dominio catch-all: envía con criterio. No entregable significa que la dirección rebotará: no envíes. Desconocido significa que el servidor receptor no quiso dar una respuesta, lo cual es información sobre el servidor y no sobre la dirección.

El veredicto es la respuesta categórica y la puntuación la graduada. Dos direcciones pueden ser ambas entregables siendo una un buzón antiguo en un gran proveedor y la otra una cuenta recién creada en un dominio oscuro. La puntuación recoge esa diferencia para que fijes tu propio umbral en lugar de aceptar el nuestro. La acompaña un nivel de confianza que indica sobre cuánta evidencia se apoya.

Un código de motivo nombra el hallazgo concreto que produjo el veredicto, y es lo bastante estable como para ramificar sobre él en código. Esa es la diferencia entre un resultado accionable y un número que hay que creerse. Si se suprime una dirección, el código de motivo dice si lo decidió la sintaxis, el dominio, el buzón o la reputación del proveedor, lo que permite explicar una decisión a un compañero, a un cliente o a un auditor meses después.

Desconocido significa que el servidor receptor declinó responder, no que la dirección sea mala. Algunos servidores aplican greylisting a conexiones desconocidas y aplazan todo en el primer contacto. Otros limitan o rechazan el tráfico de verificación por política. Otros simplemente están inalcanzables en el momento de la comprobación. Tratar desconocido como no entregable equivale a tirar direcciones buenas, y por eso es un veredicto aparte y no un caso fundido en otro.

Un dominio catch-all está configurado para aceptar correo dirigido a cualquier cosa en ese dominio, exista o no el buzón, así que el servidor responde que sí a cualquier pregunta. Ningún verificador puede demostrar que hay un buzón concreto detrás de un catch-all, y quien afirme lo contrario está adivinando. Devolvemos la dirección como de riesgo con el motivo catch-all adjunto, para que decidas por segmento: a menudo el riesgo compensa en una lista caliente, y rara vez en prospección en frío con un dominio de envío joven.

Una dirección genérica pertenece a una función y no a una persona: info, soporte, ventas, admin, facturación. Suele ser entregable, por lo que no se marca como inválida, pero a menudo la leen varias personas o ninguna, y es más propensa a generar una queja en correo de marketing. Se señala en lugar de retirarse porque la respuesta correcta depende de lo que envíes. Consérvalas para correo transaccional y de soporte, y piénsatelo dos veces antes de incluirlas en una campaña.

Una trampa de spam es una dirección que existe solo para identificar a quien no mantiene sus listas. Las trampas prístinas nunca fueron direcciones válidas; las recicladas son buzones abandonados que el proveedor reactiva. Nadie puede identificar una trampa con certeza desde fuera, y cualquier proveedor que afirme tener un detector definitivo está exagerando. Lo que hace la verificación es eliminar las condiciones en las que viven las trampas: direcciones mucho tiempo dormidas, direcciones que ya no resuelven y listas sin comprobar durante años.

Un rebote duro es permanente: la dirección no existe o el dominio no acepta correo. Cuenta en contra de tu reputación de remitente y la dirección debe suprimirse de inmediato. Un rebote blando es temporal: un buzón lleno, un servidor caído, un mensaje demasiado grande. La verificación apunta a los rebotes duros, porque son los únicos a la vez predecibles de antemano y dañinos cuando ocurren.

Cuatro etapas, en orden, que se detienen en cuanto la respuesta es segura. La sintaxis, que rechaza direcciones mal formadas sin ningún tráfico de red. El DNS y los MX, que confirman que el dominio existe y publica un servidor de correo. La conversación SMTP con ese servidor, donde se comprueba el buzón en sí. Y un conjunto de señales de clasificación: si el dominio es desechable, si la dirección es genérica, si el buzón está desactivado o lleno, y qué proveedor hay detrás.

Muy por debajo del segundo en el caso habitual, lo bastante rápida para ir dentro del manejador de un formulario de registro. La variable es el servidor receptor: algunos responden al instante y otros retrasan deliberadamente las conexiones desconocidas. Fija un tiempo máximo adecuado a tu formulario y decide de antemano la alternativa. La mayoría de los equipos acepta la dirección y la marca en vez de bloquear un registro por una consulta externa lenta.

Sí. La respuesta nombra el proveedor, por ejemplo Google Workspace o Microsoft 365, junto con el grado de certeza de esa identificación. Es útil más allá de la curiosidad: el proveedor es una de las entradas de la puntuación, y te dice cuáles de tus destinatarios están detrás de los sistemas de reputación que más pesan en la entregabilidad.

Sí, en cada comprobación, como una marca en la respuesta y no como un producto aparte. Mantener tu propia lista de dominios desechables es una carrera perdida porque aparecen nuevos más rápido de lo que nadie puede añadirlos, que es exactamente por lo que esto pertenece a una consulta y no a tu base de código.

Sube un CSV en el panel, o envía las direcciones al endpoint masivo y consulta el resultado. En ambos casos el trabajo se ejecuta de forma asíncrona, así que nada tiene que mantener una conexión abierta, y el progreso es legible mientras corre. Los resultados vuelven con la misma estructura por dirección que una comprobación individual, así que lo que construiste para una sirve para la otra.

Lo bastante como para que el límite práctico sea tu saldo de créditos y no el trabajo en sí. Las listas muy grandes conviene enviarlas en varios trabajos, para empezar a actuar sobre los primeros resultados mientras corre el resto y para que un reintento no lo reinicie todo.

Los resultados están disponibles en JSON desde la API y como archivo descargable desde el panel. El archivo tiene un conjunto fijo de columnas de resultado vinculadas a la dirección, no tus filas originales, para que se importe siempre igual; crúzalo con tu propio sistema usando la columna de la dirección. También hay un informe resumen para compartir con quien quiera la forma de la lista y no sus filas.

No si subes la lista desde el panel: las direcciones repetidas se agrupan antes de empezar, así que cada una se verifica y se cobra una sola vez. Un trabajo enviado por la API se cobra por cada dirección de la petición, así que deduplica antes de enviarlo. En cualquier caso, es buena costumbre en listas montadas desde varias fuentes, donde los duplicados son frecuentes e inflan el tamaño aparente de la lista.

Sí, y es la forma principal de usar el producto. Un endpoint REST verifica una dirección individual, otro envía y consulta trabajos masivos, y ambos se autentican con un token bearer. La documentación incluye ejemplos de petición y respuesta para cada endpoint más un entorno de pruebas que puedes llamar en vivo desde la página.

La documentación muestra cURL, TypeScript, Python y Go, todos como llamadas HTTP planas sin necesidad de SDK. Es deliberado: la API es lo bastante pequeña como para que un SDK añadiera una dependencia sin quitar trabajo, y una llamada fetch se lee y se comprueba en cualquier lenguaje.

Los errores vuelven con un código estable legible por máquina junto al estado HTTP, para que la lógica de reintento ramifique sobre el código en lugar de analizar un mensaje. Un límite de tasa y un saldo de créditos agotado devuelven ambos 429 pero con códigos distintos, porque uno merece un reintento tras una pausa y el otro no. La documentación lista cada código y la acción que pide.

Sí. La documentación incluye un entorno de pruebas en vivo que lanza peticiones reales contra la API real, así que puedes ver la forma de una respuesta auténtica antes de escribir código.

Puedes tener varias claves a la vez y revocar cualquiera de ellas de forma independiente, que es lo que hace falta para separar staging de producción, o para dar a un colaborador externo una clave que puedas retirar sin rotar todo lo demás.

Un crédito verifica una dirección, venga de la API, de una carga masiva o del panel. Los créditos se compran en planes mensuales o en paquetes de pago por uso, y el precio por crédito baja según sube el volumen. No hay cargo aparte por la API, ni tarifa por usuario, ni contrato mínimo.

Una comprobación que llega al servidor receptor consume un crédito sea cual sea la respuesta, desconocido incluido, porque el trabajo se hizo y el resultado es información genuina sobre ese servidor. Una petición que falla antes de que ocurra ninguna verificación, por ejemplo una petición mal formada, no lo consume.

La API devuelve 429 con un código de cuota distinto del código de límite de tasa, para que tu integración distinga entre esperar y recargar. No se borra nada ni se pierde ningún trabajo: añade créditos y el mismo trabajo continúa.

Los créditos de pago por uso se quedan en la cuenta. Los créditos de plan se renuevan con el ciclo del plan. La página de precios expone las condiciones de cada plan de forma explícita y no en una nota al pie, porque los créditos que caducan son la sorpresa desagradable más común del sector.

Se emite factura por cada pago y está disponible en el área de facturación. Para condiciones anuales, volúmenes mayores o requisitos de compras, escríbenos y presupuestaremos sobre tu volumen real en lugar de empujarte al tramo publicado más cercano.

Las cuentas nuevas empiezan con una dotación de créditos para que puedas verificar una muestra real de tus propios datos antes de decidir. No hace falta tarjeta para usarla.

Se procesan para producir el veredicto que pediste, y para nada más. Tus direcciones no se venden, no se comparten, no se añaden a ninguna lista y no se usan para construir una base de datos que se revenda a nadie. La política de privacidad lo detalla y el acuerdo de tratamiento de datos lo convierte en contractual.

Los resultados de verificación se guardan mientras los necesites disponibles en tu cuenta, y los datos de un trabajo masivo pueden borrarse desde el panel en cuanto has descargado los resultados. Los plazos de conservación se detallan en la política de privacidad.

Sí. Hay una página de RGPD que describe cómo se aplica el reglamento específicamente a la verificación de emails, un acuerdo de tratamiento de datos disponible para todos los clientes y una lista publicada de los subencargados implicados en la prestación del servicio. Los tres están enlazados desde el pie de todas las páginas.

La plataforma de verificación y su base de datos están alojadas en la Unión Europea. Unos pocos servicios de apoyo, entre ellos pagos y correo transaccional, operan en parte fuera; la página de subencargados nombra a cada tercero, dice qué hace cada uno y dónde está, para que puedas completar tu evaluación de proveedores sin tener que preguntar.

Las claves de API se muestran una sola vez y se almacenan con hash, así que una clave no puede recuperarse desde nuestro lado, solo sustituirse. Cada clave se puede revocar por separado. El acceso a los sistemas de producción se limita a quien lo necesita, y los controles de seguridad que aplicamos se describen en las páginas legales en lugar de presentarse como distintivos.

Escribe directamente a soporte. No hay cola de tickets que atravesar ni nivel que haya que comprar antes de que responda una persona. Incluye la dirección o el identificador del trabajo por el que preguntas y la respuesta será concreta en lugar de genérica.

Sí. El volumen se agrupa en la cuenta, que es lo que hace que merezca la pena para una agencia o un equipo que lleva varios clientes: un saldo, un precio, claves separadas.

Sí, desde los ajustes de la cuenta, y el borrado se confirma en lugar de ejecutarse en silencio. Elimina la cuenta y los datos asociados, con la única salvedad de los registros que estamos legalmente obligados a conservar, que la política de privacidad enumera.

El sitio y la interfaz del producto están disponibles en inglés, francés, español, italiano y alemán. El soporte se atiende en inglés.