Pourtant, la liste de domaines jetables téléchargée ce matin est déjà dépassée. Le projet open source throwaway-email en suit plus de 180 000, agrégés depuis six listes publiques et complétés par une surveillance active d’une dizaine de fournisseurs (Reece Harris, 2025) ; le temps de charger le fichier, plusieurs nouveaux domaines sont déjà apparus. Dans le jargon postmaster anglophone repris tel quel en français, on parle de DEA, disposable email address. Bloquer réellement une telle adresse exige une vérification en temps réel au moment de l’inscription, actualisée en continu : une chaîne de contrôles DNS puis handshake SMTP, détaillée plus bas, qui teste aussi l’âge et la réputation du domaine. Le risque s’est déplacé : moins vers le domaine jetable qui passe encore au travers, davantage vers l’alias légitime rejeté au passage. Une IP listée sur le SBL Spamhaus avec 72 heures de délai de délistage annoncé, c’est souvent la conséquence tardive de bounces accumulés par des inscriptions qui n’ont jamais eu de destinataire réel.
Pourquoi une liste de domaines jetables ne suffit plus
Les listes GitHub de référence (disposable-email-domains, burner-email-providers) fonctionnent selon le même principe : un fichier texte, mis à jour par des contributeurs, comparé au domaine saisi dans le formulaire. Ces dépôts affichent chacun plusieurs dizaines de milliers d’entrées ; aucun ne se met à jour en continu, ce qui laisse toujours une fenêtre de plusieurs jours entre l’apparition d’un nouveau domaine jetable et son entrée dans le fichier. En pratique, cette approche a un plafond structurel. De nouveaux domaines temporaires apparaissent chaque heure chez les fournisseurs existants, qui font tourner leurs noms de domaine précisément pour échapper aux listes publiées (Abstract API, 2026). Le même rapport rattache cette fraude à un usage plus large : credential stuffing, test de cartes bancaires volées, épuisement de quotas API et multiplication des essais gratuits se cachent souvent derrière la même boîte jetable créée en 30 secondes. Une liste téléchargée le lundi photographie le parc de domaines jetables à cet instant précis, sans capter son évolution continue. Le projet throwaway-email fait l’inverse : plutôt qu’une seule source, il agrège six listes textuelles et JSON existantes, croise le tout avec une allowlist pour retirer les faux positifs, puis surveille directement plus de 10 fournisseurs pour capter les domaines qui n’ont pas encore atteint les listes publiques. C’est cette combinaison d’agrégation large et de surveillance active qui approche un taux de couverture correct. Une seule liste statique, aussi longue soit-elle, reste un instantané périmé.
« Une liste de domaines jetables devient obsolète au moment même où elle est téléchargée. » (Abstract API, 2026)
Catch-all et role account : ce qu’on confond avec l’email jetable
support@ passe haut la main un test anti-jetable classique, sans qu’un humain lise jamais la newsletter derrière. C’est un role account : une adresse générique, valide, qui dégrade l’engagement mesuré exactement comme une adresse jetable, pour une raison technique tout autre. Le catch-all pose un problème différent, un serveur mal configuré qui accepte toute adresse à ce domaine, c’est-à-dire qu’il répond positivement même quand la boîte n’existe pas. La RFC 5321 (IETF, 2008) traite d’ailleurs le catch-all comme une déviation du comportement attendu d’un serveur conforme. Trois problèmes, trois signatures techniques différentes. Les confondre dans une seule case « suspect » gonfle le taux de faux positifs sans réduire le vrai risque.
L’architecture de vérification qui bloque réellement
Une seule vérification ne suffit jamais. La chaîne qui tient en 2026 empile plusieurs couches, chacune éliminant une catégorie d’adresses invalides avant de passer la main à la suivante.
- Validation syntaxique de l’adresse (format RFC), qui écarte les erreurs de frappe mais ne dit rien sur l’existence du domaine.
- Résolution DNS des enregistrements MX (Mail Exchanger), qui confirme qu’un serveur de messagerie répond pour ce domaine.
- Handshake SMTP sans envoi : le MTA vérificateur ouvre une session et soumet une commande RCPT TO, sans jamais transmettre de message, pour lire le code retourné par le serveur (par exemple 550 5.1.1 user unknown quand la boîte n’existe pas).
- Heuristique de réputation du domaine, croisant âge d’enregistrement et absence de tout contenu web associé au nom de domaine testé.
- Confrontation à une allowlist des services de messagerie et d’alias reconnus avant tout rejet définitif de l’inscription.
Cette chaîne a une limite honnête. Sur un domaine catch-all, le handshake SMTP ne conclut rien : le serveur accepte toute adresse testée sans distinguer une boîte jetable d’une boîte réelle. La décision retombe alors entièrement sur l’heuristique de réputation, plus lente à établir. Certains fournisseurs de boîtes jetables exploitent justement ce point de bascule en configurant leurs domaines en catch-all pour brouiller la couche 3. Le coût de la chaîne se mesure en millisecondes ajoutées au formulaire d’inscription : une résolution DNS répond en 10 à 50 ms, un handshake SMTP complet en 200 à 800 ms selon le serveur distant, un délai transparent pour l’utilisateur mais qui impose de paralléliser les couches sur les gros volumes plutôt que de les exécuter en série. Gmail et Outlook, en tête des fournisseurs concernés, limitent aussi le nombre de handshakes SMTP acceptés depuis une même IP sur une courte période, ce qui pousse les outils de vérification à répartir leurs probes sur plusieurs adresses sortantes.
Le piège des alias de confidentialité légitimes
En janvier 2022, les mainteneurs d’une blocklist de domaines jetables ont ajouté mozmail.com, le domaine utilisé par Firefox Relay, à leur liste noire (BleepingComputer, 17 janvier 2022). Les utilisateurs concernés perdaient l’accès à des comptes ouverts parfois deux ans plus tôt, sur des sites qui refusaient soudain leur alias historique. Apple Hide My Email, Firefox Relay, SimpleLogin et DuckDuckGo Email Protection partagent une même mécanique : un alias forwarde vers la vraie boîte d’une vraie personne, avec un historique d’engagement mesurable. Aucun de ces services n’expire de lui-même. La doc postmaster classique recommande souvent de traiter comme suspecte toute adresse qui ressemble à un alias masqué ; c’est justement l’angle mort de cette recommandation, elle confond la forme (une adresse générée, imprévisible) avec la fonction (une boîte active ou une coquille vide). Le coût d’un faux positif sur un alias Hide My Email est un vrai client perdu à l’inscription. Le bon réflexe consiste à dégrader le score de confiance de ces domaines plutôt qu’à les rejeter à la porte.
Ce que ça change pour le hard bounce et la réputation IP
Le seuil officiel fixé par Google depuis juin 2024 tolère un taux de plaintes spam jusqu’à 0,3%, avec une cible recommandée de 0,1% (Google Workspace Admin Help). Abstract API mesure un signal voisin sur un tout autre axe : au-delà de 0,3% de hard bounce rate, un domaine expéditeur bascule en zone de filtrage renforcé dès 2026. Sur certains sites, 20 à 30% des inscriptions proviennent d’adresses jetables, ce qui suffit à faire glisser un domaine d’un bon IP reputation tier vers une zone de filtrage accru, bien avant que le complaint rate ne bouge. Un échantillon passé par cette même chaîne de vérification avant le prochain envoi suffit souvent à mesurer l’écart réel. Les 180 000 domaines suivis aujourd’hui auront en partie changé de nom d’ici trois mois, et une liste téléchargée une fois par trimestre ne couvre plus qu’une fraction de ce renouvellement.
