Liste des fournisseurs d'e-mails jetables (2026) pour la validation des données B2B

Les adresses e-mail jetables existent pour une raison légitime — personne n'a envie de confier une identité permanente à chaque formulaire du web — et elles créent un vrai problème opérationnel pour quiconque entretient une base de contacts. Ce guide explique ce que sont les fournisseurs d'e-mails jetables, comment leur détection fonctionne réellement, pourquoi maintenir une liste statique est la plus faible des méthodes disponibles, et comment bâtir une approche de détection qui continue de fonctionner à mesure que de nouveaux fournisseurs apparaissent.

EN BREF / À RETENIR

• Une adresse jetable est une boîte aux lettres réelle et délivrable, à durée de vie courte. Elle passe généralement les contrôles de syntaxe, les contrôles MX et la vérification SMTP : c'est pourquoi la validation d'e-mail classique la laisse passer.
• Les listes de domaines se périment vite. Les fournisseurs font tourner des centaines, voire des milliers de domaines alias, et toute liste tenue à la main est obsolète en quelques semaines.
• L'enregistrement MX est le signal le plus durable. Les domaines alias changent en permanence ; les serveurs de messagerie derrière eux beaucoup moins souvent. Classer par MX permet donc d'attraper des domaines qu'aucune liste ne contient encore.
• Les listes open source sont le bon point de départ, pas la ligne d'arrivée : les dépôts maintenus par la communauté offrent une large couverture gratuitement et sont mis à jour en continu.
• Bloquer est une décision produit, pas une décision données. Bloquer sèchement les domaines jetables à l'inscription revient aussi à bloquer des utilisateurs légitimes soucieux de leur vie privée. Scorer et conditionner vaut généralement mieux que rejeter.
• Ce que les données de zone apportent : les packages de zone enrichis contiennent l'enregistrement MX de chaque domaine, ce qui permet de repérer tous les domaines d'un TLD partageant l'infrastructure de messagerie d'un fournisseur jetable connu.
• Ce que contiennent les packages : Le format de téléchargement dépend du package et figure sur la page produit. Aucune adresse e-mail ni donnée de contact personnelle, quelle qu'elle soit.

Sommaire

• Ce que sont les fournisseurs d'e-mails jetables et pourquoi les listes se périment
• Les méthodes de détection, classées par durabilité
• Une liste de départ des fournisseurs les plus connus
• Construire un jeu de détection basé sur le MX à partir des données de zone
• Erreurs fréquentes en validation d'e-mails
• Questions fréquentes
• Conclusion
• Ressources associées

Ce que sont les fournisseurs d'e-mails jetables et pourquoi les listes se périment

Une adresse e-mail jetable — dite aussi temporaire ou éphémère — est une boîte aux lettres qu'un service crée à la demande, le plus souvent sans inscription, puis supprime au bout de quelques minutes ou de quelques jours. L'utilisateur obtient une boîte de réception dans son navigateur, reçoit le message de confirmation et ne revient jamais. Certains fournisseurs proposent des boîtes publiques, où toute adresse du domaine est lisible par quiconque la devine ; d'autres génèrent des alias privés qui redirigent vers une véritable boîte que le destinataire possède déjà.

Le détail décisif, pour quiconque écrit du code de validation, est qu'il s'agit de boîtes réelles et fonctionnelles. Le domaine possède des enregistrements MX valides, le serveur de messagerie accepte le courrier pour l'adresse et la vérification SMTP aboutit. La validation syntaxique passe, la validation DNS passe, les contrôles d'existence de la boîte passent. Rien dans la boîte à outils de validation standard ne distingue une adresse jetable d'une adresse permanente, car au niveau du protocole il n'y a aucune différence. La détection consiste donc à identifier le fournisseur, pas à tester l'adresse.

C'est là que réside la difficulté. Un même service d'e-mails jetables exploite généralement des dizaines, voire des milliers de domaines alias, qui existent précisément pour que le blocage au niveau du domaine ne fonctionne pas. Les domaines tournent, sont retirés dès qu'ils atterrissent sur des listes de blocage publiques, et sont remplacés par des domaines fraîchement enregistrés. Une liste compilée à la main il y a trois mois ne contient déjà plus les domaines enregistrés depuis — et les fournisseurs savent parfaitement comment ces listes sont constituées.

