Détecter les emails jetables avant qu’ils ne deviennent des rebonds

Pendant un mois, le tableau de bord de croissance était superbe. Les inscriptions montaient, l’entonnoir d’essai gratuit était plein, et personne n’a remarqué qu’un cinquième des nouveaux comptes n’avait jamais ouvert un seul email.

Puis la séquence d’onboarding a commencé à rebondir. Les adresses étaient réelles au moment où on les avait saisies. Elles avaient simplement cessé d’exister une dizaine de minutes plus tard.

Les boîtes temporaires ne sont pas un indicateur de croissance

Un service d’email jetable fournit une boîte à la demande et la supprime peu après, souvent en quelques minutes. Les raisons sont compréhensibles : récupérer un téléchargement, tester un produit, ou décrocher un essai gratuit de plus sans engager une adresse à laquelle on tient.

Pour l’entreprise d’en face, chacune de ces inscriptions est un problème qui arrive en différé :

• Le compte est injoignable. Réinitialisations de mot de passe, reçus et alertes de sécurité ne vont nulle part.
• Chaque email rebondit ou disparaît, et la séquence d’onboarding continue d’essayer. Un rebond coûte plus qu’une campagne : il se paie sur la réputation du domaine d’envoi.
• Les chiffres mentent. Abus d’essais gratuits, fraude au parrainage et compteurs d’inscriptions gonflés reposent tous sur des adresses que personne ne compte garder.

Pourquoi une regex ne suffit pas

Une adresse jetable est parfaitement bien formée. anna.meyer@ suivi d’un domaine jetable passe tous les contrôles de format que vous pouvez écrire, y compris celui du validateur de formulaire de votre framework.

Le domaine est le seul indice, et il en existe des milliers. De nouveaux services apparaissent chaque mois, et les anciens enregistrent de nouveaux domaines quand ils sont bloqués.

Ce qui les détecte vraiment

La détection fonctionne par couches :

• Une liste de domaines jetables tenue à jour. Elle attrape les services connus, qui représentent l’essentiel du trafic. Elle doit évoluer au rythme des nouveaux services ; une copie collée dans votre code il y a deux ans est largement périmée.
• Un contrôle DNS. Un domaine sans serveur de messagerie ne peut recevoir aucun email, jetable ou non.
• La vérification complète de la boîte. Elle repère les adresses mal formées, sur des domaines morts ou refusées par le serveur, qui accompagnent souvent les fausses inscriptions.

BounceIntel exécute ces trois couches à chaque vérification. Un domaine jetable revient avec misc.is_disposable: true, le code de raison disposable et un is_reachable à risky. Le reste du processus est décrit dans comment fonctionne la vérification d’email.

Comment un domaine se retrouve sur une liste de jetables

Personne ne devine. Un domaine gagne ce statut en se comportant comme un service jetable, et ce sont toujours les mêmes signaux :

• Il accepte toutes les adresses. Les boîtes jetables y sont obligées, puisque l'adresse est inventée au moment où quelqu'un la tape.
• Ses enregistrements MX pointent vers une infrastructure jetable connue, souvent partagée par des dizaines de domaines d'apparence sans lien.
• Il a été enregistré il y a quelques semaines, avec protection des données du titulaire, et n'a pas de site au-delà d'une page proposant des boîtes temporaires.
• Il figure dans la liste publique de domaines que le service publie lui-même pour que ses utilisateurs choisissent une adresse d'allure différente.
• Il tourne. Quand un domaine est bloqué, l'opérateur en ajoute cinq autres et garde les mêmes serveurs.

C'est pour ce dernier point que la fraîcheur de la liste compte plus que sa taille. Une liste de 100 000 domaines copiée dans un dépôt il y a deux ans ignore tout ce qui a été créé depuis, et de nouveaux services apparaissent chaque mois.

Jetable, relais ou simplement gratuite : faire la différence

