Vérification des domaines e-mail expliquée aux équipes produit et marketing

Pourquoi les vérifications de domaine comptent (même si l'e-mail a l'air correct)

Une adresse e-mail peut sembler parfaite et quand même échouer au moment où vous envoyez un message de confirmation. « [email protected] » a la bonne forme et passe une vérification de format basique, mais cela ne signifie pas que le domaine derrière peut réellement recevoir du courrier.

La différence est simple :

• Une adresse qui a l'air réelle suit le schéma habituel (nom + @ + domaine).
• Une adresse utilisable pointe vers un domaine capable de recevoir du courrier maintenant et qui n'est pas susceptible de poser problème plus tard.

Quand les équipes sautent les vérifications au niveau du domaine, les problèmes apparaissent en aval : le taux de rebond augmente, des inscriptions frauduleuses ou de faible qualité passent (y compris des adresses jetables), la délivrabilité se dégrade avec le temps et les rapports deviennent bruyants.

Un scénario courant : un essai gratuit est lancé et les inscriptions montent en flèche, mais une partie des utilisateurs ne clique jamais sur l'e-mail de vérification parce qu'il n'arrive jamais. Les tickets support s'accumulent, le marketing blâme l'outil d'e-mailing, le produit blâme les « mauvais leads ». Souvent, beaucoup de ces adresses n'étaient de toute façon pas joignables.

La vérification du domaine e-mail vous aide à détecter cela tôt. Elle vérifie si le domaine après le « @ » est configuré pour accepter le courrier et peut signaler des indices de risque courants (comme les fournisseurs jetables), pour que les mauvaises adresses ne polluent pas silencieusement votre base.

Le but n'est pas de bloquer aveuglément. C'est de s'accorder sur des règles d'acceptation qui correspondent au business : ce que vous autorisez, ce que vous avertissez, et ce que vous refusez.

Ce qu'est (et n'est pas) la vérification de domaine e-mail

La vérification de domaine e-mail vérifie si la partie domaine d'une adresse e-mail (la partie après @) semble capable de recevoir du courrier. C'est plus que « est-ce que ça ressemble à une adresse e-mail ? » et moins que « est-ce une vraie personne avec une boîte fonctionnelle ? »

Trois idées sont souvent confondues :

• Vérification de syntaxe : L'adresse est-elle écrite dans un format valide (par exemple [email protected]), sans caractères interdits ?
• Vérification de domaine : Le domaine existe-t-il et est-il configuré pour accepter les e-mails ?
• Vérification au niveau de la boîte : La boîte spécifique existe-t-elle ([email protected] reçoit-elle réellement du courrier) ?

La vérification de domaine est la couche intermédiaire. Elle confirme généralement que le domaine est réel et que ses paramètres DNS incluent des enregistrements de routage mail (souvent via une vérification des enregistrements MX). Si un domaine n'a pas de configuration mail, l'envoi vers ce domaine entraînera presque toujours un rebond.

Ce qu'elle ne peut pas prouver : elle ne peut pas confirmer qu'une boîte spécifique existe, qu'un humain la possède, ou que l'utilisateur y a accès. Un domaine peut être correctement configuré tandis qu'une adresse spécifique sous ce domaine est incorrecte, bloquée ou jamais créée.

Une façon pratique d'y penser : la vérification de domaine répond à « est-ce livrable en principe ? » et non « est-ce que cet utilisateur est réel ? »

Les vérifications en coulisses : domaine, DNS et MX

Quand quelqu'un tape une adresse e-mail, la partie après le @ est un domaine (comme example.com). La vérification de domaine pose une question : est-ce que ce domaine semble pouvoir recevoir des e-mails maintenant ?

Le domaine existe (DNS en termes simples)

Le DNS est le carnet d'adresses d'Internet. Un domaine « existe » quand ce carnet contient des enregistrements pour lui. S'il n'y a aucun enregistrement DNS, le domaine est probablement mal tapé, expiré ou jamais configuré.

