Casos de uso

Para qué se usa realmente la verificación de emails

Ocho situaciones en las que una dirección equivocada cuesta dinero de verdad, y qué devuelve BounceIntel en cada una. Cada sección enlaza con el endpoint que la sostiene.

La respuesta corta

Verificar emails merece la pena en cualquier punto donde una dirección equivocada te cueste algo que no puedes recuperar: un dominio de envío quemado, una prueba gratuita fraudulenta, un recibo que nunca llegó, un lead que pagaste y al que nunca podrás escribir. Es un control a la entrada, no una limpieza a la salida.

La mayoría descubre la verificación de emails en el peor momento posible. Una campaña rebota con fuerza, un dominio de envío queda limitado y alguien sale a buscar un limpiador de listas. Funciona, pero es la versión menos valiosa del trabajo: el daño ya está hecho y el arreglo es puntual.

Los equipos que más partido le sacan mueven el control hacia arriba, al punto donde la dirección entra en el sistema. Verificar en la captura cuesta lo mismo por dirección y previene el problema en lugar de medirlo. Las secciones siguientes están ordenadas más o menos así, desde la puerta de entrada hacia dentro.

01Ingeniería de producto y growth

Formularios de registro y de pago

Una dirección mala que entra en tu base de datos al registrarse es un problema que pagarás muchas veces, no una.

La dirección que un usuario escribe en tu formulario de registro es aquella a la que enviarás su confirmación, su restablecimiento de contraseña y todos sus recibos. Si es una errata, no puede recuperar la cuenta y tú recibes un ticket de soporte. Si es una dirección desechable, nunca iba a leer nada de lo que le mandes. Si es una cuenta genérica o una trampa de spam, dañará tu reputación de remitente en silencio durante meses.

Una llamada de verificación en el manejador del formulario detecta los cuatro casos antes de escribir el registro. Es una sola petición, responde muy por debajo del segundo y devuelve detalle suficiente para decidir en lugar de un aprobado o suspenso a secas. Las erratas reciben una sugerencia de corrección, las desechables se bloquean y las direcciones de riesgo se aceptan pero quedan marcadas para no entrar nunca en un envío masivo.

Lo que obtienes

  • Bloquear dominios desechables en el punto de captura
  • Detectar erratas antes de encolar el correo de confirmación
  • Marcar cuentas genéricas y dominios conocidos de trampas de spam antes de guardar el registro
  • Ramificar en código sobre códigos de motivo y no sobre una puntuación única

Lo que lo sostiene

  • POST /v1/check_email
  • is_disposable
  • is_role_account
  • safe_to_send
Ver la página de producto
02Equipos de ventas y agencias outbound

Prospección en frío y desarrollo de negocio

El outbound es el único canal donde un pequeño porcentaje de direcciones malas puede llevarse por delante todo el dominio de envío.

El correo en frío se apoya en dominios sin reputación establecida, así que no hay crédito acumulado que absorba un mal envío. Los proveedores de correo leen una tasa de rebote alta en un dominio joven como una señal clara de que la lista se compró o se raspó, y la respuesta es rápida: limitación, luego carpeta de correo no deseado, luego rechazo directo. Recuperar un dominio quemado lleva semanas, y la mayoría de los equipos simplemente compra otro.

Verificar la lista antes de arrancar la secuencia es el seguro más barato del outbound. Es también donde la taxonomía de veredictos demuestra su valor. Las listas de prospección están llenas de dominios catch-all, donde ningún verificador del mundo puede demostrar que existe un buzón concreto, y una herramienta que adivina ahí o descarta buenos contactos o te alimenta de rebotes. La nuestra los devuelve como un veredicto propio con el motivo adjunto, para que decidas si ese segmento compensa el riesgo en ese dominio concreto.

Lo que obtienes

  • Verificar una lista de prospectos antes del primer envío de la secuencia
  • Ver un dominio catch-all como lo que es, y no como una moneda al aire
  • Proteger el dominio de envío en lugar de ir rotando dominios nuevos
  • Segmentar por riesgo en vez de descartar todo lo que no sea seguro

