Comment vérifier des e-mails avec n8n

Vous pouvez vérifier vos e-mails avec n8n dès aujourd'hui, sans attendre un nœud de marque — le nœud générique HTTP Request de n8n appelle très bien l'API Qualisend, et comme n8n est open source et auto-hébergeable, tout le flux s'exécute sur une infrastructure que vous maîtrisez, la clé API restant stockée dans le propre coffre d'identifiants de n8n. La structure repose toujours sur les mêmes trois nœuds : un déclencheur capture l'adresse, un nœud HTTP Request l'envoie en POST à Qualisend, et un nœud IF ou Switch lit le status renvoyé et aiguille chaque résultat. Tant que la vérification de la boîte aux lettres est pending, une courte boucle Wait et GET entre les deux derniers récupère le verdict final. Ce guide construit ce workflow de bout en bout.

La réponse en bref#

Il n'existe pas encore de nœud Qualisend natif dans n8n (c'est prévu dans la feuille de route), le schéma pris en charge est donc un workflow à nœuds génériques : un déclencheur (webhook, formulaire, nouvelle ligne, planification), un nœud HTTP Request qui envoie l'e-mail en POST à l'API de vérification avec votre clé dans un identifiant stocké, et un nœud IF ou Switch qui aiguille selon result.status. Si la première réponse indique que result.smtp vaut pending, la vérification de la boîte aux lettres est encore en cours : une courte boucle Wait et GET récupère alors le verdict final avant l'aiguillage. Gardez la clé dans un identifiant n8n — jamais collée en clair dans le nœud ni dans un champ public — et laissez par défaut passer une adresse si l'appel HTTP échoue, pour qu'un incident passager ne fasse jamais disparaître silencieusement une vraie inscription.

Deux façons de vérifier des e-mails avec n8n#

Avant de câbler quoi que ce soit, choisissez le schéma qui correspond au degré de fraîcheur dont vos données ont besoin :

1. En temps réel, enregistrement par enregistrement (un workflow en direct). Chaque nouvelle adresse est vérifiée dès son arrivée et aiguillée dans la foulée. C'est le sujet principal de ce guide et le bon choix lorsque le verdict change la suite des événements — conditionner un e-mail de bienvenue, taguer un prospect ou écarter une fausse inscription.
2. Par lots, a posteriori (un CSV). Laissez les enregistrements s'accumuler dans une feuille, une base de données ou un CRM, exportez-les périodiquement, et passez-les dans un traitement de vérification en masse. Plus simple, moins cher par adresse, et mieux adapté quand vous avez juste besoin d'une liste propre avant un envoi plutôt que d'une décision instantanée.

La plupart des équipes finissent par faire les deux : un workflow en direct sur la collecte, plus un nettoyage de liste périodique pour rattraper les adresses devenues obsolètes depuis l'inscription. Si le pipeline de vérification lui-même est nouveau pour vous, comment fonctionne la vérification d'e-mails explique ce que fait réellement l'API derrière cette unique requête.

Étape 1 : le nœud déclencheur#

Démarrez le workflow avec ce qui capture l'adresse. n8n vous offre de nombreuses options, et elles alimentent toutes les mêmes nœuds en aval :

• Un nœud Webhook, si un formulaire ou une application envoie les soumissions en POST vers une URL que vous maîtrisez.
• Un nœud n8n Form Trigger, si vous voulez que n8n héberge lui-même le formulaire de collecte.
• Un déclencheur d'application — un nœud Typeform, Google Sheets, Airtable ou HubSpot — qui se déclenche à chaque nouvelle soumission ou ligne.
• Un nœud Schedule Trigger alimentant la lecture d'une base de données ou d'un tableur, si vous préférez balayer les enregistrements par petits lots à intervalle régulier.

Si votre déclencheur est un outil de formulaire précis, le guide pas à pas pour vérifier des e-mails depuis Typeform enchaîne sur les mêmes étapes HTTP Request et IF/Switch ci-dessous — seul le nœud déclencheur change.