Il vaut aussi la peine d'être précis sur l'ampleur du problème plutôt que de répéter un pourcentage spectaculaire. La proportion d'adresses jetables varie énormément d'un produit à l'autre : une application grand public offrant une récompense immédiate à l'inscription observe un taux radicalement différent de celui d'un outil B2B exigeant un e-mail professionnel et une démo planifiée. Mesurez votre propre taux avant de concevoir une réponse. Tout chiffre cité sans source ni méthodologie — y compris dans les articles consacrés au sujet — doit être considéré comme purement décoratif.

Besoin de données MX sur tout un TLD ?
Les packages de zone enrichis incluent l'enregistrement MX de chaque domaine de la zone.
Parcourir les datasets → | Voir les tarifs →

Les méthodes de détection, classées par durabilité

Les approches de détection résistent très inégalement à un fournisseur qui cherche activement à les contourner. Voici les principales, à peu près par ordre de durabilité :

1. Classification par MX (la plus durable)

Les domaines alias coûtent peu et sont jetables ; l'infrastructure de messagerie, non. Un fournisseur exploitant deux mille domaines les pointe généralement tous vers la même poignée de serveurs de messagerie. En résolvant l'enregistrement MX du domaine de l'adresse et en comparant l'hôte de messagerie à une infrastructure jetable connue, vous attrapez des domaines enregistrés le matin même et absents de toutes les listes.

C'est la méthode dans laquelle il vaut le plus la peine d'investir, et c'est celle que les données de zone enrichies prennent directement en charge, puisque le MX est une colonne du fichier. La procédure de construction est décrite dans la section suivante.

2. Listes open source maintenues par la communauté

Plusieurs dépôts publics recensent les domaines jetables et acceptent des contributions en continu — le projet disposable-email-domains, très utilisé, est le point de départ habituel, et la plupart des validateurs commerciaux s'alimentent à des sources comparables. La couverture est large, le prix est nul et la mise à jour tient en un git pull. La faiblesse est structurelle : une liste est toujours en retard sur les domaines les plus récents, et un domaine qui a cessé d'être jetable en est rarement retiré.

Utilisez-en une comme socle, en attendant d'elle qu'elle couvre la longue traîne des fournisseurs bien connus plutôt que les tout derniers apparus.

3. API de validation commerciales

Les validateurs payants combinent correspondance de listes, classification par MX, sondage SMTP et signaux comportementaux issus du trafic de toute leur base clients — ce dernier apport est celui que vous ne pouvez pas reproduire. C'est le choix pragmatique pour filtrer les inscriptions en temps réel, quand il vous faut une réponse en cent millisecondes sans avoir à maintenir la chaîne de traitement vous-même. Les coûts augmentent avec le nombre de contrôles, et la classification diffère à la marge d'un fournisseur à l'autre : testez-en deux sur le même échantillon avant de vous engager.

4. Heuristiques d'enregistrement et d'infrastructure

Faibles isolément, utiles en agrégat. Un domaine enregistré il y a quelques jours, résolvant vers un réseau d'hébergement riche en sites éphémères, sans contenu web et avec des serveurs de noms génériques, a plus de chances d'être une infrastructure jetable qu'un domaine de quinze ans doté d'un vrai site. Traitez ces éléments comme des entrées d'un score, jamais comme une règle de rejet à eux seuls — toute nouvelle entreprise légitime a elle aussi un domaine enregistré il y a quelques jours.

5. Listes de blocage statiques tenues à la main (la moins durable)

L'approche par défaut, et celle qui échoue le plus vite. On ajoute une entrée quand un collègue remarque un rebond ; on ne retire jamais rien ; personne n'est responsable du fichier. En quelques mois, ce n'est plus un dispositif de contrôle mais une pièce d'archive. Si c'est votre approche actuelle, la remplacer par une liste open source mise à jour automatiquement est le changement le plus rentable à votre portée.

Que faire d'un résultat positif

