Contrôle des enregistrements MX : null MX, tentatives et mise en cache

Ce que vérifie un contrôle d'enregistrement MX (et ce qu'il ne vérifie pas)

Un contrôle d'enregistrement MX répond à une question pratique : ce domaine peut-il recevoir des e-mails quelque part ? Il n'essaie pas de déterminer si une personne est réelle, et il ne confirme pas qu'une boîte aux lettres spécifique existe. Il inspecte seulement la configuration de routage du courrier du domaine dans le DNS.

Quand le contrôle réussit, cela signifie généralement que le domaine publie des serveurs de messagerie (ou un repli reconnu) et qu'en théorie des messages peuvent être routés vers ce domaine. C'est utile lors d'une inscription ou d'une capture de leads parce que ça filtre les évidents faux domaines avant de les enregistrer ou d'envoyer du courrier.

Mais les résultats MX ne garantissent pas une boîte aux lettres. Un domaine peut avoir des enregistrements MX valides et quand même rejeter le courrier pour de nombreuses raisons : l'adresse peut ne pas exister, le serveur peut bloquer les expéditeurs inconnus, ou il peut exiger des vérifications supplémentaires avant d'accepter quoi que ce soit. MX ne peut pas non plus vous dire si une boîte est pleine, si un domaine est stationné (parked), ou si l'utilisateur peut accéder à la boîte.

Un flux de validation typique traite le MX comme une porte d'entrée précoce, pas comme un verdict final. On commence par la syntaxe, puis on confirme que le domaine a une route de messagerie plausible (MX et signaux DNS associés), et seulement ensuite on applique des règles plus discriminantes comme la détection de fournisseurs jetables, les règles de risque de pièges à spam, et les listes blanches ou noires.

Résultats courants d'un contrôle MX (et ce qu'ils signifient généralement)

Le résultat « échec » importe autant que le fait qu'il y ait échec. La plupart des systèmes finissent par observer un petit ensemble de résultats :

• Pas d'enregistrements MX : Le domaine peut ne pas accepter d'e-mail, ou il peut compter sur un repli A/AAAA (les validateurs traitent cela différemment).
• Null MX : Le domaine dit explicitement « n'envoyez pas d'e-mail ici. »
• NXDOMAIN : Le domaine n'existe pas.
• Timeout / pas de réponse : Le DNS peut être lent, bloqué, limité en taux, ou en panne temporaire.
• SERVFAIL : Le résolveur n'a pas pu compléter la requête, souvent à cause d'un problème DNS temporaire.

Considérez MX comme un signal fort au niveau du domaine, mais jamais comme la preuve qu'une boîte précise est joignable.

Notions DNS dont vous avez besoin avant d'examiner les résultats MX

Le DNS est l'annuaire téléphonique d'internet. Quand vous tapez un domaine, le DNS renvoie des enregistrements qui indiquent aux ordinateurs où se connecter et comment.

Lors d'un contrôle d'enregistrement MX (et de toute vérification basique de domaine e-mail), vous rencontrerez quelques types d'enregistrements répétitivement :

• MX : quels serveurs de messagerie acceptent le courrier pour un domaine (souvent avec des priorités).
• A / AAAA : l'adresse IP d'un nom d'hôte (A pour IPv4, AAAA pour IPv6). Les cibles MX ont généralement besoin de ces enregistrements.
• CNAME : un alias qui pointe un nom vers un autre. Il ne peut pas coexister sur le même nom que certains autres types d'enregistrements.
• TXT : texte utilisé pour les politiques et vérifications e-mail (comme SPF, DKIM et DMARC).
• TTL (time to live) : durée pendant laquelle une réponse DNS peut être mise en cache avant de reposer la question.

Les réponses DNS peuvent changer dans le temps, même pour un même domaine. La mise en cache est la raison la plus fréquente : votre appareil, votre routeur, votre FAI et les résolveurs publics peuvent tous conserver les réponses jusqu'à l'expiration du TTL. Si le propriétaire du domaine vient de corriger sa configuration de messagerie, certains utilisateurs verront rapidement les nouveaux enregistrements MX tandis que d'autres continueront de voir les anciens pendant des minutes ou des heures.