Lo que lo sostiene

  • is_catch_all
  • bounce_risk
  • provider
  • reason_codes
Ver la página de producto
03Marketing de email y ciclo de vida

Email marketing e higiene de listas

Una lista se degrada le envíes o no, y la factura llega toda de golpe.

Las listas de suscriptores se pudren a un ritmo constante. La gente cambia de trabajo, cierra cuentas y abandona direcciones, y ninguno te avisa. Una lista sin verificar en un año contiene una proporción relevante de direcciones que ya no aceptan correo, más una proporción menor y mucho más peligrosa de trampas de spam recicladas, que es exactamente lo que usan los proveedores para identificar a quien no mantiene sus listas.

Los grandes proveedores de buzones publican ya umbrales explícitos para remitentes de volumen, y la tasa de quejas que toleran es lo bastante baja como para que un solo mal envío a una lista descuidada te deje por encima. Limpiar antes de enviar es lo evidente, pero el hábito más útil es verificar de forma periódica y en el momento de la suscripción, para que la lista nunca llegue a necesitar un rescate.

Lo que obtienes

  • Limpiar una lista antes de la campaña, no después del informe de rebotes
  • Marcar direcciones en dominios conocidos de trampas de spam antes del envío
  • Mantener rebotes y quejas dentro de los umbrales para remitentes de volumen
  • Volver a verificar segmentos dormidos antes de reactivarlos, en vez de adivinar

Lo que lo sostiene

  • Carga masiva de CSV
  • is_deliverable
  • has_full_inbox
  • is_disabled
Ver la página de producto
04Equipos de RevOps y datos

Higiene del CRM y de la base de datos

Nadie nota que un CRM se está quedando obsoleto, porque cada registro por separado parece correcto.

Los datos de contacto se degradan de forma continua, y un CRM sin proceso de higiene está sustancialmente equivocado antes de que pase un año desde su última auditoría. El coste es difuso, y por eso nunca se arregla: previsiones construidas sobre cuentas que parecen contactables, secuencias que no llegan a nadie, tiempo comercial gastado en registros que podrían haberse marcado solos, e informes que exageran tu alcance en silencio.

Una verificación masiva sobre una exportación da la foto real en una sola pasada, y la API la mantiene después. Lo que importa aquí no es el veredicto sino el motivo que lo acompaña. Un buzón desactivado te dice que una persona ha dejado una empresa, lo cual es una decisión de enrutado. Un dominio que ya no publica registros MX te dice que la empresa misma ha desaparecido, lo cual es una decisión muy distinta. Ambos llegan como códigos de motivo sobre los que puede actuar un flujo de trabajo.

Lo que obtienes

  • Auditar una exportación completa del CRM en un solo trabajo masivo
  • Distinguir un contacto que se fue de una empresa que ya no existe
  • Devolver los veredictos al enrutado, la puntuación y las reglas de supresión
  • Conservar un registro auditable del motivo de cada supresión

Lo que lo sostiene

  • Carga masiva de CSV
  • mx.accepts_mail
  • smtp.is_disabled
  • reason_codes
Ver la página de producto
05Equipos de comercio electrónico y retail

Comercio electrónico y correo transaccional

Una dirección mal escrita en el pago significa que ni la confirmación del pedido ni el aviso de envío llegan a ninguna parte.

El correo transaccional es el que el cliente sí quiere recibir, y también el que con más probabilidad se manda a una dirección tecleada con prisa en un móvil. Cuando falla no hay informe de rebotes que nadie lea: solo un cliente que no sabe si su pedido se ha cursado, seguido de un contacto con soporte y a veces de una devolución de cargo.

Comprobar la dirección dentro del proceso de pago cuesta una llamada y convierte un fallo silencioso en una invitación a corregir mientras el cliente sigue en la página. La misma comprobación evita que las campañas de carrito abandonado y de recuperación se envíen a direcciones que dejaron de aceptar correo hace dos temporadas, que es de donde sale la mayor parte del volumen de rebotes de una lista de comercio electrónico.