Même quand un site web se charge, l'e-mail peut être cassé. Beaucoup de domaines sont enregistrés mais à peine utilisés, ou configurés seulement pour un site. L'e-mail nécessite ses propres paramètres.

Le mail est accepté (ce que disent les enregistrements MX)

Les enregistrements MX sont des entrées DNS qui indiquent où livrer les e-mails pour un domaine. Si un domaine a des enregistrements MX valides, cela signifie généralement qu'il est configuré pour recevoir des e-mails.

Si les enregistrements MX sont absents, cela ne veut pas automatiquement dire que l'adresse est fausse, mais c'est un signal fort que le domaine n'est pas configuré pour le mail (ou est mal configuré). Pour la plupart des parcours d'inscription, l'absence ou l'invalidité des MX est une bonne raison de bloquer ou de demander une autre adresse.

Les équipes s'accordent généralement sur des résultats comme ceux-ci :

• Si le DNS est manquant, c'est probablement une faute de frappe ou un domaine mort (rejeter).
• Si les MX sont présents et ont l'air normaux, c'est probablement livrable (accepter).
• Si les MX sont absents ou cassés, il est probable que le domaine ne soit pas configuré pour le mail (bloquer ou demander correction).
• Si le domaine existe mais pointe vers une infrastructure suspecte, le risque est plus élevé (signaler ou bloquer).

Pannes temporaires vs permanentes (les re-tentatives comptent)

Toutes les pannes ne sont pas définitives. Parfois, les serveurs DNS mettent du temps à répondre ou un fournisseur mail a une brève panne. Ce sont des échecs temporaires et doivent être retentés. Les échecs permanents (comme « domaine n'existe pas » ou « aucun enregistrement ») ne devraient généralement pas l'être.

Ce qu'il faut décider : règles d'acceptation que les équipes peuvent s'accorder

Avant de débattre des outils, mettez-vous d'accord sur les résultats. Les règles d'acceptation sont des décisions sur ce que vous faites quand une adresse semble risquée. Le but n'est pas une détection parfaite, mais un comportement cohérent sur lequel utilisateurs, support et reporting peuvent compter.

La plupart des équipes s'en sortent bien avec trois actions :

• Autoriser : procéder normalement.
• Avertir : laisser l'utilisateur continuer, mais ajouter de la friction (confirmation supplémentaire, limites réduites ou une invite claire à changer d'adresse).
• Bloquer : empêcher l'inscription ou exiger une autre adresse.

Définissez « avertir » en une phrase pour que cela ne devienne pas une pochette de exceptions.

Où tracer les limites

Un point de départ simple est de mapper des cas courants à une action :

• Domaines e-mail jetables : généralement bloquer (ou avertir si vous servez des utilisateurs soucieux de la vie privée).
• Comptes de rôle (support@, sales@, admin@) : souvent avertir, car ils peuvent être partagés et difficiles à lier à une seule personne.
• Fournisseurs gratuits (Gmail, Outlook) : typiquement autoriser, sauf si vous êtes strictement B2B.
• Domaines d'entreprise sans configuration mail fonctionnelle (pas de MX) : bloquer, ou autoriser uniquement après vérification par e-mail.
• Domaines inconnus ou nouveaux : autoriser mais surveiller, ou avertir si la fraude est un problème connu.

Une fois ces limites posées, implémentez la même logique partout où l'e-mail entre dans votre système (formulaires d'inscription, invitations, importations CSV, portails partenaires). Des règles incohérentes sont une source silencieuse de tickets support.

Réalités régionales et linguistiques

Si vous vendez à l'international, un « fournisseur gratuit » est souvent local. Bloquer des fournisseurs régionaux inconnus peut couper des inscriptions dans certains pays sans que personne ne le remarque. Décidez si vos règles sont globales ou spécifiques à un marché, et qui gère les exceptions.

Notez aussi le compromis : des règles plus strictes réduisent la fraude et les rebonds, mais peuvent aussi bloquer de vrais utilisateurs et augmenter la charge du support. Des règles plus laxistes augmentent la conversion, mais peuvent générer des inscriptions frauduleuses et nuire à la délivrabilité. Si ce compromis est documenté, produit et marketing mesureront le succès de la même façon.