Un résolveur est le service DNS qui effectue les recherches pour vous. Le choix du résolveur compte parce que différents résolveurs ont des états de cache, des chemins réseau et des comportements de timeout différents. Un résolveur peut renvoyer une réponse claire instantanément alors qu'un autre renvoie une erreur temporaire parce qu'il ne peut pas joindre un serveur autoritaire à cet instant.

C'est pourquoi un domaine peut sembler « bon » depuis votre Wi‑Fi de bureau mais « mauvais » depuis un réseau mobile. Par exemple, l'hôte MX peut se résoudre correctement à un endroit, mais ailleurs un résolveur mettra fin au délai en essayant de récupérer l'enregistrement A/AAAA, si bien que le domaine paraît cassé alors qu'il ne s'agit que d'un problème DNS momentané.

Ces notions aident à considérer les résultats DNS comme des signaux plutôt que comme une vérité absolue. Elles expliquent aussi les cas limites comme le null MX, les mauvaises configurations et les pannes temporaires.

Étape par étape : comment exécuter un contrôle MX en toute sécurité

Commencez par traiter le domaine comme une saisie utilisateur, pas comme « déjà propre ». Supprimez les espaces, enlevez les points finaux, et mettez en minuscules. Si l'utilisateur saisit des caractères internationaux (comme ü ou 例), convertissez le domaine en forme IDN (souvent appelée punycode) avant d'interroger le DNS, afin de vérifier ce que le DNS stocke réellement.

Ensuite, lancez la recherche MX pour ce domaine normalisé. Si vous obtenez plusieurs enregistrements, triez‑les par priorité (les nombres plus bas sont essayés en premier). Cet ordre importe plus tard si vous faites des vérifications plus poussées, car un domaine « bon » peut avoir un MX cassé et un autre fonctionnel.

Après avoir obtenu des résultats MX, validez les cibles, pas seulement le fait que « quelque chose existe ». Chaque enregistrement MX pointe vers un nom d'hôte, et ce nom d'hôte doit résoudre en au moins un enregistrement A ou AAAA. S'il ne le fait pas, les serveurs de messagerie ne peuvent pas l'atteindre même si l'enregistrement MX est présent.

Quand il n'y a pas d'enregistrements MX, vérifiez si le domaine de base a des enregistrements A/AAAA. Beaucoup de systèmes considèrent cela comme un repli car certains serveurs de messagerie livreront au domaine via son A/AAAA si MX est absent. Les limites sont importantes : cela ne prouve toujours pas que le domaine accepte le courrier, et ça ne vous protège pas des domaines qui n'acceptent volontairement pas d'e-mails.

Un flux sûr ressemble à ceci :

• Normaliser le domaine (trim, minuscules, gestion IDN).
• Interroger MX et trier par priorité.
• Si MX est vide, interroger A/AAAA sur le domaine de base (signal de repli seulement).
• Pour chaque cible MX, confirmer qu'elle résout en A/AAAA.
• Enregistrer à la fois un résultat et un code de raison exploitable.

Ne stockez pas seulement « réussi/échoué ». Conservez un statut, un code de raison (par exemple : MX_FOUND, NO_MX_BUT_A, MX_TARGET_NO_IP, DNS_TIMEOUT) et un checked_at pour savoir quand recontrôler.

Null MX : le signal explicite « n'envoyez pas d'e-mail ici »

Un enregistrement null MX signifie que le propriétaire du domaine déclare clairement : « Ce domaine n'accepte pas d'e-mails. » Ce n'est pas une configuration cassée ni une panne temporaire. C'est une politique intentionnelle.

Dans le DNS, il apparaît généralement comme un enregistrement MX dont la cible spéciale est un seul point (.). Ce point signifie « nulle part ». Ainsi, une recherche MX peut réussir et pourtant indiquer que vous ne devez pas livrer de courrier pour ce domaine.

