Skip to content
Commencez avec 100 crédits de vérification gratuits
Qualisend
Tous les articles
Guides / 15 mai 2026

Comment vérifier les e-mails issus de Jotform

9 minutes read

Qualisend team
Schéma de flux : une soumission Jotform envoie une requête POST vers votre webhook, qui appelle l'API de vérification Qualisend et oriente l'adresse selon un verdict délivrable, à risque ou non délivrable.

Jotform est un moyen rapide de présenter un formulaire à vos visiteurs et de collecter leurs adresses e-mail — et, comme tout créateur de formulaires, il est meilleur pour capturer des adresses que pour vous dire lesquelles sont réelles. Son champ e-mail confirme qu'une adresse a l'air correcte ; il ne peut pas confirmer que la boîte de réception existe, qu'il ne s'agit pas d'une adresse jetable, ni que votre première réponse ne rebondira pas durement. Ce guide présente deux méthodes concrètes pour vérifier les e-mails issus de Jotform avec Qualisend : en temps réel, avec un webhook qui se déclenche à l'instant même où une soumission arrive, et en masse, en exportant vos soumissions vers un tableur. Aucune des deux ne nécessite de plugin natif — il n'y en a pas encore — juste les webhooks intégrés de Jotform 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 Jotform vers une petite fonction serverless. À chaque soumission, Jotform envoie les données du formulaire en POST vers votre point de terminaison ; la fonction lit l'e-mail, appelle l'API Qualisend et agit selon le verdict — étiqueter le contact, l'orienter vers la bonne liste ou suspendre l'e-mail de bienvenue pour une adresse non valide.
  • En masse — exportez vos soumissions existantes au format CSV ou Excel, passez-les dans la vérification groupée de Qualisend et supprimez les adresses non délivrables avant votre prochain envoi.

Pourquoi le champ e-mail de Jotform ne suffit pas#

Le type de question e-mail de Jotform effectue un contrôle de format dans le navigateur — il vérifie la présence d'un @, d'un domaine et l'absence de fautes de frappe évidentes. C'est la même catégorie de contrôle qu'une regex, et il é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 test@mailinator.com, et tout comme une adresse d'apparence réelle sur un domaine qui s'est éteint discrètement l'an dernier.

Aucune de ces adresses n'est détectée avant l'envoi — et à ce moment-là, une adresse morte devient un rebond dur qui grignote votre taux de rebond et votre réputation d'expéditeur. Une vraie vérification ajoute les couches que Jotform ne peut pas fournir : une recherche DNS/MX et un sondage SMTP de la boîte de réception, ainsi que des signalements pour les adresses jetables, génériques et catch-all. Si ce processus vous est nouveau, ce que la vérification d'e-mails contrôle réellement en est l'introduction.

Deux façons de vérifier les e-mails issus de Jotform#

D'abord la contrainte importante : Jotform ne peut pas bloquer de manière fiable un e-mail non valide en cours de formulaire. Il n'existe aucune méthode prise en charge, quel que soit le forfait, pour appeler une API externe entre les champs et empêcher quelqu'un de soumettre. La vérification en temps réel s'exécute donc juste après la soumission, dans un webhook — et non comme un filtre en ligne. Cela façonne les deux voies.

VoieQuand elle s'exécuteIdéale pour
Webhook en temps réelInstantanément, à chaque soumissionTunnels en direct — étiqueter, orienter ou suspendre le suivi avant son envoi
Export groupéÀ la demande, par lotsArriérés de soumissions existants et hygiène périodique des listes

Voie 1 : temps réel avec un webhook Jotform#

Jotform peut envoyer chaque soumission vers une URL que vous contrôlez. Ouvrez votre formulaire et rendez-vous dans Settings → Integrations, recherchez Webhooks et collez l'URL de votre point de terminaison. Contrairement à certains outils de formulaire qui réservent les webhooks à leurs offres les plus élevées, l'intégration Webhooks de Jotform est disponible largement, y compris sur le forfait gratuit — c'est votre nombre mensuel de soumissions qui est plafonné selon le forfait, pas l'accès au webhook lui-même.

