Cómo verificar correos electrónicos con n8n

Puedes verificar correos electrónicos con n8n hoy mismo sin esperar a un nodo de marca propia: el nodo genérico HTTP Request de n8n llama a la API de Qualisend sin ningún problema y, como n8n es de código abierto y autoalojable, todo el flujo se ejecuta sobre una infraestructura que tú controlas, con la clave de API guardada en el propio almacén de credenciales de n8n. La estructura son siempre los mismos tres nodos: un disparador captura la dirección, un nodo HTTP Request la envía por POST a Qualisend y un nodo IF o Switch lee el status devuelto y encamina cada resultado. Esta guía construye ese flujo de trabajo de principio a fin.

La respuesta rápida#

Todavía no hay un nodo nativo de Qualisend en n8n (está en la hoja de ruta), así que el patrón admitido es un flujo de trabajo con nodos genéricos: un disparador (webhook, formulario, fila nueva, programación), un nodo HTTP Request que envía por POST el correo a la API de verificación con tu clave en una credencial guardada, y un nodo IF o Switch que ramifica según result.status. Mantén la clave en una credencial de n8n —nunca pegada en línea dentro del nodo ni en un campo público— y opta por defecto por dejar pasar una dirección si la llamada HTTP falla en algún momento, de modo que un fallo pasajero nunca descarte en silencio un registro real.

Dos formas de verificar correos electrónicos con n8n#

Antes de conectar nada, elige el patrón que se ajuste a lo reciente que deban ser los datos:

1. Tiempo real, registro a registro (un flujo de trabajo activo). Cada nueva dirección se verifica en el momento en que llega y se encamina sobre la marcha. Este es el tema principal de esta guía y la opción correcta cuando el veredicto cambia lo que ocurre después: bloquear un correo de bienvenida, etiquetar un lead o descartar un registro falso.
2. Por lotes, a posteriori (un CSV). Deja que los registros se acumulen en una hoja de cálculo, base de datos o CRM, expórtalos periódicamente y pásalos por un trabajo de verificación masiva. Más sencillo, más barato por dirección y una opción mejor cuando solo necesitas una lista limpia antes de un envío en lugar de una decisión instantánea.

La mayoría de los equipos acaban haciendo ambas cosas: un flujo de trabajo activo en la captación, más una limpieza de lista periódica para detectar direcciones que hayan quedado obsoletas desde que se registraron. Si el proceso de verificación en sí es nuevo para ti, cómo funciona la verificación de correo explica qué hace realmente la API detrás de esa única solicitud.

Paso 1: el nodo disparador#

Inicia el flujo de trabajo con aquello que capture la dirección. n8n te ofrece muchas opciones, y todas alimentan los mismos nodos posteriores:

• Un nodo Webhook, si un formulario o una aplicación envía por POST los envíos a una URL que tú controlas.
• Un nodo n8n Form Trigger, si quieres que el propio n8n aloje el formulario de captación.
• Un disparador de aplicación —un nodo de Typeform, Google Sheets, Airtable o HubSpot— que se active con un nuevo envío o una nueva fila.
• Un nodo Schedule Trigger que alimente una lectura de base de datos o de hoja de cálculo, si prefieres barrer los registros en pequeños lotes con un temporizador.

Si tu disparador es una herramienta de formularios concreta, el tutorial de plataforma para verificar correos desde Typeform enlaza con los mismos pasos de HTTP Request e IF/Switch de más abajo: solo cambia el nodo disparador.

Elijas lo que elijas, lo único que importa es que la dirección de correo llegue al JSON del elemento para que los nodos posteriores puedan referenciarla —normalmente como {{ $json.email }} (ajusta la clave para que coincida con la salida de tu disparador; una carga útil de Webhook podría exponerla como {{ $json.body.email }}, y un nodo de formulario bajo la etiqueta de campo que hayas definido). Usa el botón Execute step de n8n en el disparador para ver la ruta exacta antes de construir el siguiente nodo.

Paso 2: llama a la API de Qualisend con el nodo HTTP Request#

