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 est toujours la même, avec 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. 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. 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://api.qualisend.com/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 et un ensemble de sub_flags. Une adresse deliverable revient à peu près comme ceci :

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

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 : 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 après le HTTP Request. 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.

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.

Foire aux questions#

Existe-t-il un nœud Qualisend natif pour n8n ?#

Pas pour l'instant. Les intégrations natives de Qualisend sont en cours de reconstruction, il n'y a donc pas encore de nœud dédié à chercher dans n8n — c'est prévu dans la feuille de route. En attendant sa sortie, la méthode prise en charge pour vérifier des e-mails avec n8n est le nœud générique HTTP Request pointé vers l'API Qualisend, exactement comme le décrit ce guide. L'approche par nœud HTTP est aussi plus souple : vous maîtrisez la requête, l'identifiant stocké, le délai d'expiration et la logique d'aiguillage.

Où n8n stocke-t-il ma clé API Qualisend ?#

Dans le coffre d'identifiants de n8n, pas dans le workflow. Créez un identifiant Header Auth contenant Authorization: Bearer YOUR_API_KEY et référencez-le depuis le nœud HTTP Request. n8n garde les identifiants séparés des définitions de workflow et les chiffre au repos — sur une instance auto-hébergée sous votre N8N_ENCRYPTION_KEY — de sorte que le secret n'apparaît jamais dans les paramètres du nœud, le JSON du workflow exporté ni les journaux d'exécution. Utilisez une clé à portée limitée, réservée à la vérification, pour qu'une référence divulguée ne puisse rien faire d'autre que vérifier.

Quel statut dois-je laisser passer vers mon outil e-mail ?#

Uniquement deliverable pour un filtrage strict. Si vous voulez conserver davantage d'adresses, autorisez deliverable ainsi que risky/unknown, mais routez ces dernières vers un segment distinct et de moindre priorité plutôt que vers votre flux principal — beaucoup de résultats risky sont des domaines catch-all qui peuvent tout de même délivrer. Rejetez toujours undeliverable, et envisagez d'aiguiller aussi sur le sous-indicateur disposable si votre produit est sensible à la réputation.

Comment tester le workflow avant de l'activer ?#

Utilisez le bouton Execute step de n8n sur le nœud HTTP Request avec une adresse connue comme valide et une autre connue comme invalide, et vérifiez que {{ $json.result.status }} change comme prévu — puis contrôlez que votre nœud IF ou Switch route chacune vers la bonne branche. Pour des vérifications ponctuelles rapides en dehors de n8n, collez une adresse dans le vérificateur d'e-mails gratuit et comparez le verdict à ce que renvoie votre workflow.

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.