Quel que soit votre choix, la seule chose qui compte est que l'adresse e-mail atterrisse dans le JSON de l'élément pour que les nœuds suivants puissent y faire référence — le plus souvent via {{ $json.email }} (adaptez la clé à la sortie de votre déclencheur ; une charge utile de Webhook peut l'exposer sous {{ $json.body.email }}, un nœud de formulaire sous le libellé de champ que vous avez défini). Utilisez le bouton Execute step de n8n sur le déclencheur pour voir le chemin exact avant de construire le nœud suivant.

Étape 2 : appeler l'API Qualisend avec le nœud HTTP Request#

Ajoutez un nœud HTTP Request après le déclencheur. C'est le nœud qui appelle réellement Qualisend. Configurez-le ainsi :

Définissez le corps JSON à l'aide d'une expression pour que l'adresse du déclencheur circule directement :

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

La requête que n8n envoie en votre nom ressemble alors à ceci — les espaces réservés sont à compléter à partir de la documentation développeur, qui liste le point de terminaison exact et montre la requête dans plusieurs langages :

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

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

Créez la clé en tant qu'identifiant à portée limitée, réservé à la vérification plutôt qu'une clé à accès complet, ainsi si le JSON du workflow ou un journal divulgue un jour la référence, celle-ci renvoie à une clé qui ne peut que vérifier, rien d'autre. Dans n8n, cette clé va dans un identifiant Header Auth — n8n stocke les identifiants séparément du workflow et les chiffre au repos (sur les instances auto-hébergées, sous votre N8N_ENCRYPTION_KEY), de sorte que le secret n'apparaît jamais dans les paramètres du nœud, les workflows exportés ni les journaux d'exécution.

Lorsque vous exécutez le nœud avec Execute step, n8n affiche le corps de la réponse. Sous result, vous obtenez un status, un code reason, un score de 0 à 100, un ensemble de sub_flags et un champ smtp qui indique si la vérification de la boîte aux lettres est terminée. Une nouvelle adresse sur un domaine qui fonctionne revient généralement comme ceci :

{
  "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 }
  }
}

Ce unknown n'est pas encore un verdict. La réponse arrive dès que les vérifications locales rapides (syntaxe, domaine et MX, disposable, role, faute de frappe) sont terminées, alors que la vérification SMTP de la boîte aux lettres est encore en cours ; l'étape 3 récupère le verdict final. Si smtp vaut cached ou skipped, result est déjà définitif.

Ce sont ces noms de champs sur lesquels le nœud suivant s'aiguille ; notez donc que le statut se trouve à {{ $json.result.status }} et un sous-indicateur à {{ $json.result.sub_flags.disposable }}. Ce même schéma de requête côté serveur sous-tend le guide d'inscription serverless — n8n héberge simplement l'appel à votre place, au lieu d'une fonction que vous déployez vous-même.

Étape 3 : récupérer le verdict final si la vérification de la boîte est en attente#

Aiguiller sur une réponse pending enverrait la plupart des vraies inscriptions dans la branche unknown. Ajoutez plutôt une courte boucle d'interrogation entre le nœud HTTP Request et votre routeur, qui lit le job créé par le premier appel :

1. Un nœud IF : {{ $json.result.smtp }} is equal to pending. La sortie false (cached ou skipped) est déjà définitive et va directement à l'étape 4.
2. Sur la sortie true, un nœud Wait réglé sur 5 à 10 secondes.
3. Un second nœud HTTP Request avec la méthode GET, le même identifiant Header Auth et cette URL (remplacez Verify email par le nom de votre premier nœud HTTP Request) : https://app.qualisend.com/api/v1/jobs/{{ $('Verify email').item.json.job_id }}?include=results
4. Un nœud IF qui vérifie si le job est terminé : {{ $json.status }} est égal à completed, failed ou canceled (trois conditions combinées avec OR). Reliez sa sortie false au nœud Wait.
5. Sur la sortie true, un nœud Edit Fields (Set) qui donne à un champ nommé result (type Object) la valeur {{ $json.results[0] }}, pour que les deux chemins transmettent à l'étape 4 le même result.status et les mêmes result.sub_flags.