Le null MX diffère de deux résultats courants qui peuvent paraître similaires à première vue :

• Pas d'MX : le domaine n'a pas d'enregistrements MX. Certains systèmes de messagerie utilisent le repli A/AAAA, donc c'est ambigu.
• Échec temporaire : le domaine peut accepter du courrier, mais votre requête DNS a échoué dans l'instant (timeouts, SERVFAIL, problème de résolveur).

Avec null MX, il n'y a pas d'ambiguïté. Si votre contrôle retourne null MX, le comportement le plus sûr est de traiter le domaine comme non joignable par e-mail et de le bloquer à l'inscription (ou d'exiger une autre adresse). Le laisser passer entraîne des rebonds prévisibles et nuit à la délivrabilité.

La manière de l'expliquer à l'utilisateur importe. Évitez les termes DNS et restez actionnable :

• « Ce domaine ne peut pas recevoir de messages. Veuillez utiliser une autre adresse e-mail. »
• « Nous ne pouvons pas envoyer d'e-mail à cette adresse. Essayez une autre adresse (par exemple une boîte professionnelle ou personnelle). »

Séparez aussi clairement null MX de « impossible de vérifier pour l'instant ». Null MX doit être un rejet assuré. Les erreurs temporaires doivent déclencher une stratégie de réessai, pas un blocage stricte.

Domaines mal configurés : schémas courants et traitement recommandé

Beaucoup de domaines de messagerie ne sont pas simplement « oui » ou « non ». Ils existent, mais leur DNS est suffisamment brouillon pour que le contrôle MX donne des résultats confus. L'objectif est d'éviter de rejeter de vraies personnes tout en bloquant les domaines qui ne peuvent pas recevoir de courrier.

Les mauvaises configurations courantes incluent des enregistrements MX pointant vers un hôte qui n'existe pas, souvent parce que le propriétaire a changé de fournisseur et laissé des enregistrements obsolètes. Un autre problème fréquent est une cible MX invalide : MX doit pointer vers un nom d'hôte, pas une adresse IP. Vous pouvez aussi rencontrer des chaînes CNAME qui se terminent nulle part, bouclent, ou se comportent différemment selon les résolveurs.

Certains domaines n'ont aucun chemin de livraison utilisable : pas d'MX et pas de repli A/AAAA fonctionnel. D'autres renvoient des réponses incohérentes (des MX apparaissent dans une requête et disparaissent dans la suivante), généralement à cause de problèmes de propagation ou d'un hébergement DNS mal configuré.

Échec dur vs échec souple

Classifiez selon la confiance.

Traitez le résultat comme un échec dur quand le domaine ne peut clairement pas accepter de mail, par exemple une cible MX invalide (comme une IP) ou des hôtes MX constamment NXDOMAIN après plusieurs tentatives.

Traitez‑le comme un échec souple lorsque le résultat pourrait être temporaire (timeouts, réponses incohérentes, SERVFAIL). Dans ce cas, demandez à l'utilisateur de retenter, ou autorisez l'inscription mais marquez l'adresse pour confirmation ultérieure.

Utilisez une catégorie inconnue pour les domaines bizarres mais non définitivement cassés, et combinez le résultat MX avec d'autres signaux au lieu de prendre une décision unique.

Pannes DNS temporaires : pourquoi elles arrivent et quoi faire

Un échec de recherche MX n'indique pas toujours qu'un domaine ne peut pas recevoir de mail. Parfois votre résolveur (ou le fournisseur DNS du domaine) a un mauvais moment. Si vous traitez chaque échec comme « invalide », vous rejetterez de vrais utilisateurs pendant de brefs incidents.

Voici les erreurs DNS courantes et leur cartographie pratique :

