API de détection des e-mails jetables : stop aux fausses inscriptions

Tout faux compte commence souvent de la même façon : par une boîte mail qui n’existera plus demain. Les services d’e-mails jetables fournissent des adresses juste assez longtemps pour cliquer sur un lien de confirmation — dix minutes, parfois moins — avant de disparaître, avec toute possibilité de recontacter cet utilisateur.

Pour une entreprise SaaS, cette simple adresse peut devenir la porte d’entrée du farming d’essais gratuits, de la fraude au parrainage, de l’abus de promotions ou de comptes temporaires utilisés pour spammer.

Une API de détection des e-mails jetables sert à répondre à une question précise, au moment où elle compte vraiment — lors de l’inscription : cette adresse appartient-elle à un fournisseur de boîtes mail temporaires ?

Pourquoi les adresses jetables sont un signal de fraude

Une adresse jetable n’est pas automatiquement malveillante. Certains utilisateurs soucieux de leur vie privée utilisent une boîte temporaire lorsqu’ils ne font pas encore confiance à un service, et c’est un choix légitime. Mais à grande échelle, le signal devient difficile à ignorer :

• Abus d’essais gratuits. Une personne, trente essais. Chaque essai demande une nouvelle adresse, et les fournisseurs d’e-mails jetables en créent à la chaîne.
• Fraude au parrainage et aux promotions. Les auto-parrainages ne fonctionnent que si chaque « ami » possède une adresse unique. Les boîtes temporaires sont la source la moins chère.
• Comptes abusifs jetables. Spam, scraping, harcèlement : ces comptes sont plus simples à remplacer qu’à préserver, donc ils reposent sur des adresses que personne ne compte garder.
• Dégradation des listes. Les adresses jetables génèrent des hard bounces en quelques heures. Chacune qui entre dans votre base e-mail nuit à votre réputation d’expéditeur, sans aucun bénéfice en retour.

Le point commun est simple : l’utilisateur ne cherche pas à construire une relation durable. Selon votre produit, cela peut justifier un blocage, une vérification supplémentaire ou un simple marquage du compte. Mais impossible de choisir la bonne réaction sans disposer du signal.

Ce qu’une API de détection vérifie réellement

Le fonctionnement est volontairement simple, parce que la simplicité va vite :

• Extraction du domaine. Seule la partie après le @ compte. Un bon service compare les domaines et ne stocke jamais l’adresse complète : la partie locale est une donnée personnelle dont vous n’avez pas besoin.
• Comparaison avec une base de domaines jetables. Des dizaines de milliers de domaines exploités par des services de temp-mail, des boîtes temporaires et des réseaux d’alias rotatifs.
• Retour d’un verdict. disposable: true ou false, avec le domaine détecté et un horodatage. Un appel, un champ exploitable immédiatement.

Une intégration classique ressemble à ceci :

bash curl "https://guarda.net/api/public/v2/email/newuser@mailinator.com?key=YOUR_API_KEY"

{ "status": "ok", "email": "newuser@mailinator.com", "domain": "mailinator.com", "disposable": true, "checked_at": "2026-08-23T12:00:00.000Z" }

Comme la vérification se résume à un appel HTTP, elle s’intègre partout : gestionnaire de formulaire d’inscription, endpoint de paiement, capture newsletter ou traitement batch pour auditer une liste existante.

Le problème des faux positifs dont personne ne parle

Voici la partie moins confortable de cette catégorie d’outils : les blocklists publiques utilisées par beaucoup de détecteurs sont souvent bruitées. Plusieurs flux open source très répandus mélangent de vrais services de messagerie gratuits avec des fournisseurs d’adresses temporaires. Si vous les consommez tels quels, vous finirez par dire à un vrai client, avec une vraie boîte mail, que son adresse est « jetable » — et vous le perdrez au moment précis où il essayait de vous faire confiance.

La bonne réponse n’est pas cosmétique, elle est architecturale : une allowlist prioritaire en toutes circonstances. Les fournisseurs légitimes vérifiés — grands services de freemail, opérateurs régionaux, FAI, universités — doivent être épinglés dans une allowlist recoupée avec des classements de trafic indépendants. Lorsqu’un flux signale à tort l’un de ces domaines, l’allowlist prend le dessus. La qualité d’une détection ne se mesure pas seulement au nombre de domaines bloqués, mais à la confiance avec laquelle vous pouvez affirmer que les domaines autorisés sont bien légitimes.

La fraîcheur de la donnée est tout aussi cruciale. Les opérateurs de temp-mail font tourner leurs domaines précisément pour échapper aux listes statiques : une base téléchargée le mois dernier est déjà périmée là où elle compte le plus. Cherchez un fournisseur qui synchronise quotidiennement plusieurs sources et conserve la provenance de chaque domaine, afin de pouvoir auditer pourquoi un verdict a été rendu, pas seulement quel verdict a été retourné.

Intégrer sans nuire à la conversion

La pire manière d’utiliser une détection d’e-mail jetable consiste à bloquer tous les verdicts positifs et à afficher une impasse. Un meilleur modèle, du moins intrusif au plus strict :

• Marquer silencieusement. Enregistrez le signal sur le compte et utilisez-le dans vos décisions ultérieures — par exemple, un compte non vérifié avec adresse jetable ne reçoit pas de bonus de parrainage.
• Demander une vérification. Exigez la validation de l’e-mail avant de délivrer de la valeur : accès à l’essai, code promo, clé API. Les vrais utilisateurs le font en quelques secondes ; les fraudeurs abandonnent souvent.
• Bloquer avec une explication. Réservez le rejet ferme aux contextes où une adresse jetable n’est jamais acceptable — paiements, facturation, essais B2B — et expliquez toujours pourquoi, avec un chemin vers le support.

Et surtout, combinez les signaux. Une adresse jetable associée à une IP de datacenter n’a pas du tout la même signification qu’une adresse jetable utilisée depuis une connexion résidentielle. L’intelligence e-mail et l’intelligence IP répondent à deux moitiés de la même question ; elles ont donc leur place dans le même flux de décision, plutôt que dans des outils séparés.

Ce que la détection ne peut pas faire

Être clair sur les limites évite les fausses certitudes. Une vérification fondée sur le domaine ne peut pas détecter :

• Les domaines personnalisés sur une infrastructure jetable. Un service de burner sur un domaine neuf, encore inconnu des listes, passera jusqu’à sa découverte. C’est une course à la détection, pas un problème définitivement résolu.
• Les alias de type Gmail. name+anything@gmail.com et les variantes avec points mènent à la même boîte. C’est un sujet de déduplication dans votre base de données, pas de détection d’e-mail jetable.
• Les humains déterminés. Quelqu’un prêt à enregistrer un vrai domaine et à recevoir de vrais e-mails passera. L’objectif n’est pas la perfection, mais de rendre l’abus plus coûteux que ce qu’il rapporte.

La détection des e-mails jetables est une couche de protection. Associée à des signaux de risque IP et à des parcours de vérification bien conçus, elle élimine la catégorie la moins chère et la plus massive de fausses inscriptions : les comptes automatisés. Et, dans la plupart des cas, c’est déjà l’essentiel du problème.

Vous pouvez tester n’importe quelle adresse dès maintenant avec le vérificateur gratuit d’e-mails jetables sur guarda.net, sans compte, puis brancher l’API dans votre flux d’inscription lorsque vous serez prêt à l’appliquer.