Lo que obtienes

  • Detectar erratas del pago mientras el cliente todavía puede corregirlas
  • Asegurar que llegan confirmaciones de pedido y avisos de envío
  • Reducir el soporte de clientes que nunca recibieron su recibo
  • Verificar segmentos de recuperación antes de escribir a una lista antigua

Lo que lo sostiene

  • POST /v1/check_email
  • valid_syntax
  • smtp_is_deliverable
  • action
Ver la página de producto
06Equipos de producto SaaS

Onboarding SaaS y abuso de pruebas gratuitas

Las pruebas gratuitas y los bonos por recomendación se explotan con direcciones desechables, un buzón de usar y tirar cada vez.

Cualquier producto que regale algo en el registro es un objetivo. Los proveedores de direcciones desechables existen precisamente para que una misma persona repita una prueba gratuita, reclame un bono por recomendación una y otra vez, o vote varias veces. Bloquearlos manteniendo tu propia lista de dominios es una carrera perdida: aparecen nuevos más rápido de lo que nadie puede añadirlos.

La verificación resuelve eso como una consulta y no como una lista que mantener. También mejora los números sobre los que planificas. La activación, la retención y la conversión calculadas sobre una base de registros inflada con cuentas de usar y tirar están mal en la dirección que te favorece, y la corrección solo aparece mucho después, en unos ingresos que no cuadran con el embudo.

Lo que obtienes

  • Frenar el abuso repetido de pruebas y de bonos por recomendación en el registro
  • Sacar las cuentas efímeras de las métricas de activación y retención
  • Aplicar en código una regla más estricta a los planes de pago que a los gratuitos
  • Evitar mantener a mano una lista de bloqueo de dominios desechables

Lo que lo sostiene

  • is_disposable
  • is_b2c
  • confidence
  • safe_to_send
Ver la página de producto
07Agencias y consultoras

Agencias y proveedores de servicios

Heredas listas que no construiste, y eres tú quien responde por lo que hagan.

Una agencia que acepta un cliente hereda la lista que ese cliente ha acumulado, normalmente sin registro alguno de su procedencia. Enviar a esa lista desde el dominio del cliente, o peor aún desde una cuenta compartida de plataforma, pone en juego la posición de la propia agencia por los hábitos de recogida de datos de otra persona.

Verificar en la incorporación convierte eso en un paso documentado. Sabes qué te han entregado antes de enviar nada, puedes enseñarle al cliente el estado de su lista en términos que él puede comprobar, y los mismos códigos de motivo que te justifican una supresión se la explican a él. El volumen se agrupa entre clientes, así que una agencia pequeña compra a un precio que la lista de un solo cliente nunca alcanzaría.

Lo que obtienes

  • Auditar la lista de un cliente al incorporarlo, antes de enviar nada
  • Enseñar evidencias al cliente en lugar de una puntuación sin explicación
  • Agrupar el volumen de todas las cuentas de cliente para mejorar el precio
  • Mantener tu reputación de remitente al margen del historial de un cliente

Lo que lo sostiene

  • Carga masiva de CSV
  • Exportación de informe puntuado
  • reason_codes
  • confidence_level
Ver la página de producto
08Plataformas de datos y vendedores de listas

Proveedores de datos y plataformas

Si vendes datos de contacto, la precisión de la verificación es la calidad de tu producto, no un coste operativo.

Los vendedores de datos, las plataformas de enriquecimiento y los mercados de leads verifican de forma continua y a una escala en la que solo importan dos cosas: el precio por crédito y la fiabilidad de la API. Todo lo que va aguas abajo hereda tu precisión, lo que significa que un verificador que devuelve una puntuación sin explicar traslada un riesgo no cuantificado a tus propios clientes.

Aquí es donde una salida explicable deja de ser una preferencia. Un veredicto con códigos de motivo y un nivel de confianza puede atravesar tu pipeline, exponerse en tu propia API y defenderse ante un cliente que pregunte por qué un registro se marcó así. Un número a secas no puede. Los trabajos masivos son asíncronos y paginados, así que un lote de cualquier tamaño es un envío y una consulta, no una conexión que haya que mantener abierta.