Détection et politique sont deux décisions distinctes. Bloquer sèchement tout domaine jetable à l'inscription écarte aussi des utilisateurs soucieux de leur vie privée qui auraient converti, et ils sont nombreux. Les compromis courants : autoriser l'inscription mais suspendre les actions irréversibles tant que l'adresse n'est pas confirmée ; exiger une vérification avant de prolonger un essai ; laisser passer les inscriptions depuis un domaine jetable mais les exclure des campagnes de réengagement payantes. Pour les listes de prospection B2B, le calcul est plus simple : une adresse jetable rebondira ou ne sera jamais lue, donc la retirer avant l'envoi protège votre délivrabilité sans aucun inconvénient réel.

Une liste de départ des fournisseurs les plus connus

Voici des services d'e-mails jetables anciens et largement connus. C'est un point de départ pour tester votre logique de détection, pas une liste de blocage exhaustive : chacun d'eux exploite d'autres domaines alias, et de nouveaux fournisseurs apparaissent en permanence.

Cette dernière ligne compte plus qu'il n'y paraît. Les services d'alias de redirection sont massivement utilisés par des personnes soucieuses de leur vie privée qui veulent réellement recevoir le courrier, et l'adresse reste généralement valide pendant des années. Les mettre dans le même sac que les boîtes publiques éphémères vous coûtera de vrais utilisateurs. Donnez-leur leur propre catégorie et leur propre politique.

Construire un jeu de détection basé sur le MX à partir des données de zone

L'objectif est d'obtenir une liste des hôtes de messagerie associés aux fournisseurs jetables, ainsi que tous les domaines d'une zone qui pointent vers eux. Cet ensemble est bien plus durable qu'une liste de domaines, car il survit à la rotation des alias.

Étape 1 — Récupérez les données MX des zones qui vous intéressent. Les packages de zone enrichis incluent l'enregistrement MX de chaque domaine. Parcourez /zones/ pour les 716 fichiers de zone par TLD et leurs versions enrichies, avec le nombre de lignes affiché avant achat, et /datasets/ pour les 27 collections inter-zones sélectionnées. Le catalogue complet de 1 538 packages se trouve sur /packages/. Les packages démarrent à $3.50 et se téléchargent immédiatement au format ZIP, exportés à l'instant même de l'achat. L'offre Pro est à $29/month (50 packages, 10 datasets, 30 000 appels API) ; l'offre Enterprise à $99/month (200 packages, 50 datasets, 300 000 appels API) — voir /pricing/.

Étape 2 — Décompressez et vérifiez le schéma.

unzip com-enriched.zip
head -3 com-enriched.csv
# domain,ns,mx,ip,cms

Étape 3 — Amorcez avec des domaines de fournisseurs connus. Partez d'une liste open source de domaines jetables et du tableau ci-dessus, puis placez les domaines dans un fichier :

curl -sL https://raw.githubusercontent.com/disposable-email-domains/disposable-email-domains/master/disposable_email_blocklist.conf \
  > seed-domains.txt
wc -l seed-domains.txt

Étape 4 — Extrayez les hôtes de messagerie utilisés par ces domaines. Joignez la liste d'amorçage au fichier de zone pour collecter les valeurs MX, qui deviennent votre empreinte d'infrastructure :

-- mail hosts used by known disposable domains, most common first
SELECT z.mx, count(*) AS domains
FROM read_csv_auto('com-enriched.csv') z
JOIN read_csv_auto('seed-domains.txt', header=false, columns={'domain':'VARCHAR'}) s
  ON z.domain = s.domain
WHERE z.mx IS NOT NULL AND z.mx <> ''
GROUP BY z.mx
ORDER BY domains DESC;

Étape 5 — Élargissez à tous les domaines partageant cette infrastructure. C'est l'étape qui met au jour ce qu'aucune liste ne contient encore :

-- all domains in the zone pointing at a known disposable mail host
SELECT domain, mx
FROM read_csv_auto('com-enriched.csv')
WHERE mx IN (SELECT mx FROM disposable_mx_hosts);

Étape 6 — Vérifiez avant de déployer. N'expédiez pas le résultat sans l'examiner. Certains hôtes de messagerie hébergent à la fois des domaines jetables et des domaines légitimes, et une plateforme mutualisée produira des faux positifs qui vous coûteront de vraies inscriptions. Triez le résultat par hôte MX, contrôlez par sondage les plus gros groupes, et ne promouvez un hôte dans la liste de blocage que lorsque ses domaines sont systématiquement jetables.

