Créez une liste autorisée et une liste de blocage pour les domaines d'email afin de bloquer les domaines jetables sans exclure les entreprises réelles. Conseils pour la responsabilité et la maintenance.

Par défaut, privilégiez une liste de blocage qui interdit les domaines d'emails jetables connus et les domaines associés à des abus répétés. N'ajoutez une liste autorisée que lorsque l'accès doit être restreint (outils internes, portails clients pour certaines entreprises).
Commencez par vos propres données d'inscription des 30 à 90 derniers jours. Repérez les domaines qui génèrent beaucoup d'inscriptions mais presque aucune activation, qui provoquent des rebonds durs répétés, ou qui font l'objet de signalements d'abus, puis examinez quelques échantillons avant de bloquer quoi que ce soit.
Normalisez d'abord le domaine d'email : supprimez les espaces, mettez en minuscules et retirez un point final s'il existe. Ensuite, faites correspondre des domaines exacts par défaut, car les correspondances larges sont la manière la plus simple de bloquer par erreur des utilisateurs légitimes.
Une bonne règle par défaut est « la liste autorisée l'emporte », ainsi une exception validée peut débloquer rapidement un utilisateur réel même si une règle de blocage plus large existe. Si vous choisissez « la liste de blocage l'emporte », prévoyez davantage de tickets support et des délais d'unblocking plus longs.
Évitez les règles larges comme bloquer tous les TLD d'un pays, les domaines avec un tiret, ou tout ce qui semble « rare ». Avant d'ajouter un domaine à la liste de blocage, vérifiez s'il est utilisé par des organisations réelles (universités, administrations, grands FAI) et examinez les inscriptions réussies récentes provenant de ce domaine.
Affichez une raison claire et une étape suivante. Par exemple : « Ce fournisseur d'email n'est pas autorisé. Veuillez utiliser une adresse professionnelle ou contacter le support pour demander une exception. » Veillez à ce que le support voie la règle exacte qui a déclenché le blocage.
Exécutez d'abord les règles en mode « journalisation seulement » pour mesurer l'impact, puis déployez par petits lots avec un interrupteur de rollback rapide. Testez sur un échantillon récent d'inscriptions réelles pour estimer combien d'utilisateurs légitimes seraient bloqués avant d'appliquer les règles.
Désignez un propriétaire clair pour les approbations et les appels, et consignez chaque changement avec une raison courte et une date de révision. Sans ownership, les listes dérivent et vous vous retrouvez avec des blocages permanents que personne ne peut expliquer ou supprimer en toute confiance.
Passez en revue la liste de blocage chaque semaine et la liste autorisée chaque mois comme base pratique. Ajoutez des dates d'expiration aux blocages temporaires et aux exceptions afin qu'ils tombent automatiquement, sauf si quelqu'un les renouvelle avec des preuves récentes.
Les listes de domaines sont une couche de politique, pas une preuve que l'adresse est réelle. Associez-les à une validation d'email qui vérifie la syntaxe, les enregistrements DNS/MX et les signaux de fournisseurs jetables pour réduire les faux positifs tout en capturant les inscriptions frauduleuses.
Les règles sur les domaines existent pour protéger l'inscription contre des problèmes prévisibles : comptes faux, emails en rebond, et abus. Si les gens peuvent s'inscrire avec des adresses jetables, vous vous retrouvez avec des utilisateurs injoignables, un taux de rebond plus élevé et une base de données encombrée. Les domaines jetables sont aussi un outil courant pour les bots et fraudeurs parce qu'ils facilitent la création de milliers de comptes.
Une liste autorisée et une liste de blocage pour les domaines d'email à l'inscription est un contrôle brutal mais utile. Elle fonctionne mieux lorsque vous êtes clair sur ce que vous essayez d'arrêter. Bloquer des fournisseurs jetables connus, par exemple, peut réduire rapidement les inscriptions de faible qualité, même avant d'envoyer un email de vérification.
Il aide de séparer deux idées :
Cette différence compte parce que le compromis est réel. Des règles plus strictes signifient généralement moins de mauvaises inscriptions, mais elles créent aussi plus de refus erronés. Si vous bloquez trop largement, vous rejetterez des utilisateurs réels qui tentent de s'inscrire de bonne foi.
Qu'est-ce qui compte alors comme un domaine d'entreprise légitime pour vous ? En général, c'est un domaine détenu par une organisation réelle capable de recevoir des messages de façon fiable. Cela peut inclure le domaine principal d'une entreprise (comme example.com), des domaines régionaux (like name.co.uk), ou un domaine géré par un fournisseur pour le personnel. L'objectif est de bloquer les domaines risqués sans pénaliser les emails professionnels normaux.
Une liste de domaines n'est pas une simple fonctionnalité. C'est une décision de politique qui affecte le chiffre d'affaires, la charge du support et la confiance. Avant de construire une liste autorisée/liste de blocage pour les inscriptions, précisez ce que vous empêchez.
La plupart des équipes ont un objectif principal (et quelques secondaires) : empêcher les adresses jetables, réduire la fraude aux inscriptions, ou protéger la délivrabilité en maintenant la qualité des données. L'objectif compte car il change ce que vous bloquez et la sévérité. Bloquer les domaines jetables est généralement sûr. Bloquer les « emails gratuits » est risqué et bloque souvent des utilisateurs légitimes.
Écrivez aussi ce que vous ne bloquerez pas, même si cela semble suspect. Exemples courants : clients payants, utilisateurs invités, partenaires et comptes internes. Une règle simple comme « Nous autorisons ces flux, mais nous pouvons les signaler pour examen » évite beaucoup de blocages accidentels.
Décidez où l'application aura lieu pour garder des règles cohérentes dans votre produit : formulaires d'inscription en libre-service, API publiques qui créent des utilisateurs, utilisateurs créés par les admins, flux d'invitation (souvent plus permissifs), et actions sensibles comme la réinitialisation de mot de passe ou le changement d'email (évitez de surprendre des utilisateurs existants).
Enfin, fixez les attentes pour le support. Si quelqu'un est bloqué, que voit-il et comment corrige-t-il la situation ? Un bon message de blocage inclut une raison claire (« Ce fournisseur d'email n'est pas autorisé »), une étape sûre suivante (utiliser une adresse professionnelle ou contacter le support) et un chemin d'appel clair.
Une liste autorisée est l'option stricte. Vous ne laissez s'inscrire que les emails dont le domaine figure dans un ensemble de domaines de confiance. Cela fonctionne mieux quand vous savez déjà qui doit avoir accès.
Cas courants d'utilisation d'une liste autorisée : outils internes pour employés, bêtas privées où les invitations vont à des entreprises spécifiques, ou portails B2B où chaque compte correspond à un domaine d'entreprise connu. Dans ces configurations, bloquer une vraie personne est moins risqué parce que les bons domaines sont prévisibles et le support peut ajouter les domaines manquants.
Une liste de blocage est l'option flexible. Vous laissez passer la plupart des domaines, mais bloquez ceux qui sont clairement de faible qualité ou abusifs. C'est ici que vous bloquez généralement les domaines jetables, les domaines liés à des abus répétés et les motifs évidents de comptes jetables.
Une approche hybride est souvent la plus sûre pour la croissance : utilisez une liste de blocage comme base, puis ajoutez des exceptions ciblées en liste autorisée pour les cas importants. Par exemple, un grand client peut utiliser un domaine d'entreprise peu commun, ou un partenaire légitime peut s'inscrire depuis un sous-domaine qui semble suspect au premier abord.
Gardez le libellé des règles simple pour qu'il soit facile à relire et difficile à mal interpréter. Correspondre des domaines exacts (par exemple, example.com) est préférable quand c'est possible. Décidez à l'avance si vous traitez les sous-domaines comme identiques (par exemple, si mail.example.com doit être pris en compte). Si vous utilisez des exceptions temporaires, donnez-leur un propriétaire et une date d'expiration, et préférez des règles petites et claires plutôt que des motifs astucieux qui peuvent bloquer les mauvaises personnes.
Une bonne liste de départ ne se télécharge pas et ne se colle pas. Elle doit se baser sur ce qui se passe réellement dans votre flux d'inscription. C'est ainsi que vous bâtissez une liste autorisée/liste de blocage qui reflète le risque réel, pas des suppositions.
Commencez par vos propres données. Extractez les 30 à 90 derniers jours d'essais d'inscription, d'utilisateurs confirmés, de rebonds d'emails, de plaintes pour spam et de rapports d'abus. Regroupez par domaine et cherchez des motifs comme un volume élevé avec très peu d'activations, des rebonds durs répétés, ou le même domaine créant de nombreux comptes en peu de temps.
Si vous avez des rapports internes, cherchez les récidivistes. Une règle pratique : les domaines qui génèrent beaucoup de volume mais presque aucune interaction méritent un examen, pas un blocage automatique. Choisissez un petit nombre, enquêtez sur quelques adresses et confirmez le comportement avant d'ajouter le domaine.
Construisez aussi le côté « bon » à partir des connaissances internes. Demandez aux équipes Sales et Customer Success une courte liste des principaux domaines clients et prospects actifs. Ceux-ci peuvent devenir votre liste autorisée initiale (ou au moins une « liste à ne jamais bloquer sans examen »), ce qui vous aide à éviter des frictions accidentelles pour des entreprises réelles.
Quoi que vous ajoutiez, notez pourquoi c'est là. Gardez la note courte et utile : la source (rapport, ticket, cas de fraude, données de rebond), la date d'ajout, qui l'a approuvé, ce que vous avez observé et quand vous le reverrez.
Exemple : vous voyez 400 inscriptions d'un même domaine en une semaine, mais zéro confirmations et beaucoup d'IP identiques. Vous consignez les preuves, ajoutez le domaine à la liste de blocage et fixez une révision à 30 jours au cas où le motif change.
Traitez le domaine d'email comme une donnée non fiable. Les petites différences de format peuvent casser vos règles.
Normalisez chaque adresse de la même façon avant de la comparer à une liste : supprimez les espaces, mettez en minuscules et retirez un point final éventuel (certains systèmes acceptent example.com. comme valide). Faites cela une fois, près de l'endroit où l'email entre dans votre système, afin que toutes les vérifications en aval voient la même valeur.
Ensuite, décidez comment fonctionne la correspondance et écrivez-le. « Domaine exact uniquement » est plus sûr pour la plupart des équipes car il évite les surprises. « Inclure les sous-domaines » peut être utile (par exemple bloquer mail.disposable.com en plus de disposable.com), mais cela peut aussi bloquer des configurations légitimes si une entreprise utilise des sous-domaines inhabituels.
Choisissez une règle de départ et appliquez-la partout. De nombreux produits optent pour « la liste autorisée l'emporte » afin qu'une exception examinée puisse débloquer immédiatement des utilisateurs réels, même si une règle de blocage plus large existe. Si vous choisissez « la liste de blocage l'emporte », attendez-vous à plus de tickets support et à un déblocage plus lent.
Un déploiement sûr ressemble généralement à ceci :
Le moyen le plus rapide de perdre des inscriptions réelles est de bloquer avec des motifs larges. Évitez des règles comme « bloquer tous les TLD d'un pays » ou « bloquer tout ce qui contient un tiret ». Beaucoup d'entreprises réelles utilisent des domaines comme company.co.uk, company.com.au ou des configurations régionales comme eu.company.com.
Considérez les sous-domaines comme normaux, pas suspects. Une grande entreprise peut router les emails via des sous-domaines pour différentes équipes, régions ou acquisitions. Si votre règle ne vérifie que le « domaine principal », assurez-vous qu'elle gère correctement des cas comme company.co.uk vs company.com, et ne classe pas mail.company.com comme « inconnu ».
Soyez prudent avec les fournisseurs de routage d'emails. Certaines entreprises légitimes envoient et reçoivent du courrier via des services qui paraissent génériques, et leurs enregistrements MX peuvent ressembler à ceux utilisés par des solutions jetables ou marketing. Les règles de domaine seules ne peuvent pas déterminer l'intention.
Une simple checklist de sécurité avant d'ajouter une règle de blocage :
Enfin, créez un processus d'exception pour les comptes à forte valeur. Après des fusions, un client peut avoir cinq à dix domaines actifs. Facilitez la demande d'une exception temporaire par le support ou les ventes pendant que vous vérifiez la propriété et mettez à jour vos règles en toute sécurité.
Les règles de domaine échouent le plus souvent pour une raison ennuyeuse : personne ne s'en occupe. Donnez à une équipe ou à un rôle une responsabilité claire pour approuver les changements et traiter les appels. Il ne s'agit pas de contrôle, mais de vitesse et de cohérence quand un vrai client se retrouve bloqué.
Un workflow basique suffit :
Chaque changement doit être journalisé pour que vous puissiez l'expliquer plus tard. Gardez le journal succinct : qui a demandé, qui a approuvé, ce qui a changé (domaine et type de règle), pourquoi (preuves), quand c'est allé en production et quand le réexaminer.
Fixez un SLA pour les blocages contestés afin que les utilisateurs légitimes ne restent pas coincés. Par exemple : accusé de réception sous 4 heures ouvrées et résolution sous 1 jour ouvré, avec une voie d'urgence pour les clients payants.
Avant de mettre un domaine en liste de blocage, exigez des preuves, pas des impressions. Preuves typiques : volume élevé d'inscriptions frauduleuses, rebonds durs répétés, plaintes pour spam, ou un fort taux de correspondance avec des fournisseurs jetables connus.
Exemple : le support signale que des utilisateurs de acme-partners.com ne peuvent pas s'inscrire. Le propriétaire vérifie le journal, voit qu'il a été bloqué à cause de 30 inscriptions spam en une heure, et bascule sur une règle temporaire plus des contrôles renforcés, puis revoit la situation sous 48 heures.
Une liste de domaines n'est pas une configuration unique. Dès que vous cessez de l'entretenir, elle dérive : d'anciens schémas d'abus disparaissent, de nouveaux domaines jetables apparaissent, et une seule mauvaise entrée peut bloquer discrètement de bons utilisateurs.
Fixez un rythme de révision adapté au risque. Hebdomadaire pour la liste de blocage est un point de départ courant, car les attaquants évoluent vite. Mensuel pour la liste autorisée fonctionne généralement parce que les domaines légitimes changent plus lentement.
Pour éviter la « pourriture » de la liste, faites expirer par défaut les décisions temporaires. Si vous ajoutez un domaine à cause d'une vague de spam courte, attachez une date d'expiration et une note sur la raison. Faites de même pour les exceptions (« autoriser ce domaine pour le Partenaire X jusqu'à la fin du contrat »). À l'échéance, la règle tombe à moins qu'on la renouvelle avec des preuves fraîches.
Suivez quelques métriques pour savoir si la liste aide ou nuit : taux de blocage, taux d'appel, faux positifs (utilisateurs légitimes confirmés que vous avez bloqués), taux de rebond et concentration par domaine (quelle part du trafic provient d'un même domaine).
Surveillez deux signaux en particulier : nouveaux domaines jetables et pics soudains sur un même domaine. Si examplemail.co passe de 2 inscriptions par jour à 400 en une heure, enquêtez avant de bloquer en masse. Regardez la géographie, les motifs d'IP et si les adresses sont syntaxiquement valides et ont un routage mail réel.
Enfin, retirez rapidement les entrées. Si un domaine n'a pas produit d'abus depuis un moment, ou s'il déclenche des faux positifs pour de vraies entreprises, supprimez-le ou remplacez un blocage fort par un contrôle plus doux comme des limites de taux, une vérification supplémentaire ou un examen manuel.
Le moyen le plus rapide de casser la confiance des utilisateurs réels est de bloquer des domaines sur des impressions. Une liste autorisée/liste de blocage ne fonctionne que si elle est basée sur des preuves, revue souvent et appliquée de la même façon partout.
Un piège courant est de bloquer trop largement. Les équipes interdisent parfois un gros fournisseur ou un TLD entier après un pic d'inscriptions malveillantes. Cela touche presque toujours des utilisateurs légitimes, en particulier des contractuels, des étudiants et des utilisateurs internationaux.
Un autre piège est d'étiqueter un domaine comme jetable simplement parce qu'il est récent, peu commun ou paraît « aléatoire ». Beaucoup de vraies entreprises utilisent de petits domaines hébergés, des rebrands ou des fournisseurs régionaux. Si vous n'avez pas de preuves (taux de fraude, taux de rebond, rapports d'abus), traitez « inconnu » comme « à examiner », pas comme « mauvais ».
Voici les motifs qui causent le plus de dégâts :
Même un blocage correct peut poser problème si l'expérience utilisateur est floue. Si quelqu'un rencontre un blocage, il doit comprendre ce qu'il s'est passé et quoi faire ensuite. Journalisez la raison exacte et la règle qui a déclenché le blocage, affichez un message clair (évitez un vague « email invalide ») et maintenez une voie d'exception rapide pour les clients ou partenaires connus.
Avant de pousser une mise à jour de votre liste autorisée/liste de blocage, faites une passe de sécurité. La plupart des dégâts viennent de petites incohérences, d'un contexte manquant ou de changements sans possibilité de retour en arrière.
Commencez par les règles de correspondance. Décidez si vous faites des correspondances de domaine exactes (example.com) ou si vous incluez les sous-domaines (mail.example.com). Normalisez l'entrée de la même façon à chaque fois : conversion en minuscules, suppression d'espaces et format international cohérent. Si votre système traite Gmail.com et gmail.com différemment, vous allez manquer des cas et créer des comportements déroutants.
Assurez-vous que chaque règle est explicable. Chaque entrée doit avoir une raison courte, la date d'ajout et un propriétaire qui puisse répondre plus tard. « Domaine mauvais » n'est pas une raison. « Observé dans 1 200 inscriptions frauduleuses la semaine dernière » l'est.
Gardez le chemin d'appel simple mais réel. Mettez une révision limitée dans le temps sur les entrées contestées pour que les erreurs ne perdurent pas. Et n'autorisez pas des exceptions temporaires à devenir permanentes par accident : si vous autorisez un domaine risqué pour un lancement partenaire ou un événement, fixez une expiration et retirez-le à moins qu'on le renouvelle avec une raison.
Après la mise en ligne, surveillez l'impact. Suivez les faux positifs et traitez-les rapidement. Surveillez le taux de rebond et la délivrabilité pour les domaines nouvellement autorisés. Échantillonnez des inscriptions récentes pour confirmer que les règles se comportent comme prévu.
Un SaaS B2B remarque un pic d'ouvertures de comptes utilisant des domaines ressemblant à des marques (comme acme-corp-support.com au lieu du vrai domaine) et une vague de fournisseurs jetables. Les équipes Sales et Support se plaignent des leads pourris et des demandes de rétrofacturation. L'équipe a déjà une liste autorisée/liste de blocage, mais elle n'a pas été touchée depuis des mois.
Ils commencent prudemment, pas par une purge massive. D'abord, ils ajoutent une règle ciblée de blocage pour le domaine jetable le plus visible dans les logs. Ils imposent aussi une limite de vitesse temporaire sur les inscriptions à risque (même plage IP, forte vélocité, noms d'utilisateur similaires). Cela réduit l'abus pendant qu'ils apprennent, au lieu de bloquer des catégories entières de domaines.
Deux jours plus tard, un vrai client est bloqué. Une grande entreprise utilise un sous-domaine régional pour l'email (par exemple [email protected]). Une règle trop large destinée à repérer les sous-domaines lookalike l'a accidentellement matché. Le support escalade avec des preuves : le prospect a un bon de commande signé, un historique d'IP cohérent, et les messages rebondissent parce que l'inscription n'a pas été finalisée.
La correction n'est pas de supprimer la règle de blocage. Ils ajoutent plutôt une exception d'allowlist étroite pour le domaine corporate vérifié, documentent pourquoi elle existe et définissent une date d'expiration pour la revoir plus tard.
Au bout de deux semaines, l'équipe examine les résultats : le taux de blocage passe à 6 % (contre 1 %), mais les appels au support restent faibles (0,2 % des inscriptions). Le taux de rebond sur les emails de bienvenue tombe de 3,4 % à 1,1 % et les ventes signalent moins de démonstrations frauduleuses réservées. Le gain clé est la confiance : chaque règle a désormais un propriétaire, une raison et une voie de rollback.
Les listes de domaines sont utiles, mais ce sont des outils grossiers. Associez-les à une validation d'email pour détecter les adresses douteuses même quand le domaine semble normal, et évitez de bloquer des utilisateurs réels juste parce qu'ils utilisent un domaine d'entreprise peu familier.
Commencez par rédiger votre politique en termes clairs : ce que vous bloquez, ce que vous autorisez et ce qui relève d'un examen manuel. Cela aligne support, produit et ingénierie quand quelqu'un demande pourquoi une inscription a été rejetée.
Un flux pratique : vérifiez la syntaxe, confirmez que le domaine peut recevoir du courrier (contrôle DNS/MX), filtrez les fournisseurs jetables et les pièges à spam connus, puis appliquez vos règles de liste autorisée/liste de blocage (y compris les exceptions). Journalisez le résultat pour pouvoir apprendre et ajuster.
Si vous voulez garder les règles simples tout en obtenant de bons signaux à l'inscription, Verimail (verimail.co) est une option que certaines équipes utilisent pour valider les emails avec des vérifications RFC, des contrôles de domaine et MX, et la détection des fournisseurs jetables en un seul appel d'API. Utilisée ainsi, vos listes restent une couche de politique tandis que la validation prend en charge la lourde tâche de déterminer si une adresse paraît réelle et joignable.