Vérifier l'e-mail à l'inscription avec une fonction serverless

Le rebond le moins coûteux est celui qui n'entre jamais dans votre liste. Vérifier une adresse au moment même où quelqu'un la saisit — dans une fonction serverless derrière votre formulaire d'inscription — arrête les fautes de frappe, les domaines morts et les adresses jetables dès l'entrée, au lieu de payer pour les nettoyer plus tard et d'encaisser la perte de délivrabilité entre-temps. Ce guide présente le schéma avec un route serverless fonctionnel.

La réponse courte#

Placez la vérification dans une fonction côté serveur que votre formulaire d'inscription appelle : elle détient votre clé API, appelle POST /verify et agit sur le verdict local immédiat — rejetez undeliverable, proposez la correction did_you_mean, signalez disposable et laissez passer tout le reste. Deux règles font toute la différence : n'appelez jamais l'API depuis le navigateur (la clé doit rester côté serveur) et ne bloquez jamais une inscription quand l'API est lente ou hors service (basculement souple).

Pourquoi à l'inscription, et pas plus tard#

La vérification à la capture, c'est de la prévention ; nettoyer une liste, c'est du rattrapage, et la prévention l'emporte sur tous les plans. Une faute de frappe interceptée au clavier, c'est un abonné sauvé grâce à une correction en une ligne. Un domaine mort rejeté à l'inscription ne devient jamais un rebond dur qui entame votre taux de rebond. Une adresse jetable bloquée dès l'entrée ne dilue jamais vos indicateurs ni votre facture. La même adresse retrouvée lors d'un nettoyage de liste trois mois plus tard vous a déjà coûté un envoi, un rebond et une parcelle de réputation d'expéditeur.

Le schéma#

Trois pièces mobiles :

1. Le formulaire envoie l'adresse à votre propre endpoint — jamais directement à l'API de vérification, car cela exposerait votre clé.
2. Une fonction serverless détient la clé dans une variable d'environnement, appelle POST /verify et transforme le résultat en décision.
3. Votre logique d'inscription agit sur la décision : rejeter, suggérer une correction ou accepter.

Un route serverless#

Le voici sous forme de Route Handler de l'App Router Next.js, qui se déploie comme une fonction serverless sur Vercel. La clé vit dans QUALISEND_API_KEY ; le client ne la voit jamais :

// app/api/validate-email/route.ts
import { NextResponse } from "next/server";

const BASE = "https://app.qualisend.com/api/v1";

export async function POST(req: Request) {
  const { email } = await req.json();

  try {
    const res = await fetch(`${BASE}/verify`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.QUALISEND_API_KEY!}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
      signal: AbortSignal.timeout(4000), // don't let a slow probe stall signup
    });

    // On any API error, fail open — a real user must not be blocked by our outage.
    if (!res.ok) return NextResponse.json({ ok: true, degraded: true });

    const { result } = await res.json();

    if (result.status === "undeliverable") {
      return NextResponse.json({
        ok: false,
        reason: result.reason,          // invalid_email | invalid_domain | rejected_email
        suggestion: result.did_you_mean, // e.g. "jane@gmail.com"
      });
    }
    if (result.sub_flags?.disposable) {
      return NextResponse.json({ ok: false, reason: "disposable" });
    }

    // deliverable, risky, or unknown — accept, but pass along a typo suggestion if any
    return NextResponse.json({ ok: true, status: result.status, suggestion: result.did_you_mean });
  } catch {
    return NextResponse.json({ ok: true, degraded: true }); // timeout or network error → fail open
  }
}

Stockez la clé avec l'outillage d'environnement de votre plateforme (vercel env add QUALISEND_API_KEY) et elle est injectée à l'exécution — jamais intégrée au bundle client.

Agir sur le verdict#

Le result immédiat est le verdict local (syntaxe, DNS, jetable, rôle, faute de frappe), ce qui est exactement ce que vous voulez à l'inscription — rapide, et suffisant pour décider :

Basculement souple, toujours#

Le seul point non négociable : si l'appel de vérification échoue, expire ou renvoie un code non-2xx, laissez passer l'inscription. Une API de vérification est un filtre de qualité, pas une porte d'authentification, et bloquer un client payant à cause d'une panne passagère est une issue bien pire que de laisser entrer une adresse douteuse. La branche !res.ok et le catch ci-dessus renvoient tous deux ok: true précisément pour cette raison. Journalisez les inscriptions dégradées et interceptez-les lors de votre prochain nettoyage de liste.

Foire aux questions#

La vérification à l'inscription ralentit-elle le formulaire ?#

À peine, si vous vous y prenez bien. Le verdict local revient rapidement, et le délai d'expiration de 4 secondes ci-dessus plafonne le pire des cas — au-delà duquel vous basculez en mode souple et acceptez tout de même l'inscription. Les utilisateurs obtiennent des corrections « vouliez-vous dire » quasi instantanées ; ils n'attendent jamais un serveur de messagerie lent, car vous agissez sur le résultat local immédiat, sans interroger le test SMTP.

Dois-je bloquer les adresses e-mail jetables à l'inscription ?#

Cela dépend de votre produit. Pour un service payant ou sensible à la réputation, bloquer les adresses jetables dès l'entrée en vaut la peine — leurs propriétaires n'ont jamais eu l'intention d'avoir de vos nouvelles à nouveau. Pour une inscription grand public à faible friction, les signaler pour un examen ultérieur peut être préférable à l'ajout de friction. Le route ci-dessus les rejette ; assouplissez-le en simple signalement si cela convient à votre entonnoir.

Ai-je besoin du résultat complet confirmé par SMTP à l'inscription ?#

Généralement non. Le verdict local immédiat intercepte la majeure partie des mauvaises inscriptions — fautes de frappe, domaines morts, adresses jetables — sans attente. Réservez le résultat complet confirmé par SMTP (via GET /jobs ou une tâche en masse) au nettoyage de liste, où la latence n'a pas d'importance et où intercepter chaque boîte aux lettres morte compte.

Comment garder ma clé API secrète ?#

N'appelez l'API de vérification que depuis du code côté serveur — une fonction serverless, un route handler ou un backend — et stockez la clé dans une variable d'environnement, jamais dans du JavaScript côté client. Si la clé se retrouve dans le bundle du navigateur, elle est au mauvais endroit.

Prêt à mettre tout cela en place ? Le plan gratuit inclut 100 crédits pour tester le flux, et la référence de l'API présente l'endpoint /verify avec des exemples prêts à copier-coller dans sept langages.