Une particularité propre à Jotform façonne le code : Jotform n'envoie pas du JSON propre. Il transmet la soumission sous forme de champs encodés en form-encoded, où chaque réponse porte le nom de sa question — un champ e-mail arrive généralement sous une forme telle que q3_email. Il existe aussi un champ rawRequest qui contient une chaîne JSON de l'ensemble de la soumission si vous préférez analyser celle-ci. Dans les deux cas, votre point de terminaison lit le corps du formulaire, pas req.json().

Votre point de terminaison est une fonction serverless qui détient la clé d'API et transforme le verdict en action. Le principe est le même que celui du guide de vérification à l'inscription : la clé reste côté serveur, et vous agissez sur le résultat. Le voici sous la forme d'un Route Handler Next.js (consultez la documentation développeur pour le chemin exact du point de terminaison et la structure de la requête) :

// app/api/jotform-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) {
  // Jotform POSTs form-encoded fields, not JSON.
  const form = await req.formData();

  // Jotform names email fields like q3_email — check yours in the builder.
  const email = form.get("q3_email")?.toString();
  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 submission already landed — 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 : Jotform attend un 2xx rapidement, alors gardez le gestionnaire léger et renvoyez la réponse sans tarder. Échouez en mode ouvert (fail open) : si l'API expire ou renvoie une erreur, ne perdez pas le lead — acceptez-le et revérifiez-le plus tard, ce qui explique pourquoi la branche !res.ok renvoie tout de même ok: true. Et protégez le point de terminaison : Jotform ne signe pas ses webhooks avec un secret partagé comme le font certains outils, alors protégez l'URL autrement — gardez-la impossible à deviner et rejetez tout élément dont le formID ne correspond pas au formulaire attendu, avant de dépenser un crédit de vérification.

Si votre formulaire comporte plus d'une question e-mail, ne vous contentez pas de prendre la première que vous trouvez — lisez le nom de champ précis (q7_email, q12_workEmail, quel que soit celui attribué par le concepteur) afin que la bonne adresse soit toujours celle que vous vérifiez. Vous pouvez voir le nom de chaque champ dans le concepteur Jotform ou en inspectant une fois la charge utile d'une soumission de test.

En aval, le verdict n'est qu'une bifurcation. Un résultat deliverable s'écoule directement vers votre CRM ou votre outil d'e-mailing ; un résultat undeliverable ou disposable est étiqueté, retiré de la séquence de bienvenue ou placé dans une file de contrôle — selon les besoins de votre processus. Le webhook, c'est la tuyauterie ; l'aiguillage, c'est le vôtre.

La logique de vérification en elle-même est indépendante du langage ; le même appel fonctionne depuis une fonction Python ou PHP si c'est votre stack, et la même approche par webhook s'applique à n'importe quel outil de formulaire — voyez vérifier les e-mails issus de Typeform pour une configuration quasi identique, où la seule véritable différence tient à la façon dont la charge utile est analysée. Seule cette étape d'analyse est spécifique à Jotform ; la moitié « vérifier et aiguiller » est la même partout.

Voie 2 : vérifier en masse un export CSV ou Excel#

Si vous disposez déjà d'un tas de soumissions, ou si vous préférez nettoyer selon un calendrier plutôt que de câbler un webhook, procédez par lots. Dans Jotform, ouvrez le tableau des Submissions de votre formulaire (ou Reports → Excel/CSV) et téléchargez les données. Vous obtiendrez une ligne par soumission, avec l'e-mail dans sa propre colonne.

Ensuite :

  1. Importez le fichier dans la vérification groupée de Qualisend et laissez-la exécuter l'ensemble du processus — MX, SMTP et les signalements jetable/générique/catch-all — sur chaque ligne.
  2. Téléchargez le fichier annoté. Chaque adresse revient accompagnée d'un status, d'un code reason et d'un score de 0 à 100.
  3. Supprimez les adresses non délivrables dans l'outil depuis lequel vous envoyez réellement vos e-mails, et traitez les lignes à risque avec précaution. La procédure de bout en bout, y compris la place de chaque statut, se trouve dans comment nettoyer une liste d'e-mails.