Lo que obtienes

  • Verificar de forma continua a gran volumen, con tarifas que bajan con la escala
  • Pasar códigos de motivo y confianza aguas abajo, a tus propios clientes
  • Enviar y consultar de forma asíncrona en vez de mantener conexiones abiertas
  • Defender un veredicto ante un cliente con las señales que lo respaldan

Lo que lo sostiene

  • POST /v1/bulk
  • GET /v1/bulk/{job_id}
  • confidence
  • score
Ver la página de producto

Una comprobación, ocho umbrales

La misma comprobación bajo los ocho casos

Ninguna de las situaciones anteriores usa un producto distinto. Todas usan la misma verificación, invocada en otro momento y leída con otro umbral. Cada comprobación inspecciona la sintaxis, luego el DNS y los registros MX, luego el buzón en sí, y devuelve la misma estructura sea cual sea la vía por la que la llamaste.

Lo que cambia entre casos es cuánta exigencia aplicas. Un formulario de pago debería aceptar todo lo que probablemente sea real y sugerir una corrección en lo que probablemente sea una errata. Una lista de prospección en frío debería recibir solo lo que es seguro. Como la respuesta lleva el razonamiento y no solo el veredicto, ambas reglas son unas pocas líneas de código contra el mismo endpoint.

  • 01Un veredicto de accesibilidad: entregable, de riesgo, no entregable o desconocido
  • 02Una puntuación de entregabilidad de 0 a 100, con un nivel de confianza adjunto
  • 03Códigos de motivo que nombran qué decidió el veredicto, seguros para usar en código
  • 04Una acción recomendada: enviar, enviar con cautela, verificar a mano, no enviar
  • 05Las señales en bruto detrás de todo ello, para aplicar tu propio umbral

Preguntas

Preguntas sobre ponerlo en marcha

¿Por qué caso de uso debería empezar?

Por el que te esté costando dinero ahora mismo. Si los rebotes ya son un problema, empieza limpiando la lista. Si no lo son, pon la comprobación en tu formulario de registro, porque ese es el que impide que el problema vuelva en lugar de repararlo después.

¿Es la verificación en tiempo real lo bastante rápida para un formulario de registro?

Sí. Una comprobación individual responde muy por debajo del segundo en el caso habitual, suficiente para ejecutarse en el manejador del formulario sin que el usuario lo note. Fija un tiempo máximo y decide de antemano tu alternativa: la mayoría de los equipos acepta la dirección y la marca en lugar de bloquear un registro por una consulta lenta.

¿Puedo usar la misma cuenta para comprobaciones en tiempo real y trabajos masivos?

Sí. Los créditos son compartidos, la misma clave de API sirve para ambos, y un trabajo masivo devuelve por dirección la misma estructura que el endpoint individual. No hay un plan ni un producto aparte para uno u otro.

¿Qué ocurre con un dominio catch-all?

Un dominio catch-all acepta correo para todas las direcciones, así que ningún verificador puede demostrar que exista allí un buzón concreto. Lo decimos, y lo devolvemos como un veredicto propio con el motivo adjunto, en lugar de adivinar. Qué hacer con ese segmento depende del caso: suele compensar el riesgo en una reactivación de lista caliente, y rara vez en prospección en frío con un dominio joven.

¿Tengo que escribir código distinto para cada caso de uso?

No. Es un endpoint y una forma de respuesta. Lo que cambia es el umbral que aplicas al resultado, y por eso la respuesta lleva códigos de motivo y un nivel de confianza en lugar de solo un veredicto.

¿Verificar una dirección le envía algo?

No. La verificación se detiene antes de la entrega. La comprobación abre una conversación con el servidor de correo receptor y le pregunta si aceptaría un mensaje para esa dirección, y luego la cierra sin enviar ninguno. El titular del buzón no ve nada.

Empieza con 100 créditos. Sin tarjeta.

Pasa tus propias direcciones y comprueba cuál de los ocho estás resolviendo de verdad.