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 se basa siempre en 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. Mientras la comprobación del buzón siga en pending, un breve bucle de Wait y GET entre los dos últimos obtiene el veredicto final. 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. Si la primera respuesta indica que result.smtp es pending, la comprobación del buzón sigue en curso, así que un breve bucle de Wait y GET obtiene el veredicto final antes de ramificar. 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://app.qualisend.com/api/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, un conjunto de sub_flags y un campo smtp que indica si la comprobación del buzón ha terminado. Una dirección nueva con un dominio que funciona suele volver así:

{
  "job_id": "3f2b6c1e-8a4d-4f7e-9c21-5b0d7e9a1c44",
  "result": {
    "status": "unknown",
    "reason": null,
    "score": 60,
    "smtp": "pending",
    "sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
  }
}

Ese unknown todavía no es un veredicto. La respuesta llega en cuanto terminan las comprobaciones locales rápidas (sintaxis, dominio y MX, desechable, rol, errores tipográficos), mientras la comprobación SMTP del buzón sigue en curso; el paso 3 recoge el veredicto final. Si smtp es cached o skipped, result ya es definitivo.

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: obtén el veredicto final cuando la comprobación del buzón está pendiente#

Ramificar sobre una respuesta pending enviaría la mayoría de los registros reales por la rama unknown. En su lugar, añade un breve bucle de sondeo entre el nodo HTTP Request y tu enrutador que lea el trabajo que creó la primera llamada:

1. Un nodo IF: {{ $json.result.smtp }} is equal to pending. La salida false (cached o skipped) ya es definitiva y va directamente al paso 4.
2. En la salida true, un nodo Wait configurado entre 5 y 10 segundos.
3. Un segundo nodo HTTP Request con el método GET, la misma credencial Header Auth y esta URL (cambia Verify email por el nombre que diste al primer nodo HTTP Request): https://app.qualisend.com/api/v1/jobs/{{ $('Verify email').item.json.job_id }}?include=results
4. Un nodo IF que comprueba si el trabajo ha terminado: {{ $json.status }} es igual a completed, failed o canceled (tres condiciones combinadas con OR). Conecta su salida false de vuelta al nodo Wait.
5. En la salida true, un nodo Edit Fields (Set) que asigna a un campo llamado result (tipo Object) el valor {{ $json.results[0] }}, para que ambos caminos entreguen al paso 4 el mismo result.status y los mismos result.sub_flags.

Cada sondeo es una llamada normal a la API: no gasta créditos, pero cuenta para el límite de solicitudes por minuto de tu espacio de trabajo, así que una espera de 5 a 10 segundos es más que suficiente. No vuelvas a llamar al endpoint de verificación para «refrescar» una dirección: eso gasta un segundo crédito. Un trabajo que termina en failed o canceled no trae veredicto, así que trátalo como unknown. Y deja que tu disparador responda en cuanto llega un envío (el valor por defecto de un nodo Webhook, Respond: Immediately), para que quien se registra nunca espere a este bucle.

Paso 4: 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 donde se unen los dos caminos del paso 3. 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. Configura igual el nodo GET del paso 3.

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.

¿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.