Étape par étape : définir les règles de vérification de domaine pour l'inscription

Commencez par définir ce qu'une « bonne » inscription signifie pour votre entreprise. La priorité est-elle une activation rapide, moins de rebonds, une meilleure qualité de leads ou moins de fraude ? Si le produit veut moins de tickets support et que le marketing veut une meilleure délivrabilité, formalisez ces objectifs. Sinon, les règles changeront au gré des plaintes.

Ensuite, choisissez des résultats qui correspondent à un risque réel, pas à l'instinct. Un schéma simple :

• Accepter pour les domaines normaux et livrables.
• Avertir pour les cas fragiles où vous voulez que l'utilisateur réessaie ou confirme plus tard.
• Bloquer pour les cas à risque clair (domaines jetables connus, domaines inexistants, domaines sans configuration mail fonctionnelle).

Pour rendre le déploiement gérable, concentrez-vous sur quelques étapes concrètes :

• Choisir des métriques de succès (taux d'activation, taux de rebond, conversion essai-payant, taux de fraude).
• Définir vos résultats (autoriser, avertir, bloquer) et où chaque action s'applique (inscription, flux d'invitation, paiement).
• Rédiger des messages utilisateurs clairs et spécifiques sur la marche à suivre.
• Surveiller hebdomadairement (rebonds, conversions et inscriptions signalées).
• Revoir les règles mensuellement au début, puis trimestriellement une fois stabilisées.

Restez pratique dans les messages. Si un domaine échoue à la vérification MX, n'affichez pas « Erreur DNS ». Dites : « Ce domaine e-mail ne peut pas recevoir de messages. Essayez une autre adresse. » Si vous avertissez, proposez une marche à suivre : « Vous pouvez continuer, mais vous devrez confirmer votre e-mail pour activer le compte. »

Enfin, créez une boucle de rétroaction. Suivez la fréquence de chaque résultat et le comportement ultérieur des utilisateurs. Si les utilisateurs « avertis » convertissent bien et ne rebondissent pas, assouplissez la règle. Si les utilisateurs bloqués continuent d'apparaître dans les rapports de fraude, renforcez-la.

Comment produit et marketing doivent mesurer le succès

Le succès n'est pas seulement « plus d'inscriptions ». L'objectif est de garder l'inscription facile pour les vrais utilisateurs tout en réduisant les problèmes coûteux plus tard : rebonds, plaintes et comptes frauduleux.

Suivez deux volets côte à côte : le volume d'amont et la qualité en aval. Si la conversion augmente mais que les rebonds et plaintes explosent, vous n'avez pas gagné.

Métriques que la plupart des équipes peuvent revoir hebdomadairement :

