Apprenez à concevoir un score de risque d'e‑mail en combinant syntaxe, santé du domaine, indicateurs d'adresses jetables et historiques en une grille simple et exploitable.
Un score de risque d'e‑mail est un résumé rapide de la probabilité qu'une adresse cause des problèmes comme des rebonds, des inscriptions frauduleuses ou des abus. Il aide à prendre des décisions cohérentes quand un simple contrôle pass/fail « e‑mail valide » n'est pas suffisant.
La validation d'e‑mail répond à « cette adresse peut‑elle probablement recevoir du courrier ? », tandis qu'un score de risque répond à « quel est le risque d'accepter cette inscription maintenant ? ». Une adresse peut sembler délivrable mais être risquée si elle est jetable ou correspond à des schémas liés à l'abus.
Commencez par un petit ensemble facile à expliquer : résultats de syntaxe conformes à la RFC, résolution du domaine, présence d'enregistrements MX, et correspondance avec des fournisseurs d'e‑mails jetables. Ajoutez les historiques plus tard, une fois que vous pouvez mesurer ce qui arrive après l'inscription.
Utilisez quelques bandes claires liées à des actions, comme permettre, permettre avec vérification, et bloquer ou revoir. Gardez les bandes stables au début, puis ajustez les seuils en fonction des résultats observés (taux de rebond, plaintes, événements d'abus).
Conservez de courtes chaînes de raison avec le score, par exemple « fournisseur jetable » ou « domaine ne peut pas recevoir de mail ». Si quelqu'un ne peut pas expliquer en une phrase pourquoi vous avez bloqué une adresse, le modèle est trop compliqué à exploiter.
Considérez les timeouts DNS comme « inconnu » et réessayez une fois avant de noter. Si c'est toujours inconnu, appliquez une petite pénalité plutôt que de traiter cela comme une défaillance catégorique : les problèmes DNS temporaires ne doivent pas marquer définitivement un utilisateur réel comme à haut risque.
La détection d'adresses jetables est utile, mais elle ne signifie pas forcément « bloquer ». Une pratique courante est d'augmenter le score et d'exiger une vérification par e‑mail ou de limiter les actions à forte valeur, puis d'ajuster selon vos données de conversion et d'abus.
Le risque de délivrabilité concerne l'atteignabilité et les rebonds, tandis que le risque de fraude concerne le comportement nuisible de l'utilisateur (rétrofacturations, abus de coupons, etc.). Si vous mélangez les deux sans préciser, les équipes se disputeront la signification du chiffre ; gardez deux scores séparés ou nommez clairement l'objectif du score unique.
Loggez les entrées que vous avez utilisées, le score final, la bande, l'action entreprise et une courte raison pour pouvoir déboguer les décisions. Limitez la conservation et restreignez l'accès : les logs d'e‑mail sont sensibles. Pour l'analytique longue durée, stockez des agrégats ou des identifiants hachés plutôt que des adresses complètes.
Ajustez en vous basant sur les résultats, pas sur l'intuition : vérifiez si les inscriptions à haut risque ont réellement des taux de rebond ou d'abus plus élevés que celles à faible risque. Changez une chose à la fois—souvent un seuil—et faites un holdout ou un A/B test pour mesurer l'impact entre faux positifs bloqués et abus prévenus.
Un score de risque d'e‑mail est un nombre simple (ou une étiquette comme faible, moyen, élevé) qui estime la probabilité qu'une adresse e‑mail crée des problèmes pour votre activité. « Problèmes » signifie généralement inscriptions frauduleuses, rebonds, plaintes pour spam ou utilisateurs que vous ne pouvez plus joindre.
Ce n'est pas un verdict sur le fait qu'une personne soit « bonne » ou « mauvaise ». C'est un résumé rapide et cohérent des signaux que vous avez déjà.
Un score aide quand le pass/fail est trop grossier. Beaucoup d'adresses semblent valides en apparence mais restent risquées. Une adresse peut avoir une syntaxe correcte et un domaine réel, et pourtant être jetable, mal configurée ou liée à des schémas ayant déjà causé des abus.
Avec un score de risque, vous pouvez prendre des décisions cohérentes sans transformer chaque cas limite en débat. Les actions typiques sont :
L'explicabilité est importante. Les équipes non techniques doivent pouvoir répondre « Pourquoi ceci est‑il à haut risque ? ». Visez des raisons simples comme « fournisseur jetable », « domaine incapable de recevoir des mails » ou « échec des vérifs de domaine ».
Une façon simple d'aligner tout le monde est d'associer chaque bande de score à une politique claire. Par exemple, 0–30 signifie faible risque et auto‑approuvé, 31–70 signifie risque modéré et exigence de vérification, 71–100 signifie risque élevé et blocage ou revue. L'objectif n'est pas un chiffre parfait, mais une décision que vous pouvez expliquer, mesurer et ajuster.
Commencez avec un petit ensemble de signaux faciles à expliquer et difficiles à manipuler. Vous pouvez en ajouter plus tard.
Commencez par des contrôles stricts de syntaxe. Ce n'est pas seulement « contient un @ ». Le parsing de type RFC repère les parties manquantes, caractères interdits, doubles points et formats trompeurs que beaucoup de systèmes gèrent mal. Les vérifs de syntaxe sont peu coûteuses et arrêtent les déchets évidents tôt, mais elles ne disent rien sur la capacité réelle de la boîte à recevoir du courrier.
Ensuite, vérifiez la santé du domaine. Deux contrôles font la majeure partie du travail : le domaine existe‑t‑il (résolution DNS) et publie‑t‑il des enregistrements MX. MX n'est pas parfait (certains domaines acceptent le courrier sans MX), mais c'est un bon indice d'atteignabilité. Un domaine tout récent sans configuration mail est souvent plus risqué à l'inscription.
Les drapeaux d'adresses jetables comptent surtout lors de la création de compte. Les boîtes jetables apparaissent dans l'abus d'essai gratuit, la chasse aux coupons et la capture de faux leads. Vous n'avez pas toujours besoin de les bloquer, mais vous devez les noter.
Vous pouvez aussi inclure des signaux de réputation avec prudence. Les listes noires et indicateurs de pièges à spam peuvent réduire les rebonds, mais des faux positifs existent. Traitez‑les comme des entrées de haute confiance seulement et préférez des actions douces (vérification supplémentaire) plutôt que des blocages fermes.
Enfin, ajoutez le contexte que vous avez déjà. L'e‑mail seul raconte rarement toute l'histoire. Des entrées utiles incluent l'origine de l'inscription, une vélocité d'inscription inhabituelle, des schémas répétés et ce qu'il s'est passé pour des inscriptions similaires auparavant.
Exemple : pendant une promotion, une adresse syntaxiquement valide sur un domaine sans MX plus un drapeau jetable et une haute vélocité d'inscription forment un signal beaucoup plus fort que n'importe lequel de ces contrôles pris isolément.
Un score de risque ne fonctionne que si tout le monde s'accorde sur ce que « risque » signifie. Commencez par écrire la décision qu'il doit soutenir. Voulez‑vous bloquer les mauvaises inscriptions, réduire les rebonds, ou diminuer la charge support ? Si le score essaie de tout faire en même temps, il devient confus et difficile à régler.
Ces notions sont liées, mais différentes.
Le risque de délivrabilité concerne votre capacité à atteindre l'adresse. Il se traduit par des rebonds durs, des rebonds répétés ou un dommage à la réputation d'expéditeur.
Le risque de fraude ou d'abus concerne l'utilisateur derrière l'adresse. Il se traduit par des rétrofacturations, abus de coupons, faux comptes, plaintes pour spam ou une valeur à vie anormalement basse.
Vous pouvez gérer cela de deux façons simples : garder deux scores séparés, ou garder un score unique mais le nommer clairement (par exemple « risque d'abus à l'inscription »).
Choisissez un résultat principal à prédire, puis ajoutez des secondaires plus tard. Bons objectifs de départ :
Décidez ensuite quel est le coût d'un faux positif. Si vous bloquez un vrai client, vous perdez du revenu et de la confiance. Si vous laissez passer une inscription risquée, vous payez en rétrofacturations, temps de support ou dégâts de délivrabilité. Votre tolérance à ces compromis doit guider les seuils.
Enfin, choisissez une échelle et ce qu'elle signifie. Une échelle 0–100 est facile à communiquer, à condition de définir des bandes comme 0–24 faible, 25–59 moyen, 60–100 élevé. Liez chaque bande à une action pour que le score soit plus qu'un chiffre.
Un score de risque n'est utile que si les gens lui font confiance. Cela signifie que vous devez pouvoir répondre en termes simples : pourquoi cette inscription a‑t‑elle obtenu ce score, et que devons‑nous faire ensuite ?
Une grille à points est généralement le point de départ le plus simple. Elle fonctionne comme une checklist avec un total, et il est facile de l'inclure dans une politique. Une moyenne pondérée ou un petit modèle peuvent être plus précis, mais ils sont plus difficiles à expliquer quand quelqu'un demande « pourquoi cela a‑t‑il été bloqué ? »
Voici une approche de pondération simple avec quatre signaux de base. Gardez les calculs simples et les résultats clairs :
Cela fait 100 au total. Dans ce cadre, un score plus élevé signifie plus de risque.
Les données manquantes arrivent, surtout avec des timeouts DNS ou des échecs temporaires de lookup. Décidez à l'avance si « inconnu » doit être neutre, légèrement risqué ou une raison de retenter :
Calibrez selon votre produit. Un flux B2B peut être plus strict sur la santé du domaine et le MX (on attend des e‑mails professionnels). Un flux grand public peut autoriser davantage les domaines gratuits mais doit être plus strict sur les drapeaux jetables.
Un bon score commence par rendre comparables des signaux désordonnés. Ne cherchez pas à noter chaque détail. Convertissez chaque signal en quelques catégories que n'importe quel collègue non technique pourra reconnaître et expliquer.
Choisissez 3 à 4 catégories par signal. Par exemple : syntaxe (valide, douteuse, invalide), santé du domaine (saine, inconnue, cassée), drapeau jetable (non, peut‑être, oui), et historiques (bon historique, mixte, mauvais). Gardez des noms simples.
Ensuite, attribuez des points avec un schéma simple : bon = peu de points, incertain = moyen, mauvais = beaucoup. Si les adresses jetables sont votre principal vecteur d'abus, donnez à ce signal plus de poids que des quirks mineurs de syntaxe.
Un flux pratique :
Le score n'a de valeur que s'il déclenche une action cohérente. Gardez peu de bandes et évidentes :
Le logging n'est pas optionnel. Sauvegardez les buckets d'entrée (pas seulement le score final) et l'action prise. Si vous utilisez une API de validation d'e‑mail, conservez les sorties clés sur lesquelles vous vous êtes appuyé afin de comparer les scores aux résultats réels plus tard.
Une grille simple fonctionne mieux quand elle est facile à expliquer au support, à la fraude et au marketing. Commencez à 0 point (risque le plus faible) et ajoutez des points quand un signal augmente la probabilité que l'adresse rebondisse, soit fausse ou mène à un abus.
| Signal (d'après vos signaux de validation e‑mail) | Règle | Points |
|---|---|---|
| Syntaxe | Conforme à la RFC | +0 |
| Syntaxe | Invalide ou suspecte (points en trop, guillemets incorrects) | +40 |
| Domaine existe | Domaine résout | +0 |
| Domaine existe | NXDOMAIN / impossible à résoudre | +30 |
| Enregistrements MX | MX présent | +0 |
| Enregistrements MX | Pas de MX | +25 |
| Drapeau jetable | Non jetable | +0 |
| Drapeau jetable | Jetable / fournisseur temporaire | +35 |
| Santé du domaine | Réputation normale d'expéditeur | +0 |
| Santé du domaine | Nouvellement vu ou historique de plaintes élevé | +15 |
| Historique | Rebonds passés pour ce domaine/schéma | +20 |
Conseil pour les cas limites : si la syntaxe est valide et le domaine résout mais qu'il n'y a pas de MX, traitez par défaut comme risque moyen, pas blocage automatique. Certains domaines sont mal configurés temporairement et vous ne voulez pas refuser des utilisateurs légitimes.
Pour garder la grille stable quand vous ajoutez de nouveaux signaux, plafonnez l'impact de tout nouveau signal (par exemple +10 à +15) et ne changez les seuils qu'après avoir des données d'issue.
Une grosse promo peut changer votre trafic du jour au lendemain. Vous obtenez plus de vrais clients, mais aussi plus de bots, chasseurs de coupons et personnes utilisant des adresses jetables. Un score de risque vous aide à décider qui peut s'inscrire sans friction et qui doit passer une vérification.
Supposons une échelle 0–100 (plus = plus risqué). Vous exécutez des signaux de validation (syntax, domaine et MX, drapeaux jetables, et vos propres historiques) dans un pipeline, puis vous attribuez des points.
Voici deux inscriptions issues de la même campagne :
| Résumé des signaux | Points | Total | Décision | |
|---|---|---|---|---|
| [email protected] | Syntaxe propre, domaine résout, MX présent, non jetable, domaine faible historique de rebonds | +0, +0, +0, +0, +5 | 5 | Autoriser, sans friction |
| dealhunter923@mailbox‑now.xyz | Syntaxe OK, domaine résout, MX présent, drapeau jetable, domaine avec fort taux de rebonds/plaintes | +0, +0, +0, +40, +35 | 75 | Ajouter vérification |
Pour la deuxième inscription, « ajouter vérification » peut être léger : OTP par e‑mail, lien magique, ou exiger une vérification avant de remettre la promo. Vous ne bloquez pas tout le monde, vous n'ajoutez des ralentisseurs que là où les signaux le justifient.
Avec le temps, ajustez les poids à partir des résultats, pas des suppositions. Si les e‑mails marqués jetables convertissent et restent actifs, réduisez la pénalité. Si un domaine particulier produit des rebonds, des rétrofacturations ou des plaintes, augmentez les points liés à l'historique domaine.
La façon la plus rapide de perdre la confiance dans un score est de traiter un signal comme un verdict. Les signaux e‑mail sont bruyants : les réseaux plantent, les domaines sont mal configurés temporairement et des gens réels utilisent parfois des adresses qui paraissent suspectes.
La détection jetable est utile, mais ce n'est pas synonyme de fraude. Si vous la sur‑pondérez, vous bloquerez de vrais utilisateurs cherchant la confidentialité ou un essai rapide. Une approche plus sûre est de la scorer fortement, puis de la coupler au contexte (vélocité d'inscription, intention de paiement, vérifs de domaine/MX).
Les timeouts DNS arrivent. Ne notez pas un timeout comme « domaine inexistant ». Gardez une catégorie « inconnu maintenant », réessayez une fois, et n'augmentez le risque que légèrement sauf si d'autres signaux confirment.
Il est facile de doubler une idée. Par exemple, « pas de MX » et « échec de vérif de domaine » peuvent être deux vues d'un même problème. Si vous ajoutez les deux à plein poids, vous gonflez le risque sans améliorer la précision. Choisissez la version la plus claire, ou réduisez les poids quand les signaux se recoupent.
Quand les campagnes changent et que les attaquants s'adaptent, les poids d'hier ne valent plus forcément. Revuez les issues (rebonds, plaintes, rétrofacturations, taux d'activation) régulièrement et surveillez les changements soudains.
Séparez test et production. Des données de test comme [email protected], des scripts QA et des domaines internes peuvent polluer vos labels « bon vs mauvais ».
Checklist pratique pour prévention :
Un score n'a de sens que s'il correspond à ce qui arrive ensuite. Traitez votre score comme une prédiction vérifiable.
Commencez par collecter les issues liées à l'inscription : délivré vs rebondi, plaintes, abus de compte, rétrofacturations, flags support et toute fraude confirmée.
Choisissez quelques bandes (par ex. Faible, Moyen, Élevé) et révisez‑les à fréquence fixe. Hebdomadaire suffit au début ; quotidien aide lors de grosses campagnes ou de changements de politique.
Cherchez la séparation : le haut risque doit avoir des issues significativement pires que le bas risque. Suivez un petit ensemble de métriques :
Si les bandes se ressemblent, vos signaux ne suffisent pas ou vos seuils sont mal placés. Par exemple, si « Élevé » a le même taux de rebond que « Faible », vous êtes soit trop strict sur des signaux innocents, soit trop permissif sur des signaux forts.
Changez une chose à la fois, et rendez le changement mesurable. Le réglage le plus sûr est souvent le seuil, pas tout le modèle.
Faites un A/B test (ou un petit holdout) avant de déployer de nouveaux cutoffs. Exemple : pendant une semaine, bloquez seulement le 1 % d'inscriptions les plus risquées dans le groupe test, tandis que le groupe contrôle utilise la politique actuelle. Comparez rebonds, abus et perte de bons utilisateurs.
Les problèmes de mise en production viennent souvent d'actions floues, de garde‑fous manquants ou d'entrées bruyantes.
Ensuite, mappez le score à une action. Si deux personnes de votre équipe prendraient deux actions différentes pour le même score, la politique n'est pas prête.
Si vous voulez une quatrième bande pendant les campagnes, ajoutez‑la explicitement (et gardez‑la simple à gérer) : très haut risque peut être throttlé ou bloqué.
Une grille ne sert que si vous pouvez l'exploiter au quotidien. Traitez votre score comme un système de décision : loggez assez pour le déboguer, expliquez‑le aux humains et gardez‑le stable sous trafic réel.
Commencez par du logging qui permet de recréer la décision pour toute inscription. Capturez les entrées brutes (résultat de syntaxe, vérifs domaine/MX, drapeau jetable, toute correspondance liste noire), le score final et l'action prise (autoriser, friction, revue, blocage). Stockez un request ID pour que le support retrouve rapidement l'historique complet.
Rendez le score lisible en une phrase. À côté du score numérique, conservez une courte raison que quelqu'un peut lire en cinq secondes. Par exemple : « Fournisseur jetable + échec MX, score 82, bloqué. »
Les vérifs e‑mail peuvent échouer pour des raisons indépendantes de l'utilisateur. Prévoyez timeouts, retries limités, quotas et solutions de secours sûres. Si les vérifs échouent, renvoyez un état « inconnu » conservateur plutôt que de laisser le score varier fortement.
Les logs d'e‑mail sont sensibles. Conservez seulement ce dont vous avez besoin, restreignez l'accès et fixez une durée de rétention (par ex. 30 à 90 jours pour les signaux bruts). Si vous avez besoin d'analyses long terme, stockez des agrégats ou des identifiants hachés au lieu des adresses complètes.
Commencez petit. Votre premier score doit être une grille claire qu'un collègue peut lire et appliquer sans tableur. Si vous ne pouvez pas expliquer pourquoi une inscription a obtenu 72 plutôt que 28, vous n'y aurez pas confiance quand ça comptera.
Déployez quelques signaux que vous comprenez, puis ajustez seulement après avoir des issues réelles (rebonds, rétrofacturations, rapports d'abus, activations réussies). Gardez les actions simples pour les rendre opérationnelles :
L'implémentation est plus simple quand les signaux clés arrivent au même endroit. Par exemple, Verimail (verimail.co) fournit une API de validation d'e‑mail qui renvoie des vérifs comme la syntaxe conforme à la RFC, la vérification de domaine, la recherche MX et la correspondance jetable et liste noire dans une seule réponse. Utilisez ces résultats comme entrées pour votre grille, puis gardez les règles de décision dans votre app pour qu'elles restent faciles à expliquer et à changer.
Une fois en production, mesurez cela comme une fonctionnalité produit. Loggez le score, la bande, l'action prise et l'issue observée plus tard. Revuez un petit échantillon de faux positifs (bloqués mais légitimes) et de faux négatifs (autorisés mais nuisibles), puis ajustez une règle à la fois. La version la plus simple que vous surveillez et mettez à jour bat un modèle compliqué que personne ne peut expliquer.