Añade un nodo HTTP Request después del disparador. Este es el nodo que realmente llama a Qualisend. Configúralo así:

Define el cuerpo JSON mediante una expresión para que la dirección del disparador fluya directamente:

{ "email": "{{ $json.email }}" }

La solicitud que n8n lanza en tu nombre tiene entonces este aspecto —los marcadores de posición te corresponde rellenarlos a partir de la documentación para desarrolladores, que indica el endpoint exacto y muestra la solicitud en varios lenguajes—:

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

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

Crea la clave como una credencial con alcance limitado, solo de verificación en lugar de una clave de acceso total, de modo que si el JSON del flujo de trabajo o un registro llega a filtrar la referencia, esta apunte a una clave que solo pueda verificar, nada más. En n8n, esa clave pertenece a una credencial Header Auth: n8n almacena las credenciales por separado del flujo de trabajo y las cifra en reposo (en instancias autoalojadas, bajo tu N8N_ENCRYPTION_KEY), de modo que el secreto nunca aparece en los parámetros del nodo, en los flujos de trabajo exportados ni en los registros de ejecución.

Cuando ejecutas el nodo con Execute step, n8n muestra el cuerpo de la respuesta. Bajo result obtienes un status, un código reason, un 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 los que ramifica el siguiente nodo, así que ten en cuenta que el estado vive en {{ $json.result.status }} y un subindicador en {{ $json.result.sub_flags.disposable }}. El mismo patrón de solicitud del lado del servidor sustenta la guía de registro serverless: n8n simplemente aloja la llamada por ti en lugar de una función que despliegues tú mismo.

Paso 3: ramifica según el veredicto con IF o Switch#

Un resultado de verificación sobre el que no actúas es crédito desperdiciado. El objetivo es encaminar las direcciones de forma distinta, y n8n te ofrece dos nodos para ello.

Opción A: un nodo IF (lo más sencillo). Si lo único que quieres es «conservar solo las buenas direcciones», añade un nodo IF después del HTTP Request. Establece una condición:

• Value 1: {{ $json.result.status }} — String — is equal to — Value 2: deliverable

Todo lo que coincida sale por la salida true hacia tus nodos posteriores (añadir a tu ESP, crear el contacto, enviar el correo de bienvenida); todo lo demás sale por la salida false, donde puedes descartarlo o aparcarlo. Sencillo, pero tosco: agrupa risky, unknown y undeliverable, cuando a menudo quieres tratarlos de forma diferente.

Opción B: un nodo Switch (encaminar cada resultado). Un nodo Switch en modo Rules te permite bifurcar en una rama separada por estado, cada una con sus propios nodos de seguimiento:

También puedes ramificar según los subindicadores. Si tu producto es sensible a la reputación, añade una regla que encamine cualquier dirección en la que {{ $json.result.sub_flags.disposable }} sea true hacia la rama de revisión, 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 rol, desechables y gratuitas. Las reglas de Switch se evalúan de arriba abajo, así que coloca primero tu rama más estricta y conecta una salida fallback para todo lo que no coincida.

No dejes que la llamada a la API pierda un buen lead#

Una regla importa más que cualquier ramificación: falla abierto. Si el nodo HTTP Request da error —la API está momentáneamente lenta, se alcanza un límite del plan, hay un fallo de red— no querrás que toda la ejecución se detenga y se trague en silencio un registro real. Abre la pestaña Settings del nodo HTTP Request y configura On Error como Continue (using error output), y luego trata una dirección sin veredicto como unknown: consérvala, encamínala a revisión y vuelve a comprobarla más tarde en lugar de descartarla.

Una API de verificación es un filtro de calidad, no una puerta de autenticación. Bloquear a un cliente de pago por una caída pasajera es un resultado mucho peor que dejar pasar una dirección dudosa y detectarla en tu próxima limpieza de lista. Como puede que estés autoalojando, también conviene darle al nodo un timeout razonable (unos pocos segundos) y uno o dos retry, para que un único sondeo lento no atasque una cola de flujos de trabajo con mucho tráfico.

