Stratégie de réessai pour la validation des e-mails face aux pannes temporaires DNS et réseau, en utilisant des timeouts pratiques, des reprises avec backoff et des états de repli sûrs.
Les problèmes DNS et réseau arrivent tout le temps, même quand l'adresse e-mail est réelle. L'ISP d'un utilisateur peut perdre des paquets quelques secondes, un résolveur DNS d'entreprise peut traîner, ou l'hébergeur DNS d'un domaine peut subir un court incident. Votre validateur peut tout faire correctement et ne pas obtenir de réponse à temps.
Le problème, c'est ce que font beaucoup de flux d'inscription ensuite : ils traitent « pas de réponse » comme « mauvais e-mail ». Cela transforme une incertitude temporaire en refus net. Le coût est immédiat : un bon utilisateur est bloqué, abandonne le formulaire et ne revient souvent jamais. Si vous dépensez en publicité ou faites des campagnes partenaires, vous gâchez aussi du budget en rejetant les personnes que vous avez payées pour attirer.
Les pannes temporaires créent aussi des données sales. Les utilisateurs réessaient avec une autre adresse, tapent plus vite et font des erreurs, ou passent à une adresse jetable juste pour contourner le formulaire. Cela peut nuire à la délivrabilité plus tard plus qu'une approche prudente et conviviale.
L'objectif d'une stratégie de réessai est simple : réduire les faux rejets sans laisser passer les évidents indésirables. Vous voulez toujours bloquer les problèmes clairs comme une syntaxe invalide, les fournisseurs jetables connus et les domaines qui n'existent pas.
Une panne temporaire n'est pas la même chose qu'une adresse invalide. Cela signifie que vous n'avez pas pu terminer une ou plusieurs vérifications (comme une requête DNS ou une vérification MX) dans le délai imparti. Traitez-la comme « inconnu pour l'instant » et concevez le flux d'inscription pour qu'un vrai utilisateur puisse continuer pendant que vous réessayez en arrière-plan ou vérifiez plus tard. Des outils comme Verimail peuvent renvoyer un résultat nuancé (pas seulement accepter/refuser), ce qui facilite ce type de décision.
Une « panne temporaire » est tout résultat où l'e-mail pourrait être correct, mais quelque chose sur le chemin de vérification a été peu fiable. Votre stratégie de réessai doit les traiter comme « incertains » plutôt que « mauvais », afin de ne pas verrouiller de vrais utilisateurs.
Le DNS est la source la plus courante de confusion parce que les résultats ressemblent souvent mais signifient des choses très différentes :
Les problèmes réseau vers votre fournisseur de validation sont aussi souvent temporaires. Un timeout de requête, une connexion tombée ou un problème de routage transitoire ne disent rien sur l'e-mail lui-même. Traitez-les comme réessayables et laissez l'inscription avancer.
Les limites de taux et les erreurs serveur demandent une vue partagée. 429 rate limit et plusieurs réponses 5xx sont souvent temporaires, mais peuvent aussi être « temporaires à cause de vous » (trop de requêtes simultanées). Réessayez-les, mais seulement avec un backoff et un plafond.
Enfin, certaines pannes sont locales à l'utilisateur : blocages DNS d'entreprise, portail captif sur un Wi‑Fi public, ou un incident chez l'ISP. Si un utilisateur rapporte « impossible de s'inscrire » alors que d'autres y parviennent, supposez un problème local et évitez le blocage définitif. Marquez l'adresse comme « non vérifiée pour l'instant » et revérifiez plus tard.
Les timeouts ne sont pas juste un détail technique. Ils déterminent si une vraie personne accède à votre produit ou reste bloquée à regarder un spinner.
Commencez par définir un budget temporel strict pour toute l'étape de validation dans votre flux d'inscription. Pour de nombreuses inscriptions grand public, 300 à 800 ms semble instantané. Pour des flux à risque plus élevé ou B2B, vous pouvez souvent dépenser 1 à 2 secondes, mais dépasser cela doit être un choix délibéré.
Utilisez des timeouts séparés pour chaque dépendance, car elles tombent en panne de manières différentes. Les recherches DNS et MX peuvent se bloquer plus longtemps que prévu lors de problèmes de résolveur, tandis qu'un appel HTTP à une API de validation est généralement plus prévisible.
Une configuration pratique ressemble à ceci :
Quand le budget est épuisé, préférez un échec doux sur les timeouts plutôt qu'un échec fermé. Traitez le résultat comme incertain, pas invalide. Laissez l'utilisateur continuer, mais marquez l'e-mail pour des vérifications ultérieures. Même si votre validateur est rapide en conditions normales, vous avez besoin de votre propre budget afin qu'un réseau lent ne bloque pas toute l'inscription.
Gardez les timeouts cohérents entre web et mobile. Les réseaux mobiles peuvent être plus lents, mais les attentes des utilisateurs sont les mêmes : le bouton doit répondre. Si vous changez les limites par plateforme, vous changez aussi qui se fait bloquer.
Enregistrez les timeouts pour pouvoir affiner ensuite. Suivez quelques compteurs simples : taux de timeout par étape (DNS vs HTTP), latence médiane et p95 de la validation, pourcentage d'inscriptions entrées dans l'état incertain, et résultats ultérieurs (e-mail confirmé, rebond, churn). Ces données vous diront s'il faut augmenter le budget, le resserrer ou vous concentrer sur une dépendance instable.
Une bonne stratégie de réessai n'est pas « réessayer tout », mais choisir les cas où une seconde tentative aide réellement. Si votre recherche DNS ou votre appel réseau échoue une fois, il réussit souvent peu après. Mais si vous continuez à frapper, vous pouvez provoquer votre propre panne.
Utilisez un backoff exponentiel avec jitter. Le backoff réduit la charge. Le jitter (un petit délai aléatoire) évite une « horde tonitruante » lorsque beaucoup d'inscriptions rencontrent la même panne en même temps.
Un schéma simple pour une tentative de validation :
Qu'est‑ce qui est réessayable ? Seules les erreurs susceptibles de se résoudre rapidement, comme les timeouts DNS, les pannes temporaires du serveur DNS, les timeouts réseau et les réponses 5xx en amont. Ne réessayez pas les « non » définitifs comme une syntaxe invalide, des domaines inexistants ou une correspondance confirmée avec un fournisseur jetable.
Séparez les réessais immédiats des réessais en arrière-plan. Les réessais immédiats ont lieu pendant la requête d'inscription, donc gardez-les peu nombreux et rapides. Les réessais en arrière-plan surviennent après la création de l'utilisateur (ou après avoir accepté l'e-mail avec un statut en attente). Ils peuvent être plus lents et plus complets, car l'utilisateur n'attend plus.
Le comportement de réessai doit être prévisible, peu importe où l'utilisateur s'inscrit. Utilisez les mêmes comptes de réessai, budget de timeout et états de repli dans chaque région, et journalisez les mêmes catégories d'erreur. Sinon, un datacenter peut accepter un e-mail comme « inconnu » tandis qu'un autre le bloque, ce qui paraît aléatoire aux utilisateurs et est difficile à déboguer.
Si vous utilisez une API de validation comme Verimail, appliquez les mêmes règles de réessai côté client autour de l'appel API partout où vous déployez. Assurez-vous aussi que votre jitter est vraiment aléatoire par requête, pas synchronisé par serveur.
Les problèmes DNS et réseau temporaires ne doivent pas devenir des rejets permanents. La solution la plus simple est de séparer « on sait que c'est mauvais » de « on n'a pas pu finir la vérification ». Cette distinction rend votre flux d'inscription plus tolérant sans ouvrir la porte aux évidents indésirables.
Un modèle d'état pratique :
Ce que vous faites avec inconnu-temporaire dépend de votre tolérance au risque et de l'action de l'utilisateur. Options courantes : autoriser l'inscription et vérifier plus tard (produits à faible risque), autoriser l'inscription avec limitations (pas d'actions sensibles avant revalidation), créer le compte mais retenir l'envoi jusqu'à revalidation, ou exiger un second facteur (code à usage unique) si le risque de fraude est élevé.
Conservez le dernier résultat de validation plus un TTL court (par exemple 10 à 60 minutes pour un état inconnu-temporaire). Si l'utilisateur revient, ne relancez pas toutes les vérifications immédiatement. Reverifiez seulement quand le TTL expire ou avant la première action critique (comme l'envoi d'un e-mail de bienvenue).
Dans l'interface, ne traitez pas l'état inconnu comme invalide. Dites « Nous n'avons pas pu vérifier votre e-mail pour le moment. Vous pouvez continuer, nous reverrons cela bientôt » plutôt que « E-mail invalide ».
Créez un chemin de revalidation clair après l'inscription : une vérification en arrière-plan, un bouton « Renvoyer la vérification » et une vue admin qui montre l'état le plus récent. Avec une approche comme celle-ci, les vérifications par étapes de Verimail (syntaxe, vérification de domaine, recherche MX, détection jetable) vous aident à garder des protections solides tout en évitant que des pannes temporaires ne pénalisent les vrais utilisateurs.
Quand les vérifications DNS ou réseau échouent, le pire est de traiter l'utilisateur comme un fraudeur. Un meilleur objectif : être honnête sur l'incertitude, laisser les bons utilisateurs continuer et ajouter un second filet de sécurité.
Utilisez un langage simple et amical qui explique ce qui s'est passé sans accabler l'utilisateur. « Nous n'avons pas pu vérifier cet e-mail pour le moment. Vous pouvez continuer ; nous le confirmerons sous peu. » Cela fixe les attentes et réduit les abandons impulsifs.
Quand la validation est incertaine, autorisez l'avancement avec une légère friction plutôt qu'un blocage total. Quelques patterns efficaces :
La confirmation par e-mail devient votre seconde ligne de défense. Si vous ne pouvez pas confirmer la boîte en temps réel, envoyez un e-mail de vérification immédiatement et placez les fonctionnalités clés derrière cette confirmation. Cela maintient votre liste propre tout en évitant les rejets erronés.
Pensez aussi à différer l'application stricte jusqu'au moment où le risque augmente. Laissez le compte exister, mais exigez un e-mail confirmé avant d'inviter des coéquipiers, d'exporter des données ou de demander des paiements. Cela transforme l'incertitude en état temporaire, pas en impasse.
Les échecs répétés demandent une gestion prudente. Ne bloquez pas quelqu'un simplement parce que son ISP a eu une mauvaise heure. Escaladez progressivement : d'abord un message clair, puis ajouter de la friction, ensuite exiger une vérification, et enfin bloquer les schémas d'abus évidents.
Si vous utilisez une API comme Verimail, concevez votre stratégie de réessai pour que « inconnu dû au timeout » corresponde à ce chemin UX, pas à « invalide ».
Quand les vérifications DNS ou réseau échouent, le pire est de traiter « inconnu » comme « mauvais ». Un bon e-mail peut paraître invalide pendant quelques secondes, et bloquer cette personne nuit aux inscriptions. Mais accepter tout sans contrôle peut nuire à votre réputation d'expéditeur plus tard. L'objectif est un équilibre : laisser l'utilisateur entrer et empêcher que les adresses risquées n'affectent votre réputation d'envoi.
Une stratégie solide utilise un état temporaire qui signifie « nous n'avons pas pu vérifier pour l'instant ». Si l'adresse a passé la syntaxe de base mais que les recherches de domaine ou MX ont expiré, vous pouvez créer le compte tout en limitant ce qui se passe ensuite.
Une approche pratique pour préserver la délivrabilité sans punir les vrais utilisateurs :
Cette attitude « réessayer plus tard » n'est pas juste de la courtoisie. Elle protège votre réputation d'expéditeur parce que vous évitez d'envoyer des campagnes massives à des adresses qui pourraient être mortes ou jetables, tout en offrant une première expérience fluide aux utilisateurs légitimes.
Exemple : un utilisateur s'inscrit pendant une courte panne DNS chez son fournisseur d'e-mail. Votre validation ne peut pas confirmer les enregistrements MX. Vous créez le compte, le marquez en attente et le laissez utiliser le produit. Une heure plus tard, le réessai réussit et il passe automatiquement en confirmé. Avec Verimail, cela correspond à traiter les erreurs réseau et DNS comme « inconnu » et à reverifier rapidement au lieu de rejeter l'inscription.
La plupart des problèmes d'inscription lors de pannes DNS ou réseau sont auto‑infligés. Une bonne adresse est traitée comme mauvaise, ou le flux d'inscription reste bloqué assez longtemps pour que les gens partent.
Un piège courant est de réessayer trop agressivement. Dix réessais rapides peuvent sembler « plus sûrs », mais transforment un léger flottement DNS en une soumission de formulaire lente. Les utilisateurs pensent que le site est cassé et abandonnent la page, même si l'adresse est correcte.
Un autre piège est d'oublier le jitter. Si vous réessayez tous à 1, 2, 4 secondes pile, beaucoup de requêtes s'alignent et frappent votre résolveur DNS ou service de validation en même temps. Cette vague synchronisée peut aggraver une petite panne, surtout lors de pics de trafic.
Faites attention à la signification des erreurs. SERVFAIL indique normalement « réessayer plus tard », pas « ce domaine n'existe pas ». NXDOMAIN est plutôt « ce domaine n'est pas réel ». Les confondre conduit à des faux rejets et à des utilisateurs mécontents.
Ne mettez pas toutes les pannes dans le même panier. Une panne côté fournisseur (vos serveurs ne peuvent pas atteindre le DNS) n'est pas la même chose qu'un problème côté utilisateur (l'utilisateur est sur un réseau qui bloque le DNS ou utilise un portail captif). Les traiter tous comme « e-mail invalide » est inexact et nuisible.
Erreurs à attraper en revue de code :
Sans observabilité, tout est plus difficile. Si vous n'enregistrez pas les timeouts, les taux de SERVFAIL, les comptes de réessai et les résultats finaux, vous ne pouvez pas savoir s'il faut ajuster les timeouts ou corriger le DNS. Des outils comme Verimail exposent des résultats de validation clairs, mais vous devez quand même les capturer et tracer les tendances pour détecter rapidement les pannes.
Avant de mettre votre stratégie de réessai en production, décidez ce que signifie « assez rapide » pour votre inscription. Beaucoup d'équipes se concentrent sur les réessais et découvrent plus tard que l'écran tourne 10 secondes quand le DNS est lent.
Rédigez un budget de timeout clair. Choisissez un nombre pour toute l'étape UI (ce que l'utilisateur ressent), puis des nombres plus petits pour chaque appel interne (ce que votre système peut consacrer). Si vous utilisez une API comme Verimail, considérez-la comme une partie du budget, pas le budget entier.
Checklist :
Testez comme si ça allait échouer. Simulez un résolveur DNS lent, perdez des paquets et forcez un 503. Regardez l'expérience d'inscription bout en bout : temps à l'écran, copie d'erreur et ce qui se passe après la création du compte quand la validation redevient disponible.
Un exemple réel : Jamie s'inscrit à 9h12. Votre appli appelle votre validateur d'e-mails pour vérifier l'adresse avant de créer le compte.
À ce moment, votre résolveur DNS a une brève panne. Le validateur ne peut pas retrouver les MX, donc la première tentative subit un timeout DNS. Ce n'est pas un signe que l'e-mail est faux, mais que votre chemin réseau a eu un mauvais instant.
Au lieu de bloquer Jamie, votre système attribue un état temporaire comme « inconnu (transitoire) » et laisse l'inscription continuer. Vous créez bien le compte, mais vous n'avez pas traité l'adresse comme prouvée bonne tant que vous n'avez pas un résultat clair.
Votre logique de réessai attend un court instant et retente. Par exemple, vous pouvez utiliser un backoff exponentiel : 1s, puis 3s, puis arrêter et déléguer à un contrôle en arrière-plan. À la deuxième tentative (après la brève pause), le DNS est revenu et la recherche MX réussit. L'adresse est marquée comme valide en quelques secondes, et Jamie ne remarque rien.
En coulisses, le flux peut ressembler à ceci :
Si l'e-mail reste inconnu après vos réessais rapides, vous n'avez toujours pas besoin de rejeter Jamie. Traitez le compte comme « non vérifié » jusqu'à ce qu'il confirme l'adresse. Laissez-le utiliser le produit, mais restreignez les actions à haut risque jusqu'à confirmation.
Si vous utilisez Verimail, cela correspond bien à traiter les erreurs réseau et DNS comme réessayables, tout en gardant votre flux d'inscription fluide et votre envoi honnête.
Commencez par une stratégie de réessai simple, facile à expliquer et déboguer. Choisissez des valeurs conservatrices au départ, puis ajustez-les après avoir vu des données réelles de votre trafic. La plupart des équipes perdent du temps à débattre de paramètres « parfaits » sans savoir à quelle fréquence les problèmes DNS et réseau surviennent pour leurs utilisateurs.
Mettez en place un logging structuré pour chaque tentative de validation. Capturez le résultat (valide, invalide, jetable, inconnu), la raison (timeout DNS, erreur de connexion, pas de MX, etc.), la latence et si l'utilisateur a finalisé l'inscription. Cela transforme des suppositions en backlog clair.
Valeurs raisonnables pour débuter :
Décidez à l'avance quelles actions requièrent réellement un e-mail confirmé. L'inscription peut autoriser « inconnu », mais l'envoi marketing, les invitations d'équipe ou l'augmentation des limites de paiement peuvent nécessiter une confirmation.
Si vous ne voulez pas construire et maintenir vous‑même les vérifications DNS, la détection jetable et les correspondances de listes de blocage, une API de validation d'e-mails comme Verimail peut gérer ces vérifications en un seul appel et renvoyer des codes de raison clairs pour votre logique de repli.
Déployez les changements progressivement. Surveillez ensemble le taux de conversion d'inscription, la latence de validation, le taux de rebond et le taux de plainte. Si la conversion s'améliore mais que les rebonds montent, resserrez les règles sur les chemins à haut risque spécifiques, pas sur tous les nouveaux utilisateurs.
