Quand la validation d'email échoue, utilisez ce playbook de support pour vérifier les déclarations des utilisateurs, confirmer les causes techniques et appliquer des dérogations sûres sans inviter la fraude.
Parce que la validation vérifie plus que le fait d'avoir déjà reçu un message. Elle examine aussi le format de l'email, la configuration du domaine, les enregistrements MX et les signaux de risque (par exemple, fournisseurs jetables ou listes de blocage), et chacun de ces éléments peut échouer même si la boîte paraît “réelle” à l'utilisateur.
Demandez l'adresse exacte en texte brut copiée-collée, l'heure de la tentative et le message d'erreur exact. Demandez aussi s'ils ont tapé, collé ou utilisé l'autocomplétion, car les espaces invisibles et les caractères “intelligents” sont des causes fréquentes.
Les captures d'écran cachent des détails importants comme des espaces finaux, des caractères invisibles ou une ponctuation intelligente qui change ce que le système reçoit. Le copier-coller en texte brut permet de tester la valeur exacte et de repérer rapidement de petites différences.
La plupart des échecs appartiennent à cinq catégories : format (syntaxe), problèmes de domaine, incertitude sur la boîte, blocages liés au risque/politique (jetables, pièges à spam, domaines bloqués) et défaillances techniques temporaires comme des timeouts DNS. Nommer la catégorie dans votre réponse aide l'utilisateur à savoir quoi changer.
Les erreurs de syntaxe sont des problèmes de format comme l'absence de @, des doubles points, des caractères non autorisés ou des espaces au début/à la fin. Elles échouent généralement immédiatement ; la correction consiste à retaper l'adresse soigneusement et à supprimer les espaces superflus.
Souvent, cela signifie que la partie domaine est mal orthographiée (comme gmial.com), qu'une terminaison est erronée (comme .con) ou que le domaine n'a pas de routage mail fonctionnel pour le moment. Une étape pratique est d'essayer un autre fournisseur d'email ou de demander à l'utilisateur de vérifier l'orthographe du domaine après le @.
Certains fournisseurs bloquent les vérifications “est-ce que cette boîte existe ?”, donc le système ne peut pas confirmer la boîte même si elle existe. Dans ce cas, utilisez une preuve plus sûre comme un code à usage unique (OTP) envoyé par email plutôt que d'assumer que l'adresse est valide.
Le plus simple est d'essayer l'adresse sans tag (par exemple [email protected]) : les plus-addresses ([email protected]) sont acceptées par de nombreux fournisseurs, mais pas par tous. Si l'adresse de base fonctionne, notez que le fournisseur de l'utilisateur peut ne pas supporter les tags.
Une nouvelle tentative après une minute ou deux peut résoudre un problème transitoire (timeouts, erreurs DNS temporaires). Si cela échoue encore, proposez une voie sûre comme une adresse alternative ou un examen manuel plutôt qu'une dérogation automatique.
Utilisez des exceptions contrôlées : enregistrez la raison renvoyée par le validateur, exigez une preuve de contrôle (comme un OTP), et rendez les dérogations limitées dans le temps, liées au compte, plafonnées et faciles à révoquer. Évitez de déroger aux signaux de risque clairs comme les fournisseurs jetables ou les pièges à spam connus.
Un ticket de support courant ressemble à ceci : « Cet email est à moi. Je reçois des messages. Pourquoi votre inscription ne l'accepte-t-elle pas ? » L'utilisateur n'a pas toujours tort. Une adresse peut être réelle et pourtant échouer aux contrôles automatisés, selon ce que votre système cherche à protéger.
La plupart des validations portent surtout sur le risque et la délivrabilité, pas seulement sur « la boîte existe-t-elle ». Beaucoup de vérifications se concentrent sur tout ce qui entoure la boîte : la configuration du domaine, si les serveurs mail sont joignables, et si l'adresse semble liée à un fournisseur jetable. Certaines vérifications sont aussi sensibles au temps. Un domaine peut être mal configuré aujourd'hui et réparé demain.
Une boîte réelle peut être bloquée pour des raisons comme :
Le rôle du support est d'aider les vrais utilisateurs à terminer l'inscription tout en gardant les mauvaises inscriptions à l'écart. Un validateur peut repérer rapidement les fournisseurs jetables, les pièges à spam, les domaines invalides et les problèmes de syntaxe, mais il ne peut pas décider de votre politique commerciale à votre place.
Ce que le support peut modifier, c'est la façon dont la vérification fonctionne, quelles preuves vous acceptez et s'il existe une voie de dérogation sûre. Ce que le support ne peut généralement pas changer, ce sont la configuration du domaine de l'utilisateur, une panne DNS d'un fournisseur, ou une décision de blocage délibérée visant à protéger la plateforme.
La première réponse doit viser des détails exacts et utilisables. La plupart des cas « c'est valide » se résolvent par des problèmes simples de saisie ou un décalage entre ce que l'utilisateur a tapé et ce que votre système a réellement reçu.
Demandez l'adresse email en texte brut, copiée-collée. N'acceptez pas de captures d'écran. Les captures masquent les fautes de frappe, les caractères invisibles et la ponctuation intelligente qui peuvent changer la valeur.
Un jeu serré de questions vous mène vite à la source :
Une fois que vous avez l'adresse, vérifiez les problèmes invisibles avant d'aller plus loin. Les espaces au début ou à la fin sont fréquents. Les caractères cachés provenant d'apps de messagerie, comme les espaces insécables, le sont aussi. Un test rapide consiste à coller l'adresse dans un champ texte brut puis à la recopier depuis là.
Si vous utilisez une API de validation d'emails, capturez les détails du résultat dans les notes internes (statut et raison). Cela évite qu'un autre agent repose les mêmes questions.
Un exemple classique : un utilisateur jure que « [email protected] » est correct, mais la valeur copiée-collée est en réalité « [email protected] » avec un espace final. Corriger cela évite de longs échanges et garde le ton sympathique. Vous ne mettez pas en doute l'utilisateur, vous vérifiez ce que le système a reçu.
Les utilisateurs entendent souvent « votre email est incorrect » même quand il a l'air correct à l'écran. Vous résoudrez les tickets plus vite en nommant le type d'échec en termes simples, pour que l'utilisateur sache quoi changer.
Ce sont les plus simples et viennent souvent du copier-coller. Les problèmes courants incluent un @ manquant, des espaces en trop, des doubles points (comme name..last) ou des caractères non autorisés. Un indice est quand l'adresse échoue instantanément, avant tout contrôle de domaine.
La partie gauche peut être parfaite, mais le domaine peut être faux. Cela signifie généralement une faute de frappe (gmial.com), une terminaison incorrecte (.con au lieu de .com) ou un domaine qui n'existe plus. Certains domaines utilisent aussi des caractères internationaux qui ressemblent à des lettres latines, ce qui peut entraîner des fautes involontaires.
Parfois le domaine est réel, mais la boîte spécifique ne l'est pas. L'utilisateur a peut-être mal tapé son nom, la boîte a été supprimée ou le compte désactivé. Certains fournisseurs bloquent les vérifications « cette boîte existe-t-elle ? », donc le système peut retourner « impossible à confirmer » plutôt que « valide ».
Beaucoup d'adresses « valides » sont réelles mais inacceptables pour votre plateforme. Exemples : adresses jetables, pièges à spam connus ou motifs liés aux abus (comme de nombreuses inscriptions similaires). Des outils comme Verimail détectent cela via des listes de blocage et d'autres signaux, donc l'échec porte sur le risque, pas l'orthographe.
Tous les échecs ne signifient pas que l'utilisateur a fait une erreur. Les timeouts DNS, les recherches MX lentes ou les pannes de fournisseur peuvent provoquer un échec temporaire.
Dans vos réponses, il aide de classer le résultat dans l'une de ces cinq catégories, puis de demander une nouvelle saisie (ne pas coller) et un second essai. Cela garde la conversation ciblée et réduit les allers-retours.
Vous pouvez généralement confirmer la cause avec quelques vérifications rapides sans fouiller les logs ni utiliser d'outils DNS avancés.
Commencez par vous assurer que vous testez exactement la même adresse que celle saisie par l'utilisateur.
Retapez l'email manuellement et comparez caractère par caractère à la soumission originale. Supprimez les espaces en tête/queue et cherchez les caractères invisibles (le copier depuis des notes ou des tableurs est une source commune). Repérez les fautes de domaine classiques comme gmal.com, hotnail.com, yaho.com, ou l'absence de points.
Ensuite, vérifiez si le domaine est réel et peut recevoir des mails (le domaine existe et a des enregistrements MX). Si votre validateur rapporte un échec de domaine ou de MX, demandez à l'utilisateur d'essayer un autre fournisseur.
Si la détection d'email jetable a déclenché, c'est là que la politique entre en jeu. Décidez si votre produit bloque toujours ces adresses, les autorise seulement dans des situations spécifiques, ou propose un autre chemin de vérification.
Après ces contrôles, envoyez une réponse courte et précise. Par exemple : « J'ai retesté l'adresse et il semble que le domaine n'ait pas de serveur mail (MX) configuré pour le moment. Pouvez-vous essayer avec un autre fournisseur d'email ? »
Certains échecs sont liés au timing. Un fournisseur peut avoir un bref problème DNS, ou votre système peut voir une erreur de lookup temporaire.
Attendez une minute ou deux et réessayez, surtout si l'erreur suggère un problème passager (timeout, erreur DNS transitoire ou « réessayez »). Si votre validateur distingue « invalide » et « temporaire », utilisez cela pour orienter l'étape suivante.
Si cela échoue encore après une nouvelle tentative, donnez à l'utilisateur une voie sûre : demandez une adresse alternative. S'il n'a qu'une seule adresse, proposez un examen manuel plutôt qu'une dérogation générale, afin de ne pas ouvrir la porte aux pièges à spam, inscriptions factices ou boîtes jetables.
La plupart des utilisateurs n'essaient pas de tricher. Ils essaient l'adresse qu'ils utilisent toujours et se sentent bloqués. L'objectif est de reconnaître la frustration, d'expliquer la catégorie du problème en termes simples et de donner une étape claire.
« C'est un email réel, je l'ai déjà utilisé. » (fournisseur jetable ou temporaire) Certains services offrent des boîtes à vie courte. Beaucoup d'apps les bloquent car elles servent souvent pour des inscriptions factices et peuvent nuire à la délivrabilité. Réponse : « Nous bloquons certains fournisseurs d'emails temporaires pour protéger les comptes. Si vous avez une autre adresse (pro, scolaire ou personnelle à long terme), essayez celle-là. »
« C'est mon email pro, mais il est redirigé vers Gmail. » (boîte redirigée ou domaine personnalisé) Le transfert est courant et n'invalide pas l'adresse. Le domaine doit quand même accepter le courrier. Réponse : « La redirection est OK. Nos vérifications regardent la configuration mail du domaine (comme les enregistrements MX). Si votre équipe IT a récemment modifié les paramètres, cela peut prendre du temps pour se propager. »
« C'est [email protected]. » (plus addressing) Les plus-tags sont valides chez beaucoup de fournisseurs, mais pas tous. Réponse : « Certains fournisseurs acceptent les plus-tags, d'autres non. Essayez l'adresse de base ([email protected]). Si cela fonctionne, nous pourrons noter que votre fournisseur peut ne pas supporter les tags. »
« J'utilise info@ / support@. » (adresse de rôle) Elles peuvent être réelles, mais souvent partagées et à risque plus élevé pour les abus. Réponse : « Nous pouvons restreindre l'utilisation des boîtes partagées. Si possible, utilisez une adresse personnelle. Si vous devez utiliser une adresse de rôle, dites-le nous et nous vérifierons si notre politique l'autorise. »
« Lisez-vous mes emails ? » (préoccupation vie privée) Soyez direct : « Non. Les vérifications regardent le format de l'adresse et des signaux sur le domaine (syntaxe, contrôles domaine/MX et correspondance aux listes de blocage). Elles n'accèdent pas à votre boîte ni ne lisent vos messages. »
Une phrase de clôture utile : « Si vous partagez le domaine (la partie après @), nous pouvons dépanner sans que vous envoyiez l'adresse complète. »
La plupart des tickets répétés viennent de faire la chose “rapide” plutôt que la chose claire.
Un piège fréquent est de copier-coller depuis des apps de messagerie. Certaines apps ajoutent des caractères cachés comme des espaces insécables, des guillemets “intelligents” ou un espace final après l'adresse. L'utilisateur voit un email normal, mais votre système reçoit autre chose. Demandez à l'utilisateur de retaper l'adresse dans le champ d'inscription (ne pas coller), ou de la coller d'abord dans un éditeur de texte brut.
Une autre erreur est de supposer que « j'ai reçu votre email » signifie que la boîte est joignable de façon fiable. Un utilisateur peut recevoir un reset de mot de passe par un canal différent, ou avoir un message transféré, alors que le domaine a quand même des enregistrements MX cassés ou un problème DNS temporaire. Les lookups domaine et MX (comme ceux que font des outils type Verimail) évaluent si le mail peut atteindre cette boîte de façon fiable maintenant, pas si un message est arrivé une fois.
Le support génère aussi des tickets supplémentaires en traitant chaque échec comme une fraude. Séparez les types d'erreur dans vos réponses. Les erreurs de syntaxe demandent une correction de format. Les problèmes de domaine ou MX demandent à l'utilisateur de vérifier son fournisseur ou d'essayer une autre adresse. Les hits sur jetables ou bloclists demandent une explication de politique et une voie sûre.
Le moyen le plus rapide de causer des abus est d'autoriser des exceptions sans raison. Si vous accordez une dérogation, enregistrez pourquoi, qui l'a approuvée et quelles preuves ont été vues (par exemple, l'utilisateur a vérifié la propriété via un code à usage unique). Sans notes, le prochain agent accordera de nouveau la dérogation et le schéma se répandra.
Enfin, évitez de bloquer des domaines entiers à cause d'une seule inscription suspecte. Cela touche souvent des utilisateurs réels en entreprise, école ou fournisseurs régionaux. Si vous devez agir, ciblez le motif spécifique ou ajoutez une règle temporaire avec expiration.
Un petit ensemble d'habitudes qui évite les réouvertures :
Quand une adresse échoue à la validation, le support subit souvent la pression de « laissez-la passer ». Une approche plus sûre est de traiter les dérogations comme des exceptions contrôlées, pas des réglages cachés.
Commencez par journaliser ce qui s'est passé de façon à ce que les agents futurs puissent s'y fier. Quel que soit le validateur utilisé, enregistrez la catégorie d'échec et la raison au format machine pour repérer des motifs plus tard.
Un standard de journalisation simple :
Ensuite, décidez quelles erreurs sont éligibles à une dérogation. Envisagez seulement les cas à faible risque et vraisemblablement faux positifs comme un timeout DNS temporaire, un domaine tout neuf dont le DNS est en propagation, ou un domaine d'entreprise avec routage mail inhabituel. N'accordez pas de dérogation sur des signaux de risque clairs comme la détection d'emails jetables, des motifs de pièges à spam connus ou une syntaxe invalide.
Pour sécuriser les dérogations, ajoutez un second facteur. L'option la plus propre est un OTP envoyé par email à l'adresse en question. Si l'utilisateur ne peut pas recevoir d'OTP, exigez une vérification manuelle (par exemple, confirmer la propriété depuis une session déjà connectée, ou fournir une preuve d'entreprise).
Limitez et rendez visibles chaque dérogation :
Utilisez à la fois allowlists et denylists, mais avec un processus. Pour une allowlist, exigez une étape d'approbation interne (chef d'équipe ou responsable risque) et documentez la raison. Pour les abus répétés, ajoutez une règle denylist afin que le support n'ait pas à combattre le même incendie chaque semaine.
La façon la plus rapide de distinguer « problème de politique » et « motif d'attaque » est d'arrêter de regarder une seule adresse et d'en analyser un petit échantillon. Prenez un échantillon d'échecs récents et notez deux choses pour chacun : un email masqué (comme j***@example.com) et la raison exacte renvoyée par votre validateur.
Si la plupart des échecs partagent une raison claire et cohérente (par exemple « fournisseur jetable bloqué » ou « domaine sans MX »), vous voyez probablement des vrais utilisateurs touchés par une règle que vous avez choisie. Si les raisons sont mélangées et bruyantes, ou si les échecs montent soudainement, considérez cela comme suspect jusqu'à explication.
Un problème de politique a souvent l'air ennuyeux et cohérent. Vous pouvez voir beaucoup de personnes réelles utilisant le même fournisseur que vos règles rejettent (courant avec la détection d'email jetable ou des contrôles de domaine stricts). Les taux d'échec peuvent aussi être plus élevés dans un pays si un FAI local a un DNS instable ou un routage mail inhabituel.
Le comportement utilisateur est un indice : ils essaient une ou deux fois, contactent le support avec du contexte, et leurs adresses ressemblent à des noms normaux, pas à des chaînes aléatoires.
Les attaques ont tendance à se regrouper. Surveillez des motifs comme :
Exemple : 200 inscriptions en 10 minutes depuis une plage IP étroite, toutes avec aaaaa1@, aaaaa2@, aaaaa3@ sur le même domaine récent. Ce n'est pas de la confusion, c'est de l'automatisation.
Quand vous trouvez de tels clusters, escaladez avec des échantillons masqués, horodatages, plages IP et raisons d'échec vers votre équipe fraude ou sécurité. Si c'est un problème de politique, ajustez la règle ou le message pour que les utilisateurs sachent quoi faire ensuite (utiliser un email pro, essayer une autre adresse ou contacter le support). Des outils comme Verimail aident ici car les échecs viennent avec des raisons spécifiques que vous pouvez grouper et traiter.
Quand l'utilisateur dit « c'est vraiment réel », concluez proprement avec une vérification cohérente. Cela garde les réponses courtes, réduit les réouvertures et rend les décisions plus faciles à défendre plus tard.
Avant de clôturer, confirmez :
@, et des caractères normaux (vérifiez les espaces invisibles).Après décision, écrivez deux lignes de notes pour que le prochain agent ne reparte pas de zéro : ce qui a échoué (syntaxe, domaine, MX, jetable ou politique) et ce qui s'est passé (corrigé par l'utilisateur, confirmé via email, ou refusé avec raison). Si vous avez utilisé une dérogation, notez qui l'a approuvée et si elle est temporaire ou permanente.
Clôturez avec un résultat clair et une action suivante : « Veuillez corriger X et réessayer » ou « Nous avons autorisé cette adresse une fois, mais les futures inscriptions doivent utiliser un email non jetable. »
Un ticket courant commence ainsi : « Votre formulaire dit que mon email est invalide, mais il fonctionne. » Le chemin le plus rapide est une vérification factuelle courte et amicale.
Un utilisateur saisit [email protected] et insiste que c'est correct. Votre validateur le signale parce que le domaine n'a pas d'enregistrements MX (et souvent pas d'infrastructure mail active). L'utilisateur ne ment pas — il lit ce qu'il voulait écrire, pas forcément ce qu'il a tapé.
Un flux d'agent qui résout la plupart des cas en moins de deux minutes :
Une fois l'utilisateur réussi, clôturez avec des notes claires : l'adresse originale contenait une faute sur le domaine et n'a pas passé les contrôles MX.
Parfois l'utilisateur est sur un vrai domaine d'entreprise (par exemple [email protected]), mais le DNS a un mauvais moment. Les enregistrements MX manquent, sont lents à résoudre ou ont été changés récemment.
Dites à l'utilisateur que vous pensez que l'adresse peut être réelle et demandez-lui de réessayer dans 10–15 minutes. Si la tentative suivante passe, notez-le comme une défaillance temporaire de domaine/MX et clôturez le ticket. Si cela persiste, aiguiller vers votre parcours de « vérifications de domaine » plutôt que de discuter avec l'utilisateur.
Le support devient plus simple quand le produit enseigne un peu en amont. La plupart des tickets répétés proviennent de messages vagues, de politiques peu claires ou d'agents gérant chaque cas de manière différente.
Commencez par le message d'erreur. Rendez-le spécifique, poli et actionnable. « Email non valide » sonne comme une accusation. « Nous n'avons pas pu vérifier cette adresse pour le moment » garde un ton neutre et ouvre la porte à expliquer quoi essayer.
Un schéma simple qui réduit les allers-retours :
Ajoutez des conseils en libre-service dans l'UI d'inscription, près du champ email. Un petit indice comme « Vérifiez l'orthographe et supprimez les espaces » capture les erreurs courantes. Si vous bloquez les adresses jetables, dites-le clairement. Les utilisateurs pensent souvent être ciblés alors qu'il s'agit simplement d'une règle.
Rédigez une politique de dérogation et formez l'équipe dessus. Décidez quelles preuves vous acceptez et quand un agent peut autoriser une exception (et pour combien de temps). Gardez-la étroite et cohérente afin d'aider les vrais utilisateurs sans inviter l'abus.
Suivez les effets en regardant deux chiffres ensemble : le taux de dérogation et le taux de rebond. Si les dérogations augmentent et que les rebonds augmentent aussi, la politique est trop laxiste. Si les dérogations baissent mais que les tickets augmentent, vos messages ou conseils UI ne sont probablement pas assez clairs.
Si vous standardisez le flux autour d'un validateur, alignez les « raisons support » internes aux catégories renvoyées par l'outil pour que les agents agissent de manière cohérente. Pour les équipes utilisant Verimail, cela signifie souvent mapper les résultats comme problèmes de syntaxe, domaine/MX, et fournisseurs jetables ou bloclists dans un arbre de décision cohérent et un petit ensemble de modèles de réponse.
Si vous voulez un moyen rapide de tester et d'ajuster ces contrôles pendant l'inscription, Verimail (verimail.co) est conçu pour la validation en temps réel : contrôles de syntaxe conformes RFC, vérification de domaine, lookups MX et correspondance aux bloclists de fournisseurs jetables, le tout dans un seul appel d'API. Cela donne au support des raisons plus claires à partager en interne et moins de tickets gris à débattre.