• Timeout : pas de réponse dans le délai imparti. Souvent perte de paquets, serveurs autoritaires lents ou résolveur occupé.
• SERVFAIL : le résolveur n'a pas pu compléter la requête (problèmes DNSSEC, pannes en amont, serveurs autoritaires cassés).
• REFUSED : un serveur a refusé de répondre (limites de débit, mauvaise configuration, réglages restrictifs).
• Réponse tronquée (TC=1) : la réponse était trop grosse pour UDP et nécessite une tentative en TCP.
• NXDOMAIN (pour le domaine lui‑même) : le domaine n'existe pas, et c'est généralement sûr de le traiter comme permanent.

Une approche pratique consiste à classer les erreurs en retrable vs finales. Timeouts, SERVFAIL, REFUSED et la troncation sont typiquement « retenter », idéalement avec un petit backoff et un plafond (2–3 tentatives). Ce n'est qu'après des échecs répétés que vous devriez basculer vers une décision plus douce comme « inconnu » plutôt que « invalide ».

Pour le débogage, journalisez suffisamment pour repérer des motifs sans stocker de données personnelles inutiles. Le domaine interrogé (pas l'adresse e-mail complète), le code d'erreur et le résolveur utilisé, le nombre de tentatives et les horodatages, si une tentative TCP a eu lieu, et si la réponse provenait du cache suffisent généralement.

Réessais et mise en cache : réduire les faux rejets sans ralentir l'inscription

Le DNS est généralement rapide, mais pas parfaitement fiable. Si vous considérez un seul timeout comme un « non » définitif, vous rejetterez de vrais utilisateurs lors de courts incidents. Un bon contrôle MX équilibre rapidité et filet de sécurité.

Une politique de réessais adaptée à une page d'inscription

Limitez les réessais pour que les utilisateurs ne restent pas bloqués sur un formulaire :

• Faites 2–3 tentatives au maximum.
• Espacez les essais d'environ 200–500 ms, avec un peu d'aléa.
• Gardez un budget de délai total d'environ 1–2 secondes pour l'étape DNS.
• Retentez pour les timeouts et les erreurs « serveur », mais ne réessayez pas indéfiniment pour un résultat clair « domaine inexistant ».
• Si la première tentative est déjà lente, sautez les réessais supplémentaires et adoptez une décision plus souple (par exemple, autoriser l'inscription mais marquer l'e-mail pour vérification ultérieure).

Backoff et jitter signifient simplement attendre un peu plus à chaque tentative et éviter des réessais parfaitement synchronisés entre les utilisateurs. Cela prévient des pics où de nombreuses inscriptions bombarderaient le DNS en même temps.

Règles de mise en cache qui évitent de répéter les mêmes problèmes

La mise en cache évite de poser la même question en boucle. Mettez en cache les résultats positifs en utilisant le TTL DNS quand il est disponible, mais plafonnez la durée (par exemple, pas plus de 24 heures) afin de ne pas vous fier indéfiniment à des données anciennes.

Pour les résultats négatifs ou d'erreur, cachez brièvement (souvent 1–5 minutes). Cela évite de surcharger le DNS pendant de courts incidents et protège vos systèmes.

Forcez une nouvelle vérification quand cela compte : l'utilisateur modifie son e-mail, vous observez une nouvelle activité après une longue période d'inactivité, ou votre dernier contrôle dépasse votre plafond de cache.

Erreurs courantes que font les équipes avec les contrôles MX

Un contrôle d'enregistrement MX est utile, mais il est facile de le traiter comme un verdict définitif.

Une erreur est de supposer que « MX existe » signifie qu'une adresse e-mail est délivrable. MX indique seulement qu'un domaine affirme accepter du courrier quelque part. Il ne dit rien sur l'existence d'une boîte, sur le fait que le serveur rejette les utilisateurs inconnus, ou sur la sécurité d'envoi vers ce domaine.

Une autre erreur est de bloquer dès le premier timeout, SERVFAIL ou réponse DNS instable. Le DNS n'est pas parfaitement fiable. Si vous bloquez une inscription parce qu'une seule recherche a échoué, vous rejetterez de vrais utilisateurs durant de courtes pannes.

Le null MX est aussi largement mal compris. Un record null MX est un signal explicite que le domaine n'accepte pas d'e-mail. Si vous l'ignorez et que vous acceptez le domaine, vous vous exposez à des rebonds garantis.

Beaucoup d'implémentations s'arrêtent trop tôt après avoir lu les noms d'hôtes MX. Elles ne résolvent jamais les cibles MX en A/AAAA, ce qui manque un mode d'échec courant : le domaine publie des MX pointant vers des noms qui ne résolvent pas, ou qui ne résolvent que vers une famille d'adresses injoignable.

La mise en cache peut aussi se retourner contre vous si elle est faite sans plan d'expiration. Conserver des résultats « pour toujours » signifie que vous continuerez à rejeter des domaines temporairement cassés, ou à accepter des domaines qui ont supprimé le service de messagerie.

Les schémas qui causent le plus de problèmes en production sont :

• Accepter n'importe quel enregistrement MX comme « délivrable » sans vérifications supplémentaires
• Traiter le premier timeout ou SERVFAIL comme une erreur permanente
• Ignorer null MX et laisser passer le domaine
• Ne pas résoudre les cibles MX en A/AAAA avant de marquer le domaine « bon »
• Conserver des verdicts obsolètes indéfiniment au lieu de recontrôler

Si vous validez à l'inscription, pensez en termes de confiance, pas de certitude. Retentez les erreurs DNS transitoires, mettez en cache pour une courte durée, et combinez les contrôles MX avec d'autres signaux.

Checklist rapide avant de marquer un domaine bon ou mauvais

Utilisez cette liste après que votre contrôle MX est revenu :

• Normalisez d'abord le domaine (mettez en minuscules, retirez les points finaux et convertissez les domaines internationaux en forme ASCII sûre). Vérifiez que la partie domaine est structurellement valide (pas d'espaces, pas de doubles points, pas de caractères interdits).
• Considérez le routage du courrier comme « confirmé » seulement s'il y a des enregistrements MX utilisables et que les noms d'hôtes MX résolvent en IP, ou si le domaine a un repli A/AAAA valable qui peut recevoir du courrier.
• Si vous obtenez un enregistrement null MX, stoppez là. C'est le domaine qui dit explicitement « ne pas envoyer d'e-mail ici. »
• Surveillez les erreurs DNS temporaires. Si vous voyez des timeouts ou SERVFAIL, ne marquez pas le domaine comme définitivement mauvais sans l'avoir retenté dans une petite fenêtre temporelle.
• Enregistrez ce qui s'est passé : le résultat, le type de réponse, et un horodatage pour pouvoir recontrôler au lieu de deviner.