Étape 7 — Rafraîchissez à intervalles réguliers. Rachetez périodiquement le même package et relancez la chaîne de traitement. De nouveaux domaines alias apparaissent en pointant vers des hôtes de messagerie que vous connaissez déjà, et la comparaison de deux instantanés les fait remonter sans le moindre travail manuel.

# list zone-file packages
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

# technology packages matching a keyword
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

L'API expose le catalogue de packages, ce qui permet d'automatiser entièrement ce processus ; la référence est disponible sur /api/. Ce n'est ni un point de terminaison de validation d'e-mails ni un service de recherche de domaines — la logique de classification reste dans votre chaîne de traitement, là où vous pouvez l'ajuster.

Erreurs fréquentes en validation d'e-mails

1. S'appuyer sur une liste de domaines tenue à la main.

   • Ce qui ne va pas : la détection se dégrade silencieusement à mesure que les fournisseurs font tourner leurs domaines, et personne ne s'en aperçoit avant que le taux de rebond ne grimpe.
   • La solution : automatisez les mises à jour depuis une liste open source maintenue, et ajoutez une classification par MX pour attraper les nouveaux domaines alias dès le premier contact.

2. Prendre la vérification SMTP pour de la détection de jetables.

   • Ce qui ne va pas : la vérification aboutit — la boîte existe bel et bien — et l'adresse est marquée valide.
   • La solution : comprenez que délivrabilité et permanence sont deux propriétés différentes. Un sondage SMTP agressif fait en plus mettre votre IP en greylisting, soit un second coût pour aucun bénéfice.

3. Bloquer purement et simplement les domaines jetables à l'inscription.

   • Ce qui ne va pas : des utilisateurs légitimes soucieux de leur vie privée sont écartés, tandis que les fraudeurs déterminés passent simplement au domaine suivant.
   • La solution : scorez plutôt que rejeter. Conditionnez les actions qui vous coûtent réellement — opérations irréversibles, prolongations d'essai, envois sortants — plutôt que le compte lui-même.

4. Confondre webmail gratuit et messagerie jetable.

   • Ce qui ne va pas : les grands fournisseurs de messagerie grand public se retrouvent dans la liste de blocage et une large part de vos vrais clients est rejetée.
   • La solution : maintenez trois catégories distinctes — jetable, webmail grand public gratuit, professionnel — avec trois politiques distinctes. Une adresse grand public peut être un signal B2B faible, mais elle n'est pas fausse pour autant.

5. Considérer les domaines catch-all comme valides.

   • Ce qui ne va pas : un serveur catch-all accepte le courrier pour toutes les adresses ; la vérification renvoie donc « valide » pour des adresses inexistantes et le courrier est silencieusement supprimé.
   • La solution : marquez le catch-all à part comme « invérifiable » et tranchez explicitement la politique à appliquer, au lieu de le laisser se dissimuler dans un total d'adresses valides.

6. Valider une fois et plus jamais.

   • Ce qui ne va pas : les adresses se dégradent — les gens changent d'emploi, les domaines expirent, les boîtes ferment — et une liste validée il y a un an n'est pas une liste validée.
   • La solution : revalidez avant tout envoi de masse, et traitez la récence de l'engagement comme un signal de premier plan, au même titre que la validité syntaxique.

7. Citer un taux de prévalence que vous n'avez pas mesuré.

   • Ce qui ne va pas : un chiffre tiré d'un article oriente une décision de politique, et il s'avère que votre taux réel en diffère d'un ordre de grandeur.
   • La solution : instrumentez votre propre parcours d'inscription, classez un échantillon réel et calibrez votre réponse sur le taux que vous avez mesuré.

Questions fréquentes

Q : Qu'est-ce qu'une adresse e-mail jetable ?
R : une boîte aux lettres créée à la demande, le plus souvent sans inscription, et supprimée au bout de quelques minutes ou de quelques jours. C'est une adresse réelle et délivrable — d'où le fait que les contrôles de syntaxe, DNS et SMTP y réussissent tous.

Q : Pourquoi la validation d'e-mail standard ne les détecte-t-elle pas ?
R : parce qu'au niveau du protocole il n'y a rien à détecter. Le domaine a un MX valide, le serveur accepte le courrier, la boîte existe. La détection doit identifier le fournisseur plutôt que tester l'adresse.

