Découvrez pourquoi des enregistrements MX inhabituels sont courants en entreprise, comment les passerelles modifient le DNS et comment valider les emails sans rejeter de vrais domaines d'entreprise.
La plupart des règles de validation d'email sont construites autour de ce qui paraît normal : un domaine, quelques enregistrements MX, et un fournisseur de messagerie connu. Le problème, c'est que beaucoup de vraies entreprises ne paraissent pas normales dans le DNS. Leur configuration est guidée par la sécurité, la conformité, des fusions, et de vieilles infrastructures qui doivent continuer à fonctionner.
C'est là que les équipes se font piéger par des enregistrements MX inhabituels. Un domaine parfaitement valide peut pointer vers une passerelle tierce, publier des hôtes MX qui ne reflètent pas le nom de l'entreprise, ou acheminer le courrier via une chaîne de fournisseurs et de régions. Si vos règles attendent des schémas propres, vous finirez par rejeter de vrais clients.
Les rejets excessifs se voient vite : baisse des conversions d'inscription (surtout pour les comptes importants), tickets « je n'ai jamais reçu l'email de confirmation », commerciaux signalant qu'une entreprise connue a été bloquée, et des utilisateurs qui passent à des adresses personnelles, ce qui complique le rapprochement des comptes.
La solution n'est pas « tout accepter ». C'est considérer les vérifications de domaine comme un signal de risque, pas comme un verdict final.
La validation au niveau du domaine peut répondre à des questions comme « ce domaine est-il configuré pour recevoir du courrier ? » et « correspond-il à des schémas jetables connus ? ». Elle ne peut pas garantir qu'une boîte existe ou qu'elle acceptera votre message. De nombreuses entreprises bloquent la sonde des destinataires, le comportement catch-all est fréquent, et certaines passerelles répondent d'une manière qui paraît suspecte.
Une approche plus sûre consiste à laisser passer les domaines probablement valides même s'ils paraissent étranges, et à réserver des blocages stricts aux cas clairs (syntaxe invalide, domaine inexistant ou domaines jetables connus).
Les enregistrements MX sont des entrées DNS qui indiquent aux expéditeurs où livrer les emails pour un domaine. Si vous envoyez un message à [email protected], l'expéditeur recherche les enregistrements MX de company.com pour trouver les serveurs qui gèrent le courrier entrant.
Chaque enregistrement MX a un numéro de priorité (parfois appelé préférence). Les nombres plus bas sont essayés en premier. Il est courant de voir plusieurs hôtes MX pour la reprise sur panne, le partage de charge ou le routage régional.
Un détail important est souvent négligé par beaucoup de validateurs : le DNS vous dit où essayer, pas si votre message spécifique sera accepté.
Un domaine peut avoir des enregistrements MX propres et rejeter quand même une adresse particulière parce que la boîte n'existe pas, l'expéditeur est bloqué, ou des règles anti-spam strictes se déclenchent. L'inverse est vrai aussi : un domaine peut paraître étrange dans le DNS et accepter pourtant le courrier sans problème.
Parfois un domaine n'a aucun enregistrement MX. Les standards email permettent une solution de secours où l'expéditeur essaie l'enregistrement A ou AAAA du domaine (son adresse IP principale). Beaucoup de systèmes modernes ne comptent plus là-dessus, mais des configurations anciennes ou personnalisées le font encore.
Beaucoup de grandes entreprises n'envoient pas le courrier entrant directement à leur fournisseur de boîtes. Elles mettent une passerelle en tête, pour filtrer et inspecter les emails avant qu'ils n'atteignent les boîtes.
Cette couche de passerelle est pourquoi les enregistrements MX inhabituels sont si courants pour les domaines d'entreprise. L'hôte MX que vous voyez dans le DNS est souvent la propriété d'un fournisseur de sécurité, d'une équipe de services partagés ou d'un système legacy qui n'a rien à voir avec la marque publique.
Dans une configuration typique, le filtrage entrant et l'hébergement final des boîtes sont séparés. La passerelle gère l'analyse anti-spam et anti-malware, puis relaie le courrier propre vers le système de boîtes (cloud ou on-premise).
Parce que la passerelle est un système séparé, la cible MX peut ressembler à un cluster de filtrage générique (par exemple, quelque chose comme "mx1.mailfilter.someprovider.net") plutôt qu'à "mail.company.com". C'est normal, et ce n'est pas un signe que le domaine est faux.
Vous verrez souvent de la redondance régionale, des noms d'hôtes basés sur les tenants qui n'incluent pas le nom de l'entreprise, du routage mixte pour différentes unités métier, ou d'anciens enregistrements MX conservés pendant une migration. Les acquisitions et les groupes multi-marques ajoutent encore du bruit, surtout quand les systèmes de messagerie sont fusionnés progressivement.
La conclusion pratique : jugez si le domaine peut recevoir du courrier, pas si le nom d'hôte vous semble familier.
Certains domaines paraissent étranges lors de la vérification MX même quand le courrier fonctionne parfaitement. Si vos règles supposent « un domaine, un serveur mail, un fournisseur », vous obtiendrez des faux rejets.
Beaucoup d'entreprises externalisent l'hébergement des boîtes. Les hôtes MX peuvent pointer vers des domaines appartenant au fournisseur, pas au domaine de l'entreprise. Cela paraît suspect seulement si vous supposez que l'hôte MX doit partager le même domaine racine que l'adresse email.
Les services de sécurité et de filtrage ajoutent une couche supplémentaire. Une entreprise peut d'abord router tout le courrier entrant via une passerelle, puis le transmettre au fournisseur de boîtes. Dans le DNS, vous ne voyez que la passerelle.
Plusieurs enregistrements MX ne sont pas en eux-mêmes un signal d'alerte. Ils sont souvent utilisés pour la bascule en cas de panne et le routage régional. Des migrations temporaires peuvent aussi rendre le DNS confus, avec d'anciens et de nouveaux MX coexistant pendant des tests de basculement.
Une bonne règle de base est simple : « qui a l'air étrange » doit signifier « nécessite des vérifications plus intelligentes », pas « rejeter ».
Le DNS paraît simple vu de l'extérieur : vous demandez les MX, vous obtenez une réponse. En pratique, beaucoup d’entreprises légitimes peuvent sembler « cassées » pendant de courtes périodes.
Les grands domaines peuvent publier plusieurs noms d'hôtes MX, et ces noms d'hôtes peuvent tourner au fur et à mesure que les fournisseurs déplacent le trafic ou remplacent des nœuds. Si votre validation attend un jeu stable de noms, des changements normaux peuvent être qualifiés à tort de suspects.
Des valeurs TTL faibles rendent aussi les résultats inconsistants. Le TTL indique combien de temps un résolveur doit mettre en cache une réponse. Certaines entreprises gardent des TTL courts pour pouvoir rerouter rapidement le courrier. Deux requêtes à quelques secondes d'intervalle peuvent donner des réponses différentes si des résolveurs ont des caches différents.
Vous tomberez aussi sur des échecs en zone grise qui ne signifient pas « domaine invalide », comme SERVFAIL d'un résolveur en difficulté, des timeouts réseau, des réponses partielles, des NXDOMAIN intermittents pendant la propagation, ou des réponses tronquées nécessitant une reprise en TCP.
Le point clé est qu'une seule recherche n'est presque jamais suffisante pour prendre une décision confiante. Traitez les échecs DNS temporaires comme « inconnu », pas comme « invalide », et retentez avant de bloquer une inscription.
Quand vous rencontrez des enregistrements MX inhabituels, le plus grand risque est de rejeter une vraie entreprise parce que sa configuration ne ressemble pas à un petit domaine classique. Validez par couches et gardez « incertain » séparé de « mauvais ».
Commencez par ce que vous pouvez savoir sans réseau. Un contrôle de syntaxe strict et conforme aux RFC détecte les fautes de frappe évidentes et les formats cassés avant de lancer des requêtes DNS.
Ensuite, confirmez que le domaine existe. Si DNS retourne NXDOMAIN, c'est un échec sérieux. Si le domaine est internationalisé, assurez-vous de gérer correctement les IDN (souvent via punycode) pour interroger le vrai nom DNS.
Puis recherchez les MX, mais ne considérez pas « pas de MX » comme un rejet automatique. Certains domaines légitimes n'ont volontairement pas de MX. Si vous choisissez de supporter un repli, vérifiez A/AAAA et traitez le résultat comme de moindre confiance.
Une séquence pratique qui évite la plupart des faux rejets :
Les faux rejets surviennent généralement quand les règles supposent que chaque domaine est « normal ». La messagerie d'entreprise passe souvent par des passerelles et des infrastructures externalisées, donc des MX inhabituels ne sont pas automatiquement un signal d'alerte.
Une erreur fréquente est d'échouer automatiquement quand les noms d'hôtes MX n'incluent pas le même nom de domaine. Beaucoup d'entreprises utilisent des hôtes MX qui n'ont aucun lien visuel avec la marque. Une autre est de rejeter des domaines parce que le MX pointe vers un fournisseur tiers. Cela bloque beaucoup d'organisations légitimes.
Les timeouts sont aussi mal compris. Prendre un seul timeout comme un échec permanent est un moyen rapide de perdre des inscriptions valides. Retentez avec un backoff et, si possible, utilisez plus d'un résolveur.
Soyez prudent avec la logique « vérification SMTP ou rejet ». Bloquer systématiquement tous les domaines catch-all ou tous les résultats « inconnus » cause des dégâts car beaucoup d'entreprises désactivent volontairement les sondes SMTP ou utilisent des passerelles qui les rendent peu fiables.
Exemple : un acheteur essaie [email protected]. Le MX pointe vers une passerelle de sécurité, DNS timeoute une fois, et votre système le refuse. En réalité, le domaine est correct et le timeout était transitoire.
Les configurations email d'entreprise se trouvent souvent derrière des passerelles et des couches de routage. Cela peut faire paraître un domaine d'entreprise légitime suspect si vos règles attendent un MX simple de type grand public. L'objectif est d'attraper les mauvais sans bloquer de vrais acheteurs.
Évitez les allowlists globales. Elles sont utiles pour un seul client à haute valeur que vous avez vérifié par d'autres canaux, mais elles ne devraient pas être votre réglage par défaut. Elles créent aussi une brèche discrète que des attaquants peuvent viser.
Quand vous voyez des enregistrements MX inhabituels, considérez l'incertitude comme une décision produit, pas uniquement technique. Construisez une voie de semi-échec qui permet à l'utilisateur de continuer, tout en vérifiant plus tard. Par exemple, autorisez la création de compte mais retardez l'invitation jusqu'à confirmation de l'email, ou restreignez les actions à risque élevé jusqu'à obtenir un signal plus fiable.
Il aide aussi d'ajuster la sévérité selon le flux. L'inscription doit prioriser la fluidité avec confirmation. Les invitations d'équipe peuvent être plus strictes car elles sont faciles à abuser. Les formulaires de lead requièrent souvent une acceptation plus élevée avec un meilleur marquage. La réinitialisation de mot de passe doit privilégier les comptes confirmés et la délivrabilité.
Les logs comptent plus que la plupart des équipes ne l'imaginent. Conservez la raison de votre décision (erreur de syntaxe, NXDOMAIN, timeout, pas de MX, correspondance jetable) afin que le support puisse expliquer ce qui s'est passé et que vous puissiez améliorer les règles sans deviner.
Un prospect commercial d'une grande entreprise s'inscrit avec une vraie adresse pro : [email protected]. Votre validateur vérifie le DNS et voit des enregistrements MX pointant vers une passerelle tierce. C'est courant pour les entreprises, mais votre règle dit « le MX doit correspondre au domaine » et marque cela comme suspect. Puis une requête DNS timeoute. Votre système combine « MX tiers » et « timeout » et rejette l'inscription.
La correction consiste à gérer l'incertitude en toute sécurité :
Les enregistrements MX inhabituels sont souvent le signe d'une IT mature, pas d'une fraude.
Si vos règles considèrent tout ce qui est « étrange » comme mauvais, vous bloquerez de vrais clients. Utilisez ces vérifications pour rester strict quand c'est nécessaire et flexible quand il le faut.
Une seconde passe peut inclure la retentative DNS, la reconfirmation des listes d'adresses jetables, ou une validation plus approfondie dans un flux séparé.
Commencez par vos propres données. Récupérez un échantillon d'inscriptions récemment rejetées et regroupez-les par domaine. Cherchez des motifs : grands domaines d'entreprise, timeouts DNS répétés, et les mêmes noms d'hôte de passerelle qui reviennent.
Ajoutez de la visibilité avant d'ajouter des blocages plus stricts. Si votre système n'enregistre que « passe/échec », vous ne pouvez pas apprendre de vos erreurs. Capturez des codes de raison (syntax_fail, nxdomain, no_mx_found, dns_timeout, disposable_detected) et introduisez un troisième résultat pour les cas limites : inconnu ou à revoir. Cela laisse passer les utilisateurs d'entreprise réels avec un peu de friction au lieu d'un refus catégorique.
Si vous ne voulez pas maintenir ces règles vous-même, Verimail (verimail.co) est une option utilisée par des équipes pour la validation d'emails en entreprise. Il combine la vérification de syntaxe conforme aux RFC, la vérification de domaine et des MX, et la mise en correspondance en temps réel avec des fournisseurs d'emails jetables dans un seul appel d'API, ce qui peut vous aider à être plus précis sans pénaliser les configurations normales de passerelles d'entreprise.