Un exemple concret : un utilisateur s'inscrit avec [email protected] pendant une brève panne DNS chez votre résolveur. La première recherche timeoute et votre application rejette l'inscription. Si vous retentez une ou deux fois sur une seconde ou deux, vous obtenez souvent une réponse claire sans trop ralentir le formulaire. Si ça échoue encore, conservez l'inscription mais marquez l'e-mail comme « nécessite vérification ultérieure » et recontrôlez en arrière‑plan.

Conservez les résultats pour une courte période. La mise en cache des succès et des échecs récents réduit les recherches répétées et vous aide à distinguer « ce domaine n'accepte pas de mail » de « le DNS a été instable pendant une minute ».

Scénario d'exemple : validation lors d'une fenêtre DNS instable

Un utilisateur tente de s'inscrire avec une vraie adresse professionnelle, par exemple [email protected]. Votre application exécute un contrôle MX pendant l'inscription pour vérifier si le domaine peut recevoir des messages. Au même moment, le fournisseur DNS du domaine a un bref incident.

À la première recherche, votre système n'obtient pas de réponse claire. La requête DNS timeoute ou renvoie SERVFAIL. Cela ne signifie pas que le domaine est faux. Cela signifie que le résolveur n'a pas pu obtenir de réponse à ce moment.