• Taux de conversion d'inscription (visite -> compte créé)
• Taux d'activation (nouveaux utilisateurs atteignant une première action significative)
• Taux de rebond dur sur les e-mails d'onboarding et de campagne
• Taux de plainte pour spam et taux de désabonnement
• Signaux de fraude et abus (comptes en double, abus de coupon, pics d'inscription inhabituels)

Si possible, reliez la qualité des e-mails à l'argent. Une petite baisse des rebonds peut protéger la réputation d'envoi, maintenir les e-mails en boîte de réception et réduire les dépenses gaspillées sur de faux leads.

Pour choisir des règles strictes vs permissives, exécutez un test A/B simple pendant au moins un cycle commercial complet (souvent 1 à 2 semaines). Comparez conversion et métriques de qualité, puis décidez sur l'impact net, pas un seul chiffre en vue.

Erreurs courantes et pièges à éviter

La plupart des problèmes liés aux vérifications e-mail ne sont pas techniques. Ce sont des problèmes de politique. Une règle qui semble sûre peut bloquer de vrais clients ou laisser passer des ordures.

Une erreur classique est de confondre une vérification de format avec une validation réelle. Une regex peut dire si une adresse ressemble à [email protected]. Elle ne peut pas dire si le domaine peut recevoir du courrier ou si l'adresse risque de rebondir. La vérification de domaine se concentre sur ce qui se passe après le signe @, pas seulement sur la forme du texte.

Pièges fréquents :

• Bloquer tous les fournisseurs gratuits par défaut (tue souvent les inscriptions d'étudiants, petites entreprises et évaluateurs).
• Traiter les problèmes DNS temporaires comme des échecs permanents (génère des rejets faux).
• S'arrêter aux vérifications de syntaxe (vous accepterez encore des fautes de frappe et des domaines sans configuration mail).
• Laisser les listes de domaines jetables devenir obsolètes (elles évoluent rapidement).
• Utiliser des erreurs vagues comme « E-mail invalide » (les utilisateurs ne savent pas quoi corriger).

Un exemple simple : quelqu'un s'inscrit depuis le Wi‑Fi d'un café. Une recherche DNS a expiré une fois. Si votre système bloque immédiatement, vous venez de perdre un vrai lead à cause d'un micro-coup de réseau.

De meilleurs réglages par défaut réduisent la fraude sans pénaliser les bons utilisateurs :

• Réessayer ou adoucir l'échec sur les timeouts, et échouer de façon définitive seulement sur des signaux clairs (domaine inexistant ou absence de routage mail).
• Autoriser les fournisseurs gratuits sauf données contraires, et rendre les exceptions faciles.
• Maintenir la détection des jetables à jour.
• Rédiger des messages d'erreur qui expliquent la prochaine étape (par exemple : « Nous n'avons pas pu vérifier ce domaine pour le moment. Réessayez ou utilisez une autre adresse. »).

Cas limites que vous rencontrerez en pratique

La plupart des inscriptions sont simples. La partie délicate est de gérer les cas où la vérification de domaine ne donne ni oui ni non, même pour une vraie personne.

Les domaines internationaux et moins courants peuvent surprendre. Les clients peuvent utiliser des domaines nationaux (comme .de ou .br) ou des extensions plus récentes. Certains domaines utilisent des caractères non latins (IDN), qui peuvent paraître étranges dans les logs mais sont valides.

Les nouveaux domaines sont un autre cas limite fréquent. Une startup peut acheter un domaine aujourd'hui et commencer à collecter des inscriptions avant que les changements DNS ne se propagent complètement. Pendant quelques heures, le même domaine peut sembler valide depuis une région et absent depuis une autre.

Les domaines d'entreprise peuvent aussi être particuliers. Certaines grandes entreprises utilisent un DNS fractionné (réponses différentes selon votre emplacement) ou des configurations verrouillées qui ne ressemblent pas à l'ordinaire.

Vous verrez aussi des échecs de recherche intermittents. Les utilisateurs derrière VPN, réseaux d'entreprise ou outils de sécurité agressifs peuvent provoquer des timeouts temporaires. Ce n'est pas la même chose qu'un domaine invalide.

Quand un outil renvoie « inconnu », cela signifie généralement « impossible de confirmer pour le moment », pas « faux ». Une politique pratique :

• Réessayer une ou deux fois dans une courte fenêtre.
• Autoriser l'inscription mais exiger la confirmation par e-mail avant activation.
• Bloquer seulement quand les résultats sont clairement invalides.
• Signaler les cas risqués (comme les fournisseurs probablement jetables) pour vérification supplémentaire.
• Journaliser les « inconnus » séparément pour repérer des motifs.

Checklist rapide avant de déployer de nouvelles règles

Avant de changer les règles d'inscription, assurez-vous que tout le monde s'accorde sur ce qu'est « bon » et « mauvais ». Un petit ajustement peut déplacer les inscriptions, la conversion essai-payant et la délivrabilité dans différentes directions.

Vérifications pré-lancement

Testez les règles sur un échantillon d'inscriptions récentes (clients légitimes et spams évidents). Prenez des notes sur ce que vous bloqueriez et pourquoi, pour que l'équipe puisse revoir les compromis.

• Confirmez que le domaine peut recevoir des e-mails (domaine existant et routage mail fonctionnel, souvent prouvé par une vérification MX).
• Décidez comment vous traiterez les domaines jetables et à haut risque (bloquer, avertir, limiter ou vérification supplémentaire).
• Décidez du traitement des adresses de rôle comme info@, sales@, support@.
• Définissez la marche à suivre pour les résultats incertains (timeouts et problèmes DNS temporaires).
• Confirmez que vous pouvez mesurer l'impact (taux de rebond, plaintes pour blocage injustifié, activation d'essai).