Chaque interrogation est un appel API ordinaire : il ne consomme aucun crédit, mais il compte dans la limite de requêtes par minute de votre espace de travail, donc une attente de 5 à 10 secondes suffit largement. N'appelez pas de nouveau le point de terminaison de vérification pour « rafraîchir » une adresse : cela consomme un second crédit. Un job qui se termine en failed ou canceled ne porte aucun verdict ; traitez-le comme unknown. Enfin, laissez votre déclencheur répondre dès qu'une soumission arrive (le réglage par défaut d'un nœud Webhook, Respond: Immediately), pour que la personne qui s'inscrit n'attende jamais cette boucle.

Étape 4 : aiguiller selon le verdict avec IF ou Switch#

Un résultat de vérification sur lequel vous n'agissez pas est un crédit gaspillé. Tout l'intérêt est de router les adresses différemment, et n8n vous offre deux nœuds pour cela.

Option A — un nœud IF (le plus simple). Si tout ce que vous voulez, c'est « ne garder que les bonnes adresses », ajoutez un nœud IF là où se rejoignent les deux chemins de l'étape 3. Définissez une seule condition :

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

Tout ce qui correspond sort par la sortie true vers vos nœuds en aval (ajout à votre ESP, création du contact, envoi de l'e-mail de bienvenue) ; tout le reste sort par la sortie false, où vous pouvez l'écarter ou le mettre de côté. Simple, mais brutal — cela regroupe risky, unknown et undeliverable ensemble, alors que vous voulez souvent les traiter différemment.

Option B — un nœud Switch (aiguiller chaque résultat). Un nœud Switch en mode Rules vous permet de bifurquer dans une branche distincte par statut, chacune avec ses propres nœuds de suivi :

Vous pouvez aussi aiguiller sur les sous-indicateurs. Si votre produit est sensible à la réputation, ajoutez une règle qui route toute adresse dont {{ $json.result.sub_flags.disposable }} vaut true vers la branche d'examen, même lorsque le statut est par ailleurs correct — le même appel sur les adresses disposable, role et free que détaille le décryptage des adresses role, disposable et free. Les règles Switch sont évaluées de haut en bas, placez donc votre branche la plus stricte en premier et câblez une sortie fallback pour tout ce qui reste sans correspondance.

Ne laissez pas l'appel à l'API perdre un bon prospect#

Une règle compte plus que n'importe quelle branche : fail open (laisser passer en cas d'échec). Si le nœud HTTP Request échoue — l'API est brièvement lente, une limite de forfait est atteinte, un incident réseau — vous ne voulez pas que toute l'exécution s'arrête et engloutisse silencieusement une vraie inscription. Ouvrez l'onglet Settings du nœud HTTP Request et réglez On Error sur Continue (using error output), puis traitez une adresse sans verdict comme unknown : gardez-la, routez-la vers l'examen et revérifiez-la plus tard plutôt que de l'écarter. Réglez de la même façon le nœud GET de l'étape 3.

Une API de vérification est un filtre qualité, pas une barrière d'authentification. Bloquer un client payant à cause d'une panne passagère est une bien pire issue que de laisser passer une adresse douteuse et de la rattraper lors de votre prochain nettoyage de liste. Comme vous auto-hébergez peut-être, il vaut aussi la peine de donner au nœud un timeout raisonnable (quelques secondes) et un ou deux retry, pour qu'une seule sonde lente ne bloque pas une file de workflow chargée.

L'alternative en masse : vérifier un export CSV#

n8n est de la « colle », et la colle a un coût : chaque adresse vérifiée est une exécution, et un appel HTTP par enregistrement peut sembler excessif — ou finir par peser — quand vous n'avez pas besoin d'une décision instantanée. Optez plutôt pour la voie par lots lorsque :

• Vous nettoyez une liste qui existe déjà — des milliers de contacts historiques, pas une nouvelle collecte. Exportez-les et lancez un seul traitement en masse.
• Votre volume est assez élevé pour que le surcoût par exécution pique, et qu'un nettoyage nocturne ou hebdomadaire soit suffisamment frais.
• Vous préférez ne pas maintenir un workflow en direct pour un nettoyage ponctuel.

Dans ces trois cas, passez le workflow : exportez les enregistrements au format CSV depuis votre base de données, feuille ou CRM, et téléversez ce fichier vers le vérificateur en masse de Qualisend. Vous obtenez les mêmes status, score et sous-indicateurs par ligne, téléchargeables sous forme de fichier nettoyé que vous pouvez réimporter. C'est la façon la moins laborieuse de garder une liste saine et votre taux de rebond bas sans maintenir la moindre automatisation — et vous pouvez même faire de cet export-et-vérification un workflow n8n planifié à part entière.

Si vous hésitez entre le nœud HTTP de n8n et l'appel direct à l'API depuis votre propre backend, la comparaison des API expose les compromis — n8n l'emporte sur la rapidité de mise en place et l'aiguillage visuel, une intégration directe l'emporte sur le coût et le contrôle à grande échelle. Si vous préférez ne pas auto-héberger, le même schéma en trois étapes fonctionne dans Zapier.

Prêt à le construire ? Récupérez une clé à portée limitée et la structure exacte de la requête depuis la documentation développeur, vérifiez n'importe quelle adresse dans le vérificateur d'e-mails gratuit, et démarrez avec le forfait gratuit — 100 crédits suffisent à câbler tout le workflow et à regarder une mauvaise adresse être filtrée avant même d'atteindre votre liste.