Comprenez ce qu'un contrôle d'enregistrement MX confirme, comment gérer null MX, les domaines mal configurés et les pannes DNS temporaires, et pourquoi les réessais et la mise en cache réduisent les faux rejets.
Un contrôle d'enregistrement MX indique si un domaine publie une adresse de routage de courrier dans le DNS, ce qui signifie que le courrier peut probablement être acheminé vers ce domaine. Il ne confirme pas qu'une boîte aux lettres spécifique existe ni que le serveur acceptera votre message.
Non. Un domaine peut avoir des enregistrements MX valides et quand même refuser le courrier parce que l'adresse n'existe pas, que le serveur bloque les expéditeurs inconnus ou que des contrôles supplémentaires sont nécessaires. Traitez le MX comme un signal au niveau du domaine, pas comme une preuve de délivrabilité pour une boîte précise.
Un null MX est une politique explicite « ne pas envoyer d'e-mail » définie par le propriétaire du domaine. Il apparaît souvent comme un enregistrement MX pointant vers un seul point (.), ce qui signifie qu'il n'y a délibérément nulle part où livrer le courrier.
« Pas d'MX » peut être ambigu car certains systèmes de messagerie utilisent un repli A/AAAA quand il n'y a pas d'MX, donc le domaine peut parfois recevoir du courrier. Null MX est sans ambiguïté : le domaine dit explicitement qu'il n'accepte pas d'e-mails, il est donc généralement sûr de le rejeter à l'inscription.
Parce qu'un nom d'hôte MX peut exister dans le DNS mais rester inutilisable s'il ne résout pas en adresse IP. Vérifier que chaque cible MX possède des enregistrements A/AAAA permet de détecter un mode d'échec courant où le routage paraît configuré mais n'est pas réellement joignable.
Les timeouts signifient généralement que votre résolveur n'a pas reçu de réponse à temps à cause de perte de paquets, de serveurs autoritaires lents, de limites de débit ou de problèmes réseau temporaires. C'est généralement un problème à retenter, pas un signal définitif que le domaine ne peut pas recevoir de mail.
SERVFAIL indique que le résolveur n'a pas pu compléter la requête, souvent à cause d'un problème DNS temporaire (p. ex. panne en amont ou problème DNSSEC). Dans la plupart des cas, il faut retenter brièvement et, si le problème persiste, traiter le résultat comme « inconnu » plutôt que comme définitivement invalide.
Une valeur pratique par défaut est de faire 2 à 3 tentatives dans une petite fenêtre temporelle (environ 1–2 secondes au total pour l'étape DNS), en ne retentant que les erreurs récupérables comme les timeouts ou SERVFAIL. Si ça échoue encore, évitez un rejet catégorique et placez l'adresse dans un parcours « nécessite vérification ultérieure ».
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) pour ne pas vous fier indéfiniment à des données obsolètes. Pour les échecs temporaires, mettez en cache brièvement (souvent 1–5 minutes) pour éviter de submerger le DNS pendant un incident, et refaites la vérification quand l'utilisateur modifie l'e-mail ou que votre dernier contrôle est trop ancien.
Conservez un résultat avec un code de raison (par exemple : domain doesn’t exist, null MX, temporary DNS failure, MX target missing IP) et un horodatage indiquant quand vous avez vérifié. Si vous voulez éviter d'assembler plusieurs vérifications et cas limites vous-même, Verimail peut retourner un résultat structuré combinant contrôles de syntaxe, vérification de domaine/MX et détection d'e-mails jetables en un seul appel API.
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.
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 :
Considérez MX comme un signal fort au niveau du domaine, mais jamais comme la preuve qu'une boîte précise est joignable.
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 :
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.
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 :
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.
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 :
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 :
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.
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é.
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.
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 :
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.
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é.
Limitez les réessais pour que les utilisateurs ne restent pas bloqués sur un formulaire :
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.
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.
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 :
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.
Utilisez cette liste après que votre contrôle MX est revenu :
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 ».
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 » :
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. »
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 :
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.