Ces trois catégories sont sans cesse confondues, et les traiter de la même façon vous coûte des clients.

Un résultat de vérification vous dit laquelle vous avez : misc.is_disposable, misc.is_role_account et le code free_provider répondent chacun à une question différente, ce qui permet une décision différente pour chacune.

Ne bloquez pas les relais de confidentialité

Certaines adresses semblent inhabituelles mais appartiennent à des personnes qui comptent bien rester : Masquer mon adresse e-mail d’Apple, les adresses duck.com de DuckDuckGo et les alias SimpleLogin transfèrent vers une vraie boîte que la personne garde pendant des années.

C’est un choix de confidentialité, pas une façon de vous éviter, et les bloquer revient à refuser précisément les clients prudents que vous voulez. BounceIntel ne signale pas ces domaines relais comme jetables.

L’intégrer à votre formulaire d’inscription

Vérifiez l’adresse côté serveur à l’envoi du formulaire, jamais depuis du code navigateur contenant votre clé, et agissez selon le résultat :

async function checkSignupEmail(email: string) {
  try {
    const res = await fetch("https://api.bounceintel.com/v1/check_email", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.BOUNCEINTEL_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
      signal: AbortSignal.timeout(3000),
    });
    const result = await res.json();

    if (result.misc?.is_disposable) return { allow: false, reason: "disposable" };
    if (result.is_reachable === "invalid") return { allow: false, reason: "invalid" };
    return { allow: true };
  } catch {
    // Fail open: never lose a real signup because a check was slow.
    return { allow: true, recheckLater: true };
  }
}

Deux décisions comptent plus que le code :

• Laisser passer en cas d’échec. Si la vérification expire, laissez la personne entrer et revérifiez l’adresse en arrière-plan. Un serveur de messagerie lent n’est pas une raison de perdre un client.
• Décider ce que risky signifie pour vous. Jetable est un type de risque. Les adresses catch-all et génériques en sont d’autres, et elles méritent en général un avertissement, pas un blocage.

Bloquer en douceur, avec des mots humains

Un sec « email invalide » pousse les gens à essayer une deuxième adresse jetable. Expliquez pourquoi vous avez besoin d’une vraie :

Cette adresse ressemble à une boîte temporaire. Utilisez une adresse que vous garderez, pour ne pas perdre l’accès à votre compte ni à vos reçus.

Gardez le formulaire rempli, placez le message à côté du champ et n’accusez personne.

Où bloquer, où avertir, où ne rien faire

Bloquer est une décision produit, pas un réglage de sécurité. La bonne réponse dépend de l'usage de l'adresse.

Quel que soit votre choix, enregistrez la décision. Un champ sur le compte indiquant que l'adresse a été signalée vaut plus, plus tard, qu'une inscription bloquée que personne ne sait expliquer.

Auditez celles que vous avez déjà

Avant de modifier le formulaire, mesurez le problème. Exportez votre table d'utilisateurs, vérifiez-la en masse, puis regroupez par domaine.

Trois choses ressortent presque toujours :

• Un classement des domaines jetables où les cinq premiers représentent l'essentiel du volume, ce qui indique s'il s'agit d'abus ou de curiosité.
• Une cohorte qui n'a jamais rien ouvert. Les comptes sur domaines jetables lisent rarement quoi que ce soit. Comparez leur activité à 30 jours au reste et vous tenez l'argumentaire.
• Une source marketing responsable de la majorité. Un jeu concours, un partenariat d'affiliation ou un téléchargement sous formulaire saute en général aux yeux.

Supprimez les adresses jetables pour que la séquence d'onboarding cesse de leur écrire, gardez les comptes si l'historique vous sert, et corrigez la source avant de refaire le même ménage au trimestre suivant. La vérification en masse traite l'export en une passe.

Essayez

Pour le parcours d’inscription complet, consultez le cas d’usage protection des inscriptions et la documentation de l’API.