Rendre le plan de repli explicite

La plupart des débats ont lieu dans la zone grise, pas sur les faux évidents. Écrivez la voie de repli pour les cas incertains et qui prend la décision quand les métriques sont contradictoires (le marketing veut moins de rebonds, le produit veut moins d'utilisateurs bloqués).

Un exemple simple : s'aligner sur les règles pour une inscription d'essai

Une équipe B2B SaaS voit ses inscriptions d'essai augmenter de 18 % d'un mois sur l'autre, mais les commerciaux rapportent que les « nouveaux leads » ne répondent pas. Le marketing constate une augmentation des rebonds et le produit trouve de nombreux comptes créés avec des adresses jetables.

Ils resserrent leurs règles sans tuer les vraies inscriptions.

D'abord, ils choisissent une politique claire : les domaines jetables sont bloqués à l'inscription. Les comptes de rôle (info@, sales@, support@) sont autorisés, mais le formulaire affiche un avertissement doux : « Pour une configuration plus rapide et la récupération de compte, utilisez votre e-mail professionnel. » Le produit gère l'UX et la formulation, le marketing gère le ton, et les ventes définissent ce qui compte comme un lead utile.

Au bout de deux semaines, ils réexaminent les résultats ensemble. La conversion baisse légèrement, mais le taux de rebond chute significativement. Les comptes frauduleux dans les premières 24 heures diminuent, et les commerciaux signalent moins d'impasses même si le volume total est un peu inférieur.

Ils ajustent à partir des preuves. Le marketing affine le message pour réduire la friction. Le produit ajoute un indice « Réessayez » plus clair quand une adresse est bloquée pour que les vrais utilisateurs ne soient pas bloqués. Ils ajoutent aussi de la surveillance : comptes bloqués pour domaines jetables, taux de rebond, conversion essai->activation et part des inscriptions avec comptes de rôle.

Prochaines étapes : documenter, déployer et maintenir les règles

Considérez vos règles comme une décision produit, pas un réglage ponctuel. Quand produit et marketing s'accordent sur les résultats (moins de fausses inscriptions, moins de rebonds, moins de tickets support), il devient beaucoup plus simple de décider quoi bloquer et quoi autoriser.

Rédigez un document partagé clair que tout le monde peut comprendre :

• Ce que « réussir » et « échouer » signifient pour la vérification de domaine
• Ce qui se passe en cas d'échec (bloquer, avertir ou permettre avec friction)
• Exceptions connues (partenaires, grands clients, domaines internes)
• Qui peut approuver les changements et qui est propriétaire des métriques
• Quelques exemples concrets et le résultat attendu

Déployez par étapes pour ne pas couper les bons utilisateurs :

• Semaine 1 : avertir seulement et journaliser les raisons d'échec
• Semaine 2 : bloquer les cas manifestement mauvais (domaine inexistant, pas de serveur mail)
• Semaine 3 : durcir la détection des jetables et signaux à haut risque
• En continu : revoir les blocages erronés et ajouter des exceptions ciblées

Si vous voulez exécuter ces vérifications via un service unique, Verimail (verimail.co) est une API de validation d'e-mails qui combine des vérifications conformes RFC, la vérification de domaine, des recherches d'enregistrements MX et la détection en temps réel des adresses jetables/listes de blocage, afin que vous puissiez appliquer les mêmes règles sur vos formulaires et votre backend.

Mettez un rappel simple (une révision mensuelle convient à la plupart des équipes) pour examiner le taux de rebond, le taux de complétion d'inscription et combien d'utilisateurs ont été avertis ou bloqués, puis ajustez selon les données.