Q : Une liste publiée de domaines jetables suffit-elle ?
R : comme socle, oui ; comme solution complète, non. Les fournisseurs exploitent de vastes ensembles de domaines alias tournants précisément pour déjouer le blocage au niveau du domaine. Combinez la correspondance de listes avec une classification par MX.

Q : Pourquoi l'enregistrement MX est-il un meilleur signal que le domaine ?
R : les domaines alias coûtent peu et tournent en permanence. L'infrastructure de messagerie derrière eux évolue beaucoup plus lentement : classer par hôte de messagerie permet donc d'attraper des domaines qu'aucune liste ne contient encore.

Q : Faut-il bloquer les adresses jetables à l'inscription ?
R : cela dépend de votre produit. Bloquer écarte aussi des utilisateurs légitimes soucieux de leur vie privée. Conditionner à une vérification les actions coûteuses ou irréversibles est généralement un meilleur arbitrage que de rejeter le compte. Pour les listes d'e-mailing sortant, en revanche, les retirer avant l'envoi est tout simplement la bonne décision.

Q : WebTrackly valide-t-il les adresses e-mail ?
R : non. WebTrackly distribue des données de domaines en masse sous forme de fichiers téléchargeables. Les packages de zone enrichis incluent les enregistrements MX, qui constituent la matière première d'une détection basée sur le MX ; la logique de validation elle-même reste dans votre propre chaîne de traitement ou chez un prestataire de validation.

Q : Les packages contiennent-ils des adresses e-mail ?
R : non. Les fichiers contiennent le domaine, les serveurs de noms, le MX, l'IP résolue et le CMS détecté. Aucun package ne contient d'adresses e-mail, de numéros de téléphone ni de coordonnées personnelles.

Q : Quelle est la taille du catalogue ?
R : 1 538 packages — 716 fichiers de zone, 716 jeux de zone enrichis, 79 listes de sites par technologie et 27 datasets sélectionnés — couvrant 285 582 781 domaines dans les packages de zone, dont 163 422 083 en .com. Le dataset de tous les domaines enregistrés compte 272 614 863 lignes.

Q : Comment garder les données à jour ?
R : chaque package est exporté au moment de l'achat. Rachetez le même package plus tard et comparez les deux fichiers pour voir quels domaines sont nouveaux.

Q : À quoi sert l'API ?
R : elle expose le catalogue. GET /api/v1/packages/?type=zone liste les packages de zone, ?type=technology&q=wordpress filtre les packages par technologie et /api/v1/packages/{slug}/ renvoie le détail d'un package, avec authentification par bearer token.

Conclusion

La détection des e-mails jetables est un problème de maintenance, pas un problème de recherche dans une liste. Les fournisseurs font tourner leurs domaines plus vite qu'aucune liste ne peut les absorber : la question n'est donc pas de savoir quelle liste télécharger, mais quel signal continue de fonctionner quand les domaines changent. Ce signal, c'est l'infrastructure de messagerie : les domaines alias sont jetables par conception, les serveurs derrière eux ne le sont pas.

Un dispositif efficace est stratifié : une liste open source mise à jour automatiquement pour la couverture, une classification par MX pour les domaines que la liste n'a pas encore vus, et un prestataire de validation là où il vous faut une réponse en temps réel à l'inscription. Alimentez-le avec votre propre taux de prévalence mesuré plutôt qu'avec un chiffre lu dans un article, gardez les services d'alias de redirection dans une catégorie à part, et scorez plutôt que de rejeter. Si vous voulez construire vous-même la couche MX, les packages de zone enrichis contiennent l'enregistrement MX de chaque domaine de la zone — exactement la matière première dont cette étape a besoin.

Parcourir le catalogue de datasets →

Ressources associées

• Catalogue de packages — 1 538 bases de données de domaines téléchargeables
• Fichiers de zone par TLD — .com, .net, .de et plus de 700 autres
• Datasets sélectionnés — tous les domaines enregistrés, serveurs MX, e-commerce
• Documentation API — accès au catalogue avec un bearer token
• Tarifs — achats à l'unité à partir de $3.50