Cómo verificar correos electrónicos con Make (Integromat)

Hoy puedes verificar correos electrónicos con Make (antes Integromat), aunque todavía no exista un módulo de marca Qualisend en la app. El patrón consiste en construir un escenario en torno al módulo HTTP genérico: un disparador se activa cuando llega una dirección nueva, una petición HTTP envía por POST esa dirección a la API de Qualisend y un Router o un Filter lee el veredicto y bifurca el flujo, de modo que solo las direcciones entregables continúan hacia tu ESP o CRM, y las de riesgo o no entregables quedan apartadas. Esta guía construye ese escenario de principio a fin.

La respuesta rápida#

Ahora mismo no hay ninguna app nativa que instalar (está en la hoja de ruta), así que el patrón admitido es un escenario de tres partes: un disparador (nuevo envío de formulario, nueva fila o un webhook personalizado al que apuntas un formulario), un módulo HTTP → Make a request que llama a la API de verificación con el correo, y un Router con filtros por ruta que leen el status devuelto y deciden qué pasa a continuación. Guarda tu clave de API en las cabeceras del módulo, nunca en un campo público de un formulario, y configura el módulo HTTP para que siga funcionando si la API falla en algún momento, de modo que un problema transitorio nunca descarte un lead real.

Dos formas de verificar correos con Make#

Antes de conectar nada, elige el patrón que encaje con lo fresca que necesitas que esté la información:

1. Tiempo real, envío a envío (un escenario). Cada dirección nueva se verifica en el momento en que llega y se enruta al instante. Este es el tema principal de esta guía y la opción correcta cuando el veredicto cambia lo que pasa después: condicionar un correo de doble opt-in, etiquetar un lead o descartar un registro falso.
2. Por lotes, a posteriori (un CSV). Deja que los envíos se acumulen en una hoja o en tu ESP, expórtalos periódicamente y pásalos por un trabajo de verificación en bloque. Más sencillo, más barato por dirección y mejor opción cuando lo único que necesitas es una lista limpia antes de un envío, no una decisión instantánea.

La mayoría de los equipos acaban haciendo ambas cosas: un escenario en la entrada en vivo, más una limpieza de lista mensual para detectar direcciones que se han quedado obsoletas desde que se registraron.

Paso 1: el disparador#

Empieza el escenario con lo que capture la dirección. Make tiene cientos de módulos disparadores: "Watch Responses" en una app de formularios, "Watch Rows" en Google Sheets o Airtable, "New Lead" en un CRM. Si tu herramienta de formularios no tiene un módulo de Make dedicado, coloca un Custom webhook como primer módulo y apunta la URL de webhook de tu formulario hacia él; Make genera una URL única y te muestra la estructura de los datos entrantes en cuanto llega el primer envío.

Elijas lo que elijas, la salida importante es un campo que contiene la dirección de correo, al que los módulos posteriores hacen referencia como un token mapeado: Make los muestra como píldoras de colores en las que haces clic para insertarlas en un campo, extraídas del paquete de salida del disparador. En los ejemplos siguientes, ese token se escribe como {{1.email}}, donde 1 es el módulo disparador.

Paso 2: envía la dirección por POST con el módulo HTTP#

Añade un módulo y elige HTTP → Make a request. Este es el paso que realmente llama a Qualisend. Configúralo así:

Activa Parse response para que Make lea el JSON devuelto y lo convierta en campos mapeables en lugar de una cadena en bruto. En la casilla Request content, escribe el cuerpo e inserta la píldora de correo del disparador:

{ "email": "{{1.email}}" }

La petición que Make lanza en tu nombre tiene este aspecto; los marcadores de posición debes rellenarlos tú a partir de la documentación para desarrolladores, que enumera el endpoint exacto y muestra la petición en varios lenguajes:

POST https://api.qualisend.com/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{ "email": "jane@example.com" }

Usa una clave con ámbito acotado creada para este escenario en lugar de una clave de acceso completo, de modo que si el historial de ejecución del escenario llegara a filtrarse, la clave solo pueda verificar y nada más. Nunca pongas la clave en el propio formulario ni en ningún campo del lado del cliente: pertenece únicamente a las cabeceras del módulo HTTP, que se ejecutan en el servidor dentro de Make.

Cuando hagas clic en Run once, Make muestra el paquete de respuesta. Recibes un objeto result que contiene un status, un código reason, una puntuación score de 0 a 100 y un conjunto de sub_flags. Una dirección entregable vuelve más o menos así:

{
  "result": {
    "status": "deliverable",
    "reason": null,
    "score": 95,
    "sub_flags": { "disposable": false, "role": false, "free": false, "catch_all": false }
  }
}

Esos nombres de campo son sobre los que ramifica el siguiente paso, así que fíjate en cómo los mapea Make: harás referencia a result: status, result: score y a los sub_flags individuales en los filtros. Para tener la imagen completa de qué significa cada estado y cómo llega el pipeline hasta él, consulta cómo funciona la verificación de correo.

Paso 3: ramifica según el veredicto con un Router#

Un resultado de verificación sobre el que no actúas es crédito desperdiciado. Todo el sentido está en enrutar las direcciones de forma distinta, y en Make eso lo hace el módulo Router.

Coloca un Router después del módulo HTTP y se abanica en tantas rutas como necesites. Cada ruta tiene su propio filtro (haz clic en la llave inglesa de la línea que sale del Router) que comprueba el status parseado de la respuesta HTTP:

Make evalúa las rutas de izquierda a derecha y, salvo que marques una ruta como fallback (la ruta sin filtro), se ejecuta cada ruta que coincida, así que mantén tus condiciones mutuamente excluyentes sobre status para evitar que una misma dirección baje por dos ramas. Marca la rama de undeliverable/sin coincidencia como fallback para que nada se cuele sin clasificar.

