Comment on a construit un dataset anti-emails jetables

Quand on parle de bloquer les faux comptes, la première étape est souvent la même : vérifier l'email. Mais pour vérifier un email jetable, encore faut-il savoir quels domaines sont jetables. Les listes publiques sur GitHub couvrent les cas les plus évidents, mais elles sont rarement à jour. De nouveaux services apparaissent chaque semaine, avec de nouveaux domaines qui passent sous le radar.

On a décidé de construire notre propre dataset chez WebAPI. Voici comment.

Pourquoi les faux comptes sont un vrai problème business

Les faux comptes ne sont pas qu'un problème technique. Ils ont un coût direct sur le business.

Du bruit dans le CRM : Chaque faux compte créé avec un email jetable atterrit dans le pipeline commercial. Les équipes sales perdent du temps à qualifier des leads qui n'existent pas (Hubspot, Salesforce, etc.), les métriques de conversion sont faussées, et le ratio signal/bruit du CRM se dégrade. Sur un SaaS avec des milliers d'inscriptions par mois, ça peut représenter des dizaines d'heures perdues.
Abus des essais gratuits et des ressources : Les emails jetables permettent à un même utilisateur de créer des comptes en boucle pour profiter indéfiniment d'un free trial, accumuler des crédits offerts ou contourner les quotas. Pour un produit API comme le nôtre, c'est de la consommation de ressources sans aucune conversion derrière.
Métriques produit polluées : Les faux comptes gonflent artificiellement les chiffres d'inscription et faussent les taux d'activation (e.g dashboard d'un mixpanel ou metabase), de rétention et de conversion. Impossible de prendre des décisions produit fiables avec des cohortes remplies de comptes fantômes.
Risques de réputation et de délivrabilité : Envoyer des emails d'onboarding à des adresses jetables, c'est envoyer dans le vide. Les bounces s'accumulent, le taux de délivrabilité chute, et la réputation de votre domaine d'envoi en prend un coup auprès des fournisseurs email.

Le problème : des fournisseurs qui bougent vite

Les services d'emails temporaires ne fonctionnent pas tous de la même manière. Certains exposent une liste fixe de domaines dans un menu déroulant. D'autres génèrent des adresses aléatoires à chaque visite, avec des domaines qui tournent. Quelques-uns injectent leurs domaines dynamiquement via JavaScript, invisibles dans le HTML brut.

Pour construire un dataset fiable, il faut s'adapter à chacun de ces comportements.

Étape 1 : collecte multi-stratégie

On cible +20 fournisseurs d'emails jetables. Pour chacun, on déploie la stratégie d'extraction la plus adaptée à son fonctionnement.

Requêtes HTTP classiques : Pour les sites qui exposent leurs domaines directement dans le HTML (menus <select>, listes, champs <input> pré-remplis), un simple appel HTTP suffit. On parse le DOM et on extrait les domaines.

Navigateurs contrôlés : Beaucoup de fournisseurs modernes chargent leur contenu via JavaScript. Le HTML statique ne contient rien d'utile. On utilise des navigateurs headless qui exécutent le JS, attendent le rendu complet, puis nous donnent accès au DOM final.

Screenshots + OCR : Certains services vont plus loin dans la protection : le domaine n'existe nulle part dans le DOM, il est rendu uniquement dans un canvas ou une image. Dans ces cas, on prend un screenshot de la page et on extrait le texte par OCR.

Appels API directs : Quand un service expose une API (publique ou semi-publique) pour générer des adresses, on l'utilise directement.

Étape 2 : extraction intelligente des domaines

Récupérer le HTML ou le screenshot ne suffit pas. Il faut encore en extraire les domaines de manière fiable. On applique plusieurs couches d'extraction en cascade :

Champs de saisie : on scanne les <input> pour repérer les adresses email pré-remplies et en extraire le domaine
Menus déroulants : les <select> contiennent souvent la liste complète des domaines disponibles
Liens et texte brut : en dernier recours, on cherche les patterns @domaine.tld dans l'ensemble du texte visible

Étape 3 : filtrage des faux positifs

C'est probablement l'étape la plus critique. L'extraction agressive produit du bruit : des domaines qui ne sont pas jetables. Sans filtrage, on risque de bloquer des utilisateurs légitimes : ce qu'on ne peut pas se permettre.

Notre pipeline applique plusieurs filtres :

Liste d'exclusion : les grands domaines légitimes (gmail.com, outlook.com, etc.) et les domaines d'infrastructure (googleapis.com, cloudflare.com, etc.) sont systématiquement exclus
Validation structurelle : on vérifie que le domaine a un format valide, un TLD reconnu, et qu'il ne ressemble pas à un fichier statique (.js, .css, .png)
Vérification DNS : on valide la présence d'enregistrements MX pour confirmer que le domaine peut effectivement recevoir des emails
Scoring de confiance : chaque domaine est associé aux sources qui l'ont remonté. Un domaine vu chez plusieurs fournisseurs indépendants est quasi certain d'être jetable

Ce filtrage multi-couches nous permet de maintenir un taux de faux positifs très bas, même avec une extraction agressive.

Étape 4 : déduplication et indexation

Les mêmes domaines apparaissent souvent chez plusieurs fournisseurs. Avant d'enrichir notre base, on fusionne les résultats : chaque domaine est normalisé, dédupliqué, et on conserve la liste de toutes ses sources.

Le résultat est indexé dans un moteur de recherche optimisé pour les requêtes en temps réel. Quand notre API reçoit une requête de validation, le lookup sur ce dataset prend moins d'une milliseconde.

Étape 5 : monitoring et mises à jour continues

Le paysage des emails jetables évolue constamment. Des domaines disparaissent, d'autres apparaissent. On exécute ce pipeline automatiquement et régulièrement pour capter ces changements.

Chaque exécution produit un rapport : nombre de fournisseurs traités, domaines découverts, erreurs éventuelles. Si un fournisseur change son interface ou bloque nos requêtes, on est alertés immédiatement et on adapte notre stratégie.

Les chiffres

Aujourd'hui, notre dataset contient plus de 380 000 domaines jetables vérifiés, issus de +20 fournisseurs différents. Il alimente directement le champ disposable de notre API Email Validation.

Ce que ça change pour vous

Quand vous appelez GET /v1/intelligence/email avec une adresse, le champ disposable est vérifié contre ce dataset en temps réel. Pas une liste statique téléchargée il y a six mois : un dataset vivant, mis à jour chaque jour par des pipelines automatisés.

import requests

response = requests.get(
    "https://api.veille.io/v1/intelligence/email",
    params={"query": "user@guerrillamail.com"},
    headers={"x-api-key": "YOUR_API_KEY"},
)
data = response.json()

if data["disposable"]:
    print(f"Email jetable détecté (risque : {data['risk_score']})")

Bloquer les emails jetables, c'est couper le premier levier des attaquants pour créer des faux comptes en masse. Et ça commence par un dataset qui tient la route.