La alternativa por lotes: verificar una exportación en CSV#

n8n es pegamento, y el pegamento tiene un coste: cada dirección verificada es una ejecución, y una llamada HTTP por registro puede parecer excesiva —o acumularse— cuando no necesitas una decisión instantánea. Recurre en su lugar a la vía por lotes cuando:

• Estás limpiando una lista que ya existe —miles de contactos históricos, no captación nueva—. Expórtalos y ejecuta un único trabajo masivo.
• Tu volumen es lo bastante alto como para que la sobrecarga por ejecución escueza, y una limpieza nocturna o semanal es lo bastante reciente.
• Prefieres no mantener un flujo de trabajo activo funcionando para una limpieza puntual.

Para los tres casos, sáltate el flujo de trabajo: exporta los registros a CSV desde tu base de datos, hoja de cálculo o CRM, y sube ese archivo al verificador masivo 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, y hasta puedes ejecutar esa exportación y verificación como su propio flujo de trabajo programado de n8n.

Si estás sopesando el nodo HTTP de n8n frente a llamar a la API directamente desde tu propio backend, la comparativa de APIs expone las concesiones: n8n gana en rapidez de puesta en marcha y encaminamiento visual, y una integración directa gana en coste y control a escala. Si prefieres no autoalojar, el mismo patrón de tres pasos funciona en Zapier.

Preguntas frecuentes#

¿Existe un nodo nativo de Qualisend para n8n?#

Ahora mismo no. Las integraciones nativas de plataforma de Qualisend se están reconstruyendo, así que todavía no hay un nodo específico que buscar en n8n: está en la hoja de ruta. Hasta que se lance, la forma admitida de verificar correos electrónicos con n8n es el nodo genérico HTTP Request apuntando a la API de Qualisend, exactamente como describe esta guía. El enfoque basado en el nodo HTTP también es más flexible: tú controlas la solicitud, la credencial guardada, el tiempo de espera y la lógica de ramificación.

¿Dónde guarda n8n mi clave de API de Qualisend?#

En el almacén de credenciales de n8n, no en el flujo de trabajo. Crea una credencial Header Auth que contenga Authorization: Bearer YOUR_API_KEY y haz referencia a ella desde el nodo HTTP Request. n8n mantiene las credenciales separadas de las definiciones de los flujos de trabajo y las cifra en reposo —en una instancia autoalojada, bajo tu N8N_ENCRYPTION_KEY—, de modo que el secreto nunca aparece en los parámetros del nodo, en el JSON del flujo de trabajo exportado ni en los registros de ejecución. Usa una clave con alcance limitado, solo de verificación, para que una referencia filtrada no pueda hacer nada más que verificar.

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

Solo deliverable si quieres una puerta estricta. Si prefieres conservar más direcciones, permite deliverable más risky/unknown, pero encamina esas hacia un segmento separado y de menor prioridad en lugar de tu flujo principal: muchos resultados risky son dominios catch-all que aún pueden entregar. Rechaza siempre undeliverable y plantéate ramificar también según el subindicador disposable si tu producto es sensible a la reputación.

¿Cómo pruebo el flujo de trabajo antes de activarlo?#

Usa la opción Execute step de n8n en el nodo HTTP Request con una dirección buena conocida y otra mala conocida, y confirma que {{ $json.result.status }} cambia como se espera; luego comprueba que tu nodo IF o Switch encamina cada una a la rama correcta. Para comprobaciones rápidas y puntuales fuera de n8n, pega una dirección en el verificador de correo gratuito y compara el veredicto con el que devuelve tu flujo de trabajo.

¿Listo para construirlo? Consigue una clave con alcance limitado y la estructura exacta de la solicitud en la documentación para desarrolladores, comprueba cualquier dirección en el verificador de correo gratuito y empieza con el plan gratuito: 100 créditos bastan para montar todo el flujo de trabajo y ver cómo se filtra una dirección incorrecta antes de que llegue a tu lista.