También puedes ramificar según los subindicadores. Si tu producto es sensible a la reputación, añade a la ruta de revisión una condición que se dispare también cuando sub_flags: disposable sea true, incluso cuando el estado sea por lo demás correcto: la misma llamada sobre direcciones desechables, de rol y gratuitas que recorre el desglose de direcciones de rol, desechables y gratuitas. Un mismo filtro de Router admite varias condiciones AND/OR, así que puedes combinar una comprobación de status y otra de sub_flags en una sola ruta.

No dejes que el módulo HTTP bloquee un buen lead#

Una regla importa más que cualquier ramificación: falla en abierto (fail open). Si el módulo HTTP da error (la API va momentáneamente lenta, se alcanza un límite del plan, hay un fallo de red), no querrás que todo el escenario se detenga y trague en silencio un registro real. Haz clic derecho en el módulo HTTP, elige Add error handler y adjunta una directiva Resume que aporte un paquete por defecto con status fijado en unknown. El escenario sigue entonces por un camino que trata la dirección como "revisar más tarde" en lugar de descartarla. (También puedes configurar el manejo de errores del escenario para que almacene las ejecuciones incompletas, de modo que las ejecuciones fallidas se pongan en cola para reintentarlas en vez de desaparecer.)

Una API de verificación es un filtro de calidad, no una barrera de autenticación. Bloquear a un cliente de pago por una caída transitoria es un resultado mucho peor que dejar pasar una dirección dudosa y atraparla en tu próxima limpieza de lista. El mismo principio de fallar en abierto sustenta el patrón de registro serverless, donde un sondeo lento nunca debe atascar el formulario.

Cuándo un escenario es la herramienta equivocada#

Make es pegamento, y el pegamento tiene un coste: cada dirección verificada quema operaciones, y una llamada HTTP por envío puede acumularse a gran volumen o resultar excesiva cuando no necesitas una decisión instantánea. Recurre a la ruta por lotes en su lugar cuando:

• Estés limpiando una lista que ya existe: miles de contactos históricos, no entrada nueva. Expórtalos y ejecuta un único trabajo en bloque.
• Tu volumen sea lo bastante alto como para que el precio por operación duela, y una limpieza nocturna o semanal sea suficientemente fresca.
• Prefieras no mantener un escenario en vivo para una tarea que solo necesita ejecutarse de vez en cuando.

En los tres casos, sáltate el escenario: exporta los envíos a CSV desde tu herramienta de formularios, tu hoja o tu ESP, y sube ese archivo al verificador en bloque de Qualisend. Obtienes el mismo status, score y subindicadores por fila, descargables como un archivo limpio que puedes reimportar. Es la forma con menos esfuerzo de mantener una lista sana y tu tasa de rebote baja sin mantener ninguna automatización.

Si estás sopesando el enfoque HTTP de Make frente a llamar a la API directamente desde tu propio backend, la comparativa de API expone las contrapartidas: un escenario de Make gana en rapidez de puesta en marcha y no necesita servidor, mientras que una integración directa gana en coste y control a escala. El mismo patrón del módulo HTTP también se traslada con limpieza a un flujo de trabajo autoalojado de n8n si te quedas pequeño con el precio por operaciones de Make.

Preguntas frecuentes#

¿Existe un módulo nativo de Qualisend para Make?#

Ahora mismo no. Las integraciones nativas de Qualisend con plataformas se están reconstruyendo, así que todavía no hay una app de marca que buscar en la lista de módulos de Make; está en la hoja de ruta. Hasta que se publique, la forma admitida de verificar correos con Make es el módulo genérico HTTP → Make a request apuntando a la API de Qualisend, exactamente como describe esta guía. El enfoque HTTP también es más flexible: tú controlas la petición, las cabeceras y la lógica de enrutamiento.

¿Cuántas operaciones consume el escenario por correo?#

Aproximadamente una operación por cada módulo que se ejecuta: el disparador, la petición HTTP y la ruta activa del Router cuentan cada uno. Así que un único envío verificado son unas pocas operaciones, y 1.000 envíos son unos pocos miles, dentro de lo que cubren la mayoría de los planes de pago de Make. Si tu volumen hace que el precio por operación duela, deriva ese tráfico a la ruta de exportación a CSV y verificación en bloque, que no consume ninguna operación.

¿Qué estado debería dejar pasar a mi herramienta de correo?#

Solo deliverable si quieres un filtro estricto. Si prefieres conservar más direcciones, permite deliverable más risky/unknown, pero dirígelas a un segmento separado de menor prioridad en lugar de a tu flujo principal, ya que muchos resultados risky son dominios catch-all que aún podrían entregar. Rechaza siempre las undeliverable y valora ramificar también según el subindicador disposable si tu producto es sensible a la reputación.

¿Cómo pruebo el escenario antes de activarlo?#

Usa el botón Run once de Make con una dirección buena conocida y otra mala conocida, y observa la burbuja del módulo HTTP mostrando el status devuelto; después confirma que cada ruta del Router se activa con la entrada correcta. Para comprobaciones puntuales rápidas fuera de Make, pega una dirección en el verificador de correo gratuito y compara el veredicto con el que devuelve tu escenario.

¿Listo para construirlo? Consigue una clave con ámbito acotado y la forma exacta de la petición en la documentación para desarrolladores, verifica cualquier dirección en el verificador de correo gratuito y empieza con el plan gratuito: 100 créditos bastan para montar todo el escenario y ver cómo una dirección incorrecta se filtra antes de que llegue siquiera a tu lista.