Apprenez à repérer les inscriptions depuis des domaines récemment créés en combinant l'âge du domaine, la validation d'e-mails et des règles de vérification progressive pour réduire la fraude et les rebonds.
Parce qu'ils sont peu coûteux et faciles à remplacer. Si un domaine est bloqué, un attaquant peut en enregistrer un autre et continuer : on voit donc souvent des vagues d'inscriptions depuis des domaines frais pendant les campagnes abusives.
Non. Beaucoup d'utilisateurs légitimes enregistrent un domaine et s'inscrivent le jour même pour une nouvelle société, un projet, un événement ou un rebranding. Considérez l'âge du domaine comme un indice de risque, puis confirmez avec la configuration mail et les signaux comportementaux.
Cela signifie généralement soit que le domaine a été récemment enregistré, soit qu'il n'a été « vu » que récemment dans des signaux d'activité. L'âge d'enregistrement et la première observation peuvent diverger si le domaine est resté inutilisé ou a changé de propriétaire.
Commencez par une vérification de syntaxe conforme RFC pour éliminer les erreurs évidentes, vérifiez que le domaine existe dans le DNS, contrôlez les enregistrements MX pour savoir s'il peut recevoir du courrier, puis filtrez les fournisseurs jetables et l'infrastructure connue comme malveillante. Ces étapes répondent rapidement aux questions « est-ce réel ? » et « peut-il recevoir des e-mails ? ».
L'absence de MX signifie souvent que le domaine ne peut pas recevoir d'e-mails pour l'instant, ce qui rend la vérification et l'onboarding peu fiables. Pour des domaines très récents, c'est une raison pratique de ralentir l'inscription ou de demander une autre adresse plutôt que d'accorder immédiatement l'accès à des fonctionnalités sensibles.
Regroupez l'âge en plages larges comme 0–7 jours, 8–30 jours, 31–180 jours et 180+ jours. Combinez ensuite la plage avec le résultat de validation et appliquez une action cohérente : autoriser, exiger vérification, limiter le débit ou bloquer.
Un hard fail bloque immédiatement l'inscription quand l'e-mail est clairement inutilisable ou très risqué (syntaxe invalide, domaine inexistant, fournisseur jetable). Un soft fail laisse l'utilisateur créer un compte mais ajoute des frictions : vérification par e-mail, CAPTCHA, limites de taux ou accès restreint jusqu'à preuve du compte.
Créez par défaut le compte mais limitez les actions sensibles tant que la vérification n'est pas terminée. Par exemple, laissez définir un mot de passe et consulter le tableau de bord, mais retardez l'activation d'essais, la création de clés API, les exports ou les invitations jusqu'à vérification.
Considérez l'âge inconnu comme une donnée non fiable, pas comme négative. C'est un motif pour appliquer des contrôles supplémentaires ou une vérification progressive, et vous pouvez vous appuyer davantage sur des signaux de délivrabilité comme la validité DNS, la présence de MX et la détection de fournisseurs jetables ou de listes noires.
Commencez par exécuter vos règles en mode surveillance et consignez la plage d'âge, le résultat de validation et l'action choisie, puis comparez avec les résultats ultérieurs : rebonds, signalements de spam, rétrofacturations ou usage sain. Si vous voulez une solution en un appel pour obtenir ces signaux à l'inscription, une API de validation d'e-mails comme Verimail (verimail.co) fournit syntaxe RFC, vérification de domaine, contrôles MX et détection de jetables/listes noires.
Les domaines fraîchement créés attirent les attaquants parce qu'ils sont faciles à lancer, peu coûteux et jetables. Si un domaine est bloqué, ils peuvent en enregistrer un autre et continuer. C'est pourquoi les inscriptions depuis des « nouveaux domaines » surviennent souvent en vagues de faux comptes.
Les nouveaux domaines ont aussi très peu d'historique. Il y a moins de signaux publics pour les juger, et ils ne figurent pas encore sur les listes de blocage. Cette ardoise propre permet à l'abus de franchir des filtres simples et gagne du temps avant que le domaine n'obtienne une mauvaise réputation.
Quand ce schéma se produit, il crée généralement les mêmes problèmes business : comptes créés par des bots qui gaspillent le support, spam envoyé via votre produit qui nuit à la délivrabilité, essais frauduleux utilisés pour scraper ou sonder, fraudes au paiement qui finissent en rétrofacturations, et leads de faible qualité qui polluent les rapports.
Cela ne veut pas dire que tous les nouveaux domaines sont mauvais. Des personnes réelles enregistrent des domaines tous les jours : une nouvelle entreprise, un projet annexe, un événement, un rebranding, ou une équipe qui passe d'une boîte gratuite à une adresse de marque. Bloquer tous les domaines récents pénalise précisément les utilisateurs que vous voulez garder.
L'objectif pratique est de réduire l'abus sans bloquer les vrais utilisateurs. Considérez l'âge du domaine comme un indice de risque, pas comme un verdict. Associez-le à des signaux de validation d'e-mails (syntaxe, configuration du domaine, indices de délivrabilité) et utilisez une vérification progressive pour que les inscriptions à risque plus élevé rencontrent un peu plus de friction tandis que les utilisateurs normaux suivent un parcours fluide.
Une startup légitime peut s'inscrire avec un domaine enregistré la semaine précédente, mais leur configuration mail est solide et leur comportement paraît humain. Les attaquants montrent souvent l'inverse : un domaine tout neuf, une configuration bancale et un comportement automatisé à fort volume.
« Âge du domaine » désigne souvent l'une des deux choses suivantes :
L'âge d'enregistrement est utile parce que beaucoup de campagnes abusives enregistrent des domaines juste avant de s'en servir. La première observation peut être encore plus utile en pratique, car un domaine peut rester inactif des mois puis « se réveiller » aujourd'hui, ou changer de propriétaire.
Les équipes obtiennent en général les données d'âge du domaine via les enregistrements WHOIS/RDAP, des flux de registrar ou de registre (lorsqu'ils sont disponibles), le DNS passif ou des jeux de données « first observed », et l'historique produit (quand vous avez vu le domaine pour la première fois).
Un problème courant est l'absence ou l'imprécision des données. Certains registrars rédigent des informations, les services de confidentialité masquent des champs, et certains TLD ont des enregistrements inconsistants. Quand l'âge du domaine est inconnu, traitez-le comme non fiable, pas comme malveillant. Ne bloquez pas par défaut. Servez-vous-en pour décider des contrôles supplémentaires à appliquer.
L'âge du domaine est un signal, pas un verdict. Beaucoup d'utilisateurs réels créent un domaine pour une nouvelle activité et s'inscrivent le même jour. En même temps, de nombreuses inscriptions frauduleuses reposent sur des domaines fraîchement enregistrés. La valeur vient de la combinaison de l'âge avec d'autres signaux.
L'âge du domaine est utile, mais il ne vous dit pas si une adresse est joignable. Pour les inscriptions depuis des domaines nouvellement créés, combinez l'âge avec des contrôles de validation qui répondent à des questions simples comme « est-ce que c'est vraiment un e-mail ? » et « ce domaine peut-il recevoir du courrier ? »
Commencez par des vérifications de syntaxe conformes RFC. C'est rapide et ça capture les déchets évidents comme des parties manquantes, des caractères interdits, ou du texte collé qui n'est pas du tout un e-mail. La syntaxe seule ne prouve pas qu'une boîte existe, mais elle élimine beaucoup de bruit.
Ensuite, vérifiez si le domaine existe dans le DNS. Beaucoup d'inscriptions abusives utilisent des fautes de frappe, des chaînes aléatoires, ou des domaines jamais enregistrés. C'est un bon complément à l'âge du domaine puisqu'il s'agit aussi d'un signal au niveau du domaine.
Puis faites une recherche des enregistrements MX. Le domaine peut-il recevoir des e-mails ? Certains nouveaux domaines sont enregistrés mais pas configurés pour le mail. Si vous dépendez de l'e-mail pour des codes de connexion, des factures ou l'onboarding, l'absence de MX est une raison pratique de ralentir l'inscription ou d'exiger une preuve supplémentaire.
Enfin, comparez avec des fournisseurs d'e-mails jetables et une infrastructure connue comme malveillante. L'âge du domaine ne détectera pas un fournisseur jetable bien établi, et les listes de blocage ne capturent pas toujours un domaine tout neuf. Ensemble, ces contrôles couvrent les failles les uns des autres.
Une façon simple d'y penser :
Vous n'avez pas besoin d'un score de risque parfait pour commencer. Un modèle simple fonctionne bien : placez le domaine dans une tranche d'âge, combinez cela avec le résultat de validation, puis appliquez une action cohérente.
Gardez les tranches larges pour pouvoir les ajuster plus tard :
Combinez ensuite la tranche avec des issues de validation claires comme valid, invalid, disposable, risky, et unknown (par exemple, problèmes DNS temporaires).
Définissez deux types de réponses pour éviter que l'équipe n'improvise :
Par exemple, un domaine vieux de 2 jours avec un match jetable est généralement un hard fail. Un domaine de 2 jours qui valide proprement peut être un soft fail : créer le compte mais exiger une vérification avant de lancer un essai.
Le degré de sévérité dépend de votre produit. Les offres B2B voient souvent des domaines légitimes tout neufs (startups, domaines spécifiques à un projet), donc les soft fails sont plus sûrs quand la validation paraît solide. Les applications grand public voient souvent plus de comportements jetables, donc vous pouvez être plus strict sur les domaines âgés de 0 à 30 jours.
Les nouveaux domaines ne sont pas automatiquement mauvais, mais les attaquants les utilisent pour faire tourner des identités rapidement. Traitez l'âge du domaine comme un signal et confirmez-le avec ce que vous pouvez apprendre de l'e-mail lui-même.
Validez l'e-mail à l'inscription (pas seulement la syntaxe). Confirmez que le domaine existe, que des enregistrements MX sont présents, et que l'adresse ne provient pas d'un fournisseur jetable.
Consultez l'âge du domaine (par exemple via WHOIS/RDAP ou votre fournisseur). Ne stockez pas les blobs WHOIS complets. Conservez seulement ce dont vous avez besoin : une date de création si disponible, le statut de recherche, et une plage d'âge.
Combinez les signaux en un niveau de risque clair. Gardez des règles suffisamment simples pour que le support et le produit puissent les comprendre.
Appliquez l'action : autoriser, exiger vérification, limiter le débit, ou bloquer.
Consignez les entrées et les résultats. De bons logs transforment la meilleure estimation d'aujourd'hui en une politique fiable pour le mois suivant.
Les actions doivent correspondre au risque et au coût. Un domaine de 2 jours avec des MX valides mais identifié comme jetable est fortement risqué : bloquez. Un domaine de 5 jours avec une validation propre est risque moyen : autorisez la création de compte mais exigez la vérification de l'e-mail avant d'accorder un essai ou d'envoyer des invitations.
La plupart des inscriptions sont légitimes, même quand le domaine d'une entreprise est tout neuf. Commencez par des contrôles silencieux et peu intrusifs et n'ajoutez des étapes que lorsque le risque augmente.
La validation d'e-mail est une première couche solide parce qu'elle est rapide et invisible pour l'utilisateur, et qu'elle capture des problèmes courants comme les fautes de frappe, les domaines invalides, l'absence de MX et les fournisseurs jetables.
Quand les signaux s'empilent (par exemple, un domaine très récent plus des échecs de contrôles de domaine), escaladez avec une vérification progressive. Restez simple :
Un schéma orienté utilisateur consiste à séparer création de compte et capabilités du compte. Au lieu de bloquer immédiatement, créez le compte mais limitez-le tant que la vérification n'est pas terminée. Laissez définir un mot de passe et consulter le tableau de bord, mais restreignez les actions sensibles comme inviter des coéquipiers, créer des clés API, exporter des données ou démarrer un essai gratuit.
Les tentatives répétées méritent une gestion spéciale car les attaquants itèrent vite. Suivez les inscriptions par IP, par appareil (si vous utilisez cela), et par domaine. Si vous observez de nombreuses tentatives en peu de temps, accélerez l'escalade lors de la tentative suivante.
Déployez progressivement pour ne pas surprendre les vrais utilisateurs :
Les règles fonctionnent mieux quand elles sont simples, explicables et faciles à ajuster. Commencez par quelques issues (autoriser, vérifier, bloquer), puis affinez après avoir observé le trafic réel.
Voici des règles de départ qui couvrent la plupart des cas :
Un exemple concret : quelqu'un s'inscrit avec [email protected] créé la veille. L'adresse passe la validation et le domaine a des MX. Au lieu de bloquer, vous lui permettez de créer un compte mais exigez la vérification de l'e-mail avant d'octroyer des crédits d'essai. Si la même inscription correspondait à un fournisseur jetable, vous bloqueriez immédiatement.
La façon la plus rapide de rendre la protection impopulaire est de pénaliser les utilisateurs honnêtes. Les inscriptions depuis des domaines nouvellement créés ne sont pas automatiquement malveillantes. Un objectif plus sûr est de séparer « inconnu » et « malveillant » et d'ajouter de la friction uniquement quand plusieurs signaux pointent dans la même direction.
Les erreurs qui causent le plus de problèmes sont prévisibles :
Pour éviter cela, utilisez l'âge du domaine comme signal souple. Quand les données d'âge sont manquantes ou contradictoires, appuyez-vous davantage sur les contrôles de délivrabilité comme la vérification de domaine, la recherche MX et la détection de fournisseurs jetables. Supposez que vos règles seront testées, ajoutez des limites de taux et de la journalisation, et révisez les résultats chaque semaine (combien d'utilisateurs légitimes ont été bloqués, et quels contrôles se sont avérés prédictifs).
Avant d'appliquer des règles sur les inscriptions depuis des domaines récemment créés, faites une vérification rapide pour capter l'abus évident tout en donnant aux vrais utilisateurs un chemin clair :
Si vous pouvez expliquer vos règles à un collègue en deux minutes, elles sont prêtes pour une première mise en production. Ajustez ensuite avec des données réelles.
Un essai gratuit se lance sur Product Hunt et génère un pic d'inscriptions depuis des domaines nouvellement créés. Le support est submergé par des utilisateurs d'essai qui n'activent jamais, et l'équipe commerciale voit les taux de rebond grimper. Vous voulez stopper l'abus évident sans pénaliser les vraies équipes qui ont enregistré un domaine la veille.
Un jeu de règles simple :
Comparez maintenant deux inscriptions.
Priya s'inscrit avec [email protected]. Le domaine a 2 jours. La validation montre une syntaxe valide, le domaine se résout, des enregistrements MX sont présents, et ce n'est pas jetable.
Résultat : elle n'est pas bloquée, mais on lui demande de vérifier son e-mail avant d'obtenir l'essai complet. Ça prend quelques secondes, pas des minutes.
Un bot s'inscrit avec [email protected]. Le domaine a 3 heures. La validation montre des MX absents (ou un match jetable), et les mêmes schémas se répètent sur plusieurs inscriptions.
Résultat : l'inscription est bloquée immédiatement.
Après le lancement, mesurez si le compromis en vaut la peine :
Ajustez les seuils progressivement. L'objectif est de bloquer les déchets évidents tout en laissant les vraies nouvelles équipes avancer.
Considérez les premières règles comme une hypothèse. Faites-les tourner en mode monitoring pendant une à deux semaines et enregistrez ce qui se serait passé : qui aurait été challengé, qui aurait été bloqué, et combien de ces inscriptions se sont ensuite révélées risquées.
Consignez trois choses pour chaque tentative d'inscription :
Puis ajustez en fonction des observations. Si des utilisateurs légitimes avec des domaines récents sont bloqués, passez cette tranche d'âge du blocage à la vérification progressive. Si de l'abus passe encore, serrez les règles de combinaison au lieu d'augmenter la friction pour tout le monde.
Quand vous êtes prêt à formaliser le côté e-mail, une API de validation d'e-mails peut fournir rapidement les signaux de base à l'inscription. Par exemple, Verimail (verimail.co) retourne des vérifications de syntaxe conformes RFC, la vérification de domaine, la recherche MX et la détection en temps réel des fournisseurs jetables et des listes noires dans un seul appel, ce qui facilite l'application de règles plus strictes uniquement quand un domaine est très récent ou que les résultats semblent suspects.
Revenez sur vos seuils chaque mois. L'abus évolue, et votre produit aussi. L'objectif est d'exercer une pression constante sur le trafic malveillant sans faire payer les bons utilisateurs.