L'export groupé est l'outil adapté à un arriéré, mais c'est du nettoyage, pas de la prévention : une adresse que vous détectez ici traîne généralement déjà dans votre liste depuis un moment. Associez un passage groupé périodique au webhook en temps réel pour que les nouvelles adresses non valides soient signalées dès leur arrivée.

Agir selon le verdict#

Quelle que soit la voie qui livre le résultat, sa structure est la même — un status, un reason, un score et les sub_flags. Associez chacun à une action :

RésultatQue faire
deliverableAccepter — ajouter à votre liste et envoyer normalement.
undeliverableSupprimer. N'envoyez pas ; consultez le reason pour savoir s'il s'agit d'un domaine non valide ou d'une boîte de réception morte.
signalement disposableRejeter ou étiqueter, selon le degré de rigueur de votre tunnel — voyez adresses génériques, jetables & gratuites.
risky / catch-allAccepter mais segmenter. Un domaine catch-all accepte toutes les adresses au niveau du MX, il ne peut donc pas confirmer la boîte de réception individuelle — envoyez avec prudence.
unknownAccepter et revérifier plus tard — l'infrastructure n'a pas répondu, ne laissez donc jamais tomber un lead réel à cause de cela.

Foire aux questions#

Jotform peut-il vérifier les adresses e-mail par lui-même ?#

Uniquement le format. Le champ e-mail de Jotform confirme qu'une adresse est bien formée — qu'elle comporte un @ et un domaine — mais il ne résout pas les enregistrements MX et ne sonde pas la boîte de réception. Une adresse mal orthographiée ou jetable qui a l'air valide passe donc quand même. Une vraie vérification exige les couches DNS et SMTP qu'un service comme Qualisend ajoute par-dessus, et c'est précisément ce qui transforme « a l'air valide » en « sera réellement délivré ».

Faut-il un forfait Jotform payant pour vérifier les e-mails en temps réel ?#

Pas nécessairement. L'intégration Webhooks de Jotform est disponible sur l'ensemble de ses forfaits, y compris l'offre gratuite. Vous pouvez donc mettre en place la voie temps réel sans passer à un forfait supérieur — ce qui varie selon le forfait, c'est votre quota mensuel de soumissions, pas l'accès aux webhooks. Si vous préférez ne pas héberger de point de terminaison du tout, optez plutôt pour la voie groupée : exportez vos soumissions au format CSV ou Excel et vérifiez-les par lots, sur n'importe quel forfait qui vous permet de télécharger vos résultats.

Puis-je bloquer un e-mail non valide avant que l'utilisateur ne termine le formulaire ?#

Pas de manière fiable. Jotform ne propose aucune méthode prise en charge, quel que soit le forfait, pour appeler une API externe en cours de formulaire et empêcher quelqu'un de soumettre. La vérification en temps réel s'exécute donc juste après la soumission, dans le webhook. En pratique, cela convient parfaitement : vous vérifiez en quelques secondes et agissez avant même que l'adresse ne reçoive le moindre message — vous suspendez l'e-mail de bienvenue, étiquetez le contact ou l'orientez vers une file de contrôle, plutôt que de bloquer le formulaire lui-même.

Faut-il utiliser le webhook en temps réel ou l'export groupé ?#

Utilisez le webhook lorsque le moment compte — vous voulez accueillir, orienter ou supprimer chaque soumission au fur et à mesure qu'elle arrive. Utilisez l'export groupé lorsque vous nettoyez un arriéré ou effectuez une hygiène périodique. La plupart des équipes font les deux : le webhook maintient les nouvelles soumissions propres, et un passage groupé occasionnel rattrape tout ce qui a échappé au contrôle ou s'est dégradé depuis sa collecte.


Prêt à tout mettre en place ? Récupérez une clé à portée limitée et le format exact de la requête dans la documentation développeur, validez une seule adresse dans le vérificateur d'e-mails gratuit, ou commencez avec les 100 crédits gratuits offerts sur chaque forfait pour tester le flux de bout en bout.

Your reputation, protected.

Clean your first list in minutes. 100 free credits, no card required.

Get started