Si vous traitez cela comme « domaine invalide » et bloquez l'inscription, vous créez un faux rejet. L'utilisateur réessaie une minute plus tard et ça fonctionne, ce qui rend la validation aléatoire.

Un flux plus sûr sépare « définitivement mauvais » de « temporairement inconnu » :

• Si le domaine n'existe pas (NXDOMAIN), rejetez.
• Si le domaine publie null MX, rejetez.
• Si vous avez un timeout ou SERVFAIL, faites un court réessai (2–3 tentatives avec un petit délai).
• Si ça échoue toujours, autorisez l'inscription mais marquez l'e-mail comme « non vérifié » et recontrôlez en arrière‑plan.
• Si le domaine retourne des MX valides, procédez normalement.

Les réessais aident parce que beaucoup d'incidents DNS sont brefs. La mise en cache à court terme aide aussi parce que plusieurs inscriptions depuis la même entreprise peuvent survenir à proximité temporelle. Si votre première tentative échoue à cause d'une panne transitoire, mettre en cache cet échec trop longtemps peut verrouiller l'accès de vrais utilisateurs.

Quand le support reçoit la question « pourquoi mon e-mail a été rejeté ? », évitez de blâmer l'utilisateur. Une réponse claire : « Nous n'avons pas pu confirmer que votre domaine e-mail pouvait recevoir des messages à ce moment en raison d'une erreur DNS temporaire. Veuillez réessayer ou utiliser une autre adresse. »

Étapes suivantes : transformer les contrôles MX en validation d'e-mail fiable

Un contrôle d'enregistrement MX est un signal fort, mais il ne doit pas être votre seul filtre. L'étape suivante consiste à transformer des résultats DNS bruts en une politique claire que votre produit applique de manière cohérente.

Décidez de ce que vous faites pour chaque issue. Null MX est généralement un blocage dur car le domaine indique explicitement qu'il n'accepte pas d'e-mails. Une panne DNS temporaire devrait rarement être un rejet permanent. Les mauvaises configurations se situent au milieu : vous pouvez autoriser l'inscription mais exiger que l'utilisateur confirme son adresse avant d'accéder à des fonctionnalités importantes.

Un cadre de politique simple que beaucoup d'équipes utilisent ressemble à ceci :

• Bloquer : null MX, domaine clairement invalide, ou fournisseur jetable connu
• Avertir : timeout DNS ou SERVFAIL, suspect mais pas prouvé mauvais
• Autoriser mais vérifier plus tard : domaine existant mais MX mal configuré ou incohérent
• Autoriser : domaine et MX normaux, sans drapeaux de risque

Puis associez les résultats MX à d'autres contrôles pour ne pas trop faire confiance au DNS. Une bonne couverture inclut généralement des vérifications de syntaxe conformes aux RFC, une vérification basique du domaine, la recherche MX et la détection d'adresses jetables.

La cohérence importe autant que la précision. Utilisez des codes de raison stables et mappez‑les au comportement produit. Si le support voit « dns_temporary_failure » mais que les logs analytiques disent « invalid_domain », vous ne pourrez pas mesurer correctement ce qui se passe.

Si vous préférez ne pas implémenter et maintenir tous les cas limites vous‑même, un validateur multi‑étapes peut renvoyer une réponse structurée au lieu d'assembler séparément DNS et listes noires. Par exemple, Verimail (verimail.co) combine des contrôles de syntaxe conformes aux RFC, la vérification de domaine et MX, et la correspondance en temps réel avec des fournisseurs d'e-mails jetables connus en un seul appel API.

Enfin, ajoutez une boucle de revue. Suivez la fréquence à laquelle les avertissements se confirment ensuite, combien d'utilisateurs bloqués contactent le support, et si des pics correspondent à des incidents de résolveur. Ajustez ensuite les réessais et la mise en cache pour que de courtes pannes ne se transforment pas en inscriptions perdues.