Typeform excelle à collecter des adresses e-mail et, discrètement, échoue à vous dire lesquelles sont réelles. Son champ e-mail vérifie que ce que quelqu'un a saisi ressemble à une adresse — il ne peut pas confirmer que la boîte aux lettres existe, qu'elle n'est pas jetable, ou qu'elle ne fera pas un hard bounce dès votre tout premier suivi. Ce guide présente deux méthodes concrètes pour vérifier les e-mails de Typeform avec Qualisend : en temps réel, avec un webhook qui se déclenche à l'instant où une réponse arrive, et en masse, en exportant les réponses dans un CSV. Aucune ne nécessite de plugin natif — il n'y en a pas encore — juste les webhooks intégrés de Typeform ou son bouton d'export.
La réponse en bref#
Choisissez la voie qui correspond au moment où vous avez besoin de la réponse :
- Temps réel — dirigez un webhook Typeform vers une petite fonction serverless. À chaque réponse, Typeform envoie en POST la réponse à votre endpoint ; la fonction récupère l'e-mail, appelle l'API Qualisend et agit sur le verdict — taguer le contact, l'orienter vers la bonne liste, ou retenir l'e-mail de bienvenue pour une mauvaise adresse.
- En masse — exportez vos réponses existantes au format CSV, passez-les dans la vérification en masse de Qualisend, et supprimez les adresses non distribuables avant votre prochain envoi.
Pourquoi le champ e-mail de Typeform ne suffit pas#
Le type de question email de Typeform effectue une vérification de format dans
le navigateur — il s'assure qu'il y a un @, un domaine, et aucune bêtise
évidente. C'est la même catégorie de vérification qu'une regex, et elle échoue
pour les mêmes raisons :
le format n'est pas la délivrabilité. jane@gmial.com
passe le contrôle de format. Tout comme throwaway@mailinator.com, et tout comme
une adresse d'apparence réelle sur un domaine qui a fermé l'an dernier.
Aucune de ces adresses n'est détectée avant l'envoi — et à ce moment-là une adresse morte est un hard bounce qui grignote votre taux de rebond et votre réputation d'expéditeur. Une vraie vérification ajoute les couches que Typeform ne peut pas : une recherche DNS/MX et un sondage SMTP de la boîte aux lettres, plus des drapeaux pour les adresses jetables, génériques (role) et catch-all. Si ce pipeline est nouveau pour vous, ce que vérifie réellement la vérification d'e-mails est l'introduction.
Deux façons de vérifier les e-mails de Typeform#
D'abord la contrainte importante : Typeform ne peut pas bloquer un mauvais e-mail en cours de formulaire. Il n'existe aucun moyen pris en charge d'appeler une API externe entre les questions et d'empêcher un répondant de terminer, donc la vérification en temps réel a lieu juste après l'envoi, dans un webhook — et non comme un filtre intégré. Cela façonne les deux voies.
| Voie | Quand elle s'exécute | Idéale pour |
|---|---|---|
| Webhook en temps réel | Instantanément, à chaque réponse | Tunnels en direct — taguer, orienter ou retenir le suivi avant l'envoi |
| CSV en masse | À la demande, par lots | Arriérés de réponses existantes et hygiène périodique de liste |
Voie 1 : temps réel avec un webhook Typeform#
Typeform peut envoyer chaque réponse à une URL que vous contrôlez. Dans le
panneau Connect du formulaire, ajoutez un webhook et pointez-le vers votre
endpoint. Les webhooks sont une fonctionnalité des forfaits payants de Typeform,
alors vérifiez votre offre avant de construire. Lorsqu'une réponse est soumise,
Typeform envoie en POST une charge utile JSON dont le tableau
form_response.answers contient chaque réponse — l'adresse e-mail se trouve dans
la réponse de type email.
Votre endpoint est une fonction serverless qui détient la clé d'API et transforme le verdict en action. Le schéma est le même que dans le guide de vérification à l'inscription : la clé reste côté serveur, et vous agissez sur le résultat. Le voici sous forme de Route Handler Next.js (consultez la documentation développeur pour le chemin exact de l'endpoint et la forme de la requête) :
// app/api/typeform-webhook/route.ts
import { NextResponse } from "next/server";
// Placeholder — confirm the real path in /developers.
const QUALISEND_ENDPOINT = "https://api.qualisend.com/v1/verify";
export async function POST(req: Request) {
const payload = await req.json();
// The email lives in the answer whose type is "email".
const answers = payload.form_response?.answers ?? [];
const email = answers.find((a) => a.type === "email")?.email;
if (!email) return NextResponse.json({ ok: true }); // nothing to verify
const res = await fetch(QUALISEND_ENDPOINT, {
method: "POST",
headers: {
// Store YOUR_API_KEY server-side, never in the browser.
Authorization: `Bearer ${process.env.QUALISEND_API_KEY!}`,
"Content-Type": "application/json",
},
body: JSON.stringify({ email }),
signal: AbortSignal.timeout(4000),
});
if (!res.ok) return NextResponse.json({ ok: true, degraded: true }); // fail open
const { result } = await res.json();
// The submit already happened — route on the verdict instead of blocking.
if (result.status === "undeliverable" || result.sub_flags?.disposable) {
// Skip the welcome email, tag the contact for review, keep it off the main list.
}
return NextResponse.json({ ok: true, status: result.status });
}
Trois éléments rendent ce dispositif robuste. Répondez vite : Typeform attend
un 2xx rapidement, alors gardez le handler léger et renvoyez la réponse sans
tarder. Échouez en mode ouvert : si l'API expire ou renvoie une erreur, ne
perdez pas le prospect — acceptez-le et revérifiez plus tard, c'est pourquoi la
branche !res.ok renvoie tout de même ok: true. Et vérifiez la signature
que Typeform envoie, afin qu'un inconnu ne puisse pas envoyer en POST de fausses
réponses à votre endpoint — le panneau Connect vous fournit un secret pour cela.
Un piège dans la charge utile : si votre formulaire comporte plusieurs questions
e-mail, ou si vous voulez être robuste aux réordonnancements, faites correspondre
sur le field.ref de la réponse plutôt que de prendre la première réponse de type
type === "email". Définissez un ref stable sur la question e-mail dans le
constructeur Typeform et lisez a.field?.ref === "your_ref", ainsi la bonne
adresse est toujours celle que vous vérifiez.
En aval, le verdict n'est qu'un aiguillage. Un résultat deliverable file droit
dans votre CRM ou votre outil d'e-mailing ; un résultat undeliverable ou
disposable est tagué, mis de côté hors de la séquence de bienvenue, ou déposé
dans une file de revue — selon ce dont votre processus a besoin. Le webhook est la
tuyauterie ; l'aiguillage vous appartient.
La logique de vérification elle-même est indépendante du langage ; le même appel fonctionne depuis une fonction Python ou PHP si c'est votre stack. Le code de l'endpoint dans le tutoriel Node.js ou le tutoriel Python s'insère directement dans un handler de webhook — seule l'analyse de la charge utile ci-dessus est spécifique à Typeform.
Voie 2 : vérifier en masse un export CSV#
Si vous avez déjà une pile de réponses, ou si vous préférez nettoyer selon un calendrier plutôt que câbler un webhook, procédez par lots. Dans Typeform, ouvrez Results → Responses et téléchargez les données au format CSV (ou XLSX). Vous obtiendrez une ligne par réponse, avec l'e-mail dans sa propre colonne.
Ensuite :
- Téléversez le CSV dans la vérification en masse de Qualisend et laissez-la exécuter tout le pipeline — MX, SMTP, et les drapeaux jetable/générique/catch-all — sur chaque ligne.
- Téléchargez le fichier annoté. Chaque adresse revient avec un statut, un code de raison et un score de 0 à 100.
- Supprimez les adresses non distribuables dans l'outil depuis lequel vous envoyez réellement vos e-mails, et traitez les lignes à risque avec précaution. La routine de bout en bout, y compris la place de chaque statut, se trouve dans comment nettoyer une liste d'e-mails.
Le mode en masse est l'outil adapté à un arriéré, mais c'est du nettoyage, pas de la prévention : une adresse détectée ici traîne généralement déjà dans votre liste. Associez un passage en masse périodique au webhook en temps réel afin que les nouvelles mauvaises adresses soient signalées dès leur arrivée.
Agir sur le verdict#
Quelle que soit la voie qui livre le résultat, la forme est la même — un
status, une reason, un score, et les sous-drapeaux. Faites correspondre
chacun à une action :
| Résultat | Que faire |
|---|---|
deliverable | Accepter — ajouter à votre liste et envoyer normalement. |
undeliverable | Supprimer. Ne pas envoyer ; consultez la reason pour savoir
s'il s'agit d'un mauvais domaine ou d'une boîte aux lettres morte. |
drapeau disposable | Rejeter ou taguer, selon la rigueur de votre tunnel — voir adresses génériques, jetables & gratuites. |
risky / catch-all | Accepter mais segmenter. Un domaine catch-all ne peut pas confirmer la boîte aux lettres individuelle, alors envoyez avec prudence. |
unknown | Accepter et revérifier plus tard — l'infrastructure n'a pas répondu, ne lâchez donc jamais un vrai prospect à cause de ça. |
Questions fréquentes#
Typeform peut-il vérifier les adresses e-mail par lui-même ?#
Seulement le format. Le type de question email de Typeform confirme qu'une
adresse est bien formée — elle comporte un @ et un domaine — mais il ne résout
pas les enregistrements MX et ne sonde pas la boîte aux lettres, si bien qu'une
adresse mal orthographiée ou jetable qui semble valide passe quand même. Une vraie
vérification a besoin des couches DNS et SMTP qu'un service comme Qualisend ajoute
par-dessus.
Ai-je besoin d'un forfait Typeform payant pour vérifier les e-mails en temps réel ?#
Pour la voie du webhook, oui — les webhooks sortants se trouvent dans le panneau Connect de Typeform, sur ses forfaits payants, alors vérifiez votre forfait avant de construire l'endpoint. Si vous êtes sur un forfait sans webhooks, utilisez plutôt la voie en masse : exportez les réponses au format CSV et vérifiez-les par lots, ce qui fonctionne sur tout forfait permettant de télécharger les résultats.
Puis-je bloquer un mauvais e-mail avant que le répondant ne termine le formulaire ?#
Pas de façon fiable. Typeform ne propose aucun moyen pris en charge d'appeler une API externe en cours de formulaire et d'empêcher quelqu'un de soumettre, donc la vérification en temps réel s'exécute juste après l'envoi, dans le webhook. En pratique, cela convient : vous vérifiez en quelques secondes et agissez avant que l'adresse ne reçoive le moindre message — vous retenez l'e-mail de bienvenue, taguez le contact ou l'orientez vers une revue plutôt que de bloquer le formulaire lui-même.
Dois-je utiliser le webhook en temps réel ou l'export CSV en masse ?#
Utilisez le webhook quand le timing compte — vous voulez accueillir, orienter ou supprimer chaque réponse à mesure qu'elle arrive. Utilisez le mode en masse quand vous nettoyez un arriéré ou effectuez une hygiène périodique. La plupart des équipes font les deux : le webhook garde les nouvelles inscriptions propres, et un passage en masse occasionnel rattrape tout ce qui est passé entre les mailles ou a vieilli.
Prêt à tout câbler ? Récupérez une clé à portée limitée et le format exact des requêtes dans la documentation développeur, testez une adresse unique dans le vérificateur d'e-mails gratuit, ou commencez avec les 100 crédits gratuits inclus dans chaque forfait pour tester le flux de bout en bout.