Vous avez vérifié le contenu de la campagne, nettoyé la liste et confirmé les paramètres de l’expéditeur. Puis les messages commencent à rebondir, et l’erreur renvoie au domaine du destinataire. Le premier réflexe consiste souvent à examiner SPF, DKIM ou le message lui-même, mais l’échec peut être plus simple : le routage des emails du domaine est absent, obsolète ou pointe vers le mauvais service.
Un outil de vérification des enregistrements MX constitue le premier contrôle de l’infrastructure. Il indique si un domaine publie des enregistrements d’échange de courrier, si ces enregistrements identifient des serveurs de messagerie légitimes et si leur ordre de priorité est cohérent. C’est une base nécessaire, mais cela ne revient pas à prouver qu’une boîte aux lettres existe ou qu’un serveur acceptera un message.
Pourquoi les enregistrements MX sont importants pour la délivrabilité des emails
Une campagne peut échouer avant même que les filtres anti-spam n'évaluent l'objet. Si le domaine du destinataire ne dispose d'aucun chemin utilisable pour l'échange de courrier, le système d'envoi ne peut pas déterminer où remettre le message. Si le domaine publie encore l'enregistrement d'un ancien fournisseur après une migration, certains expéditeurs peuvent acheminer les emails vers une infrastructure que votre équipe ne contrôle plus.
Un outil de vérification des enregistrements MX vérifie qu'un domaine possède un ou plusieurs enregistrements MX valides, que ces enregistrements pointent vers des serveurs de messagerie légitimes et que leurs valeurs de priorité sont correctement configurées. Les nombres de priorité les plus faibles indiquent une priorité de livraison plus élevée. Les recommandations opérationnelles courantes situent les valeurs TTL dans une plage de 300 à 3600 secondes, ce qui aide les changements DNS à se propager sans conserver en cache les anciennes informations de routage plus longtemps que nécessaire, comme indiqué dans cette checklist de vérification MX.
L'échec commence souvent par le routage
Les recommandations DNS de Microsoft 365 identifient l'enregistrement MX comme la route des emails entrants vers Exchange Online et recommandent de supprimer les anciens enregistrements MX une fois la livraison opérationnelle. Zoho donne un conseil similaire, en avertissant que les anciens enregistrements à priorité plus faible peuvent détourner la livraison du service prévu. Un domaine peut donc sembler disposer d'une infrastructure de messagerie tout en acheminant certains messages vers la mauvaise destination.
C'est pourquoi la validation MX doit intervenir avant le lancement d'une campagne, l'élargissement d'une liste ou la migration d'un fournisseur. Elle répond à la question fondamentale : ce domaine publie-t-il un chemin plausible pour les emails entrants ? Pour une vue plus large de la réputation de l'expéditeur et du placement en boîte de réception, les conseils de Networking2000 sur le placement en boîte de réception constituent une ressource complémentaire utile.
Une vérification au niveau du domaine ne remplace pas la vérification de boîte mail. Elle empêche toutefois les équipes de considérer un échec de routage comme un problème de contenu et fournit aux investigations sur la délivrabilité un premier point de contrôle fiable. Les équipes qui souhaitent relier les vérifications d'infrastructure à des diagnostics de campagne plus larges peuvent également utiliser ce guide de test de délivrabilité des emails.
Fonctionnement des recherches MX et signification des résultats
Une recherche MX demande au DNS quels serveurs de messagerie acceptent les emails entrants pour un domaine. Le résultat comprend généralement un nom d’hôte, une valeur de priorité et souvent un TTL. Le nom d’hôte identifie le système de messagerie, tandis que la priorité détermine la destination qu’un serveur expéditeur doit essayer en premier.
Les valeurs les plus faibles ont la priorité la plus élevée. Si un domaine publie des enregistrements avec des valeurs différentes, les expéditeurs tentent généralement la destination portant le numéro le plus bas avant de passer à la suivante disponible. Un résultat tel que 10 mail.example.com communique donc à la fois la destination et sa position dans l’ordre de routage.
Lire la réponse dans le bon ordre
Commencez par l’ensemble des enregistrements, et non par l’indicateur visuel de réussite ou d’échec.
- Confirmez la publication. Le domaine doit renvoyer un ou plusieurs enregistrements MX lorsque les emails entrants sont attendus.
- Examinez les noms d’hôte. Chaque destination doit identifier un serveur de messagerie légitime, plutôt qu’un fournisseur obsolète ou un nom manifestement malformé.
- Comparez les priorités. Les valeurs les plus faibles représentent les destinations préférées. Un ordre inattendu peut envoyer le trafic vers le mauvais service.
- Vérifiez le TTL. Un TTL indique la durée pendant laquelle les résolveurs peuvent mettre la réponse en cache. Les recommandations publiées par Microsoft 365 précisent un TTL MX de 3600 secondes, comme l’expliquent les recommandations DNS de DigiCert pour les emails.
- Vérifiez la réponse en direct. Un enregistrement récemment modifié peut ne pas apparaître de manière cohérente via tous les résolveurs mis en cache.
Les outils les plus utiles interrogent directement le DNS faisant autorité du domaine. Cette approche expose l’ensemble MX actif et l’ordre des priorités que les serveurs expéditeurs utiliseront. Lorsque la réponse faisant autorité change, le routage mis à jour peut apparaître immédiatement, ce qui rend cette méthode utile pour repérer une erreur de migration récente ou un conflit nouvellement introduit, comme l’illustre la ressource de test de MXToolbox.
Les utilitaires en ligne de commande restent des points de référence utiles. Sous Linux ou macOS, les administrateurs utilisent généralement dig MX domain.com ; sous Windows, nslookup -type=MX domain.com fournit la même vue DNS de base. Une interface web est plus rapide pour les vérifications courantes, tandis que les requêtes brutes aident les ingénieurs à comparer les réponses pendant une migration. Pour une explication connexe de la manière dont les vérifications DNS sont effectuées, utilisez un outil qui rend la méthode de recherche claire plutôt que de masquer chaque détail derrière un simple résultat vert.
Les enregistrements MX dans l'ensemble plus large de l'authentification des emails
Les enregistrements MX répondent à une question de routage, et non d'authentification. Ils indiquent aux systèmes de réception où les emails entrants d'un domaine doivent être acheminés, tandis que SPF identifie l'infrastructure d'envoi autorisée, DKIM ajoute une signature cryptographique et DMARC définit la manière dont les systèmes de réception doivent traiter les échecs d'authentification et d'alignement.
Cette distinction est importante lors du dépannage. Un domaine peut publier un enregistrement MX pertinent tout en rencontrant des problèmes causés par une politique SPF incomplète, une configuration DKIM manquante ou une politique DMARC qui ne correspond pas au domaine From visible. Un résultat MX constitue donc une base, et non une évaluation complète de la réputation.
Les erreurs de migration restent rarement isolées
Les changements de fournisseur en sont l'exemple le plus évident. Une équipe met à jour l'enregistrement MX préféré, mais laisse un ancien fournisseur dans la zone. Les priorités ainsi obtenues peuvent acheminer une partie du trafic entrant vers le nouveau service et une autre partie vers une infrastructure qui ne devrait plus recevoir d'emails. Zoho conseille de supprimer les enregistrements de l'ancien fournisseur pour éviter ce type de conflit, tandis que les recommandations de Microsoft 365 préconisent de définir une priorité MX inférieure à celle des autres enregistrements et d'utiliser un TTL de 3600 secondes, comme indiqué dans la référence précédente sur le DNS des emails.
La même vérification doit inclure le reste de la pile d'authentification DNS. MailGenius propose une ressource pratique pour les équipes qui doivent vérifier les enregistrements SPF et DKIM en complément du routage. Les équipes doivent également vérifier les enregistrements DMARC, en particulier lorsqu'une migration modifie le service d'envoi, le comportement du return-path ou l'alignement du domaine.
Règle opérationnelle : Considérez MX, SPF, DKIM et DMARC comme des contrôles interdépendants, mais ne demandez pas à un type d'enregistrement de prouver ce qui relève d'un autre type d'enregistrement.
Cette vision systémique évite une erreur de diagnostic fréquente. Une recherche MX réussie signifie que le domaine annonce une infrastructure de messagerie. Elle n'établit pas que les messages sortants sont correctement authentifiés, que l'hôte de réception est accessible ou qu'une boîte aux lettres donnée accepte les emails.
Les limites de la validation MX basée sur le DNS
Un résultat MX valide peut créer une fausse confiance. Il prouve qu'un domaine publie une infrastructure d'échange de messages, mais ne prouve pas qu'une boîte mail spécifique existe ni que le serveur de destination acceptera un message.
La publication n'est pas l'accessibilité
Une recherche basique peut afficher un nom d'hôte et une priorité tout en ignorant les problèmes opérationnels qui déterminent si la livraison peut aboutir. L'hôte peut être inaccessible, une connexion peut échouer ou le serveur peut refuser les tentatives de relais. Les diagnostics pratiques ajoutent donc des tests de connexion, des vérifications DNS inversées et des mesures du temps de réponse pour identifier les ports bloqués, les hôtes indisponibles et les problèmes de relais, comme l'explique ce guide de configuration SMTP.
Les services de recherche gratuits peuvent également s'appuyer sur des résolveurs publics ou sur des réponses mises en cache et nettoyées. Ces réponses peuvent omettre une destination, ne pas valider le comportement de la priorité ou manquer un serveur de messagerie qui se résout mais ne répond pas. L'interface peut signaler une publication DNS saine alors que le chemin de livraison réel reste inutilisable.
Cette différence est essentielle pour les opérations de campagne :
- Publication DNS montre ce que le domaine annonce.
- Résolution du nom d'hôte montre si la destination annoncée peut être trouvée.
- Réactivité du serveur montre si la destination peut être contactée.
- Vérification SMTP teste si le système destinataire acceptera la boîte mail.
Un résultat DNS vert ne concerne que la première couche, et parfois une partie de la deuxième. Il ne doit pas être utilisé comme substitut à la vérification au niveau du destinataire.
Une courte explication visuelle peut aider les équipes à distinguer l'enregistrement du service qui se trouve derrière :
La conséquence pratique est simple. Utilisez un outil de vérification des enregistrements MX pour identifier les domaines sans chemin de livraison apparent ou présentant un routage suspect. Utilisez des diagnostics au niveau SMTP lorsque la décision concerne la sécurité d'envoyer un email à une adresse.
Des contrôles MX à la vérification SMTP
La vérification SMTP ajoute un test d'acceptation en direct aux informations DNS. Au lieu de s'arrêter au serveur de messagerie du domaine, le vérificateur se connecte à ce serveur et évalue s'il semble disposé à accepter la boîte aux lettres spécifiée.
Cette couche supplémentaire peut identifier les adresses invalides, domaines catch-all, domaines jetables et comptes de rôle. Chaque catégorie affecte différemment la qualité de la liste. Une adresse invalide représente un risque direct de rebond, une adresse jetable peut avoir une valeur limitée dans le temps, et un compte de rôle peut représenter une fonction partagée plutôt qu'un destinataire individuel.
Le comportement catch-all modifie l'interprétation
Les domaines catch-all nécessitent une attention particulière. Ils acceptent les emails pour toute partie locale, de sorte que le serveur peut sembler accepter une adresse qui ne correspond pas à une boîte aux lettres réelle. Dans cette situation, un enregistrement MX valide et une réponse SMTP positive n'offrent toujours pas le même niveau de confiance qu'une confirmation provenant d'un domaine qui n'est pas catch-all.
Un résultat de vérification utile distingue ces conditions au lieu de les réduire à « valide » ou « invalide ». Les API de vérification d'email modernes renvoient généralement du JSON structuré avec des statuts tels que valid, invalid, catch_all, unknown et do_not_mail, ainsi que des champs de confirmation SMTP et des indications sur la possibilité d'envoi, comme l'indique la documentation de l'API Mailvalid.
Cette structure fournit aux spécialistes du marketing une couche de décision pratique :
- Valide : conserver pour les envois normaux lorsque les autres contrôles de campagne sont correctement configurés.
- Invalide : supprimer plutôt que réessayer continuellement.
- Catch-all : segmenter avec une prudence accrue, car l'existence de la boîte aux lettres n'est pas confirmée.
- Inconnu : mettre en attente ou réessayer plus tard lorsque la réponse ne permet pas de prendre une décision fiable.
- Ne pas envoyer : exclure des envois de campagne.
BillionVerify est un service professionnel de vérification d'email conçu pour répondre au coût des données d'email de mauvaise qualité. Sa pertinence ici réside dans la combinaison d'une inspection au niveau du domaine et de contrôles au niveau du destinataire, plutôt que de considérer un enregistrement MX comme la réponse définitive.
Utiliser BillionVerify pour des diagnostics complets MX et SMTP
Une recherche MX autonome est utile lorsque la question est précise : ce domaine publie-t-il des enregistrements d'échange de courrier, et les destinations sont-elles classées de manière plausible ? Une plateforme de vérification a un objectif différent. Elle relie les informations du domaine aux résultats au niveau de la boîte aux lettres afin qu'une équipe marketing ou opérationnelle puisse décider quoi faire de chaque adresse.
Les résultats utiles sont structurés plutôt que purement visuels. Les réponses JSON peuvent inclure des valeurs de statut explicites, des enregistrements MX, des résultats catch-all, des champs de confirmation SMTP et des recommandations concernant l'envoi. Ce format convient aussi bien à une personne examinant une liste nettoyée qu'à une application prenant une décision lors d'une inscription ou d'une importation.
Choisir la profondeur des tests selon la décision
Utilisez une vérification MX de base lorsque vous :
- validez le routage entrant d'un nouveau domaine,
- recherchez des enregistrements obsolètes après une migration de fournisseur,
- cherchez pourquoi un domaine ne peut pas recevoir d'emails,
- confirmez que les priorités publiées correspondent au service prévu.
Utilisez une vérification combinée MX et SMTP lorsque vous :
- nettoyez une liste de campagne avant l'envoi,
- séparez les adresses invalides, catch-all, jetables ou génériques,
- validez une adresse lors de la création d'un compte,
- alimentez un CRM ou un workflow sortant avec les résultats.
Le compromis concerne la profondeur du diagnostic. Les vérifications DNS sont rapides et axées sur le domaine, mais elles s'arrêtent avant l'acceptation par la boîte aux lettres. La vérification SMTP pousse l'analyse plus près du destinataire réel et peut produire des résultats incertains lorsque les serveurs limitent les sondages ou refusent de révéler le statut de la boîte aux lettres. Un résultat structuré unknown est plus utile qu'une validation trop confiante, car il donne à l'équipe la possibilité de réessayer ou de procéder à une vérification manuelle.
Pour les équipes commerciales et marketing, le workflow est simple : examiner le domaine, interpréter le résultat SMTP, puis segmenter l'enregistrement selon son statut. Pour les équipes produit, la même logique peut s'exécuter lors de l'inscription, empêchant les adresses manifestement incorrectes d'entrer dans la base de données. La valeur vient de la transformation des informations d'infrastructure en une action de données explicite.
Créer un workflow reproductible de vérification d'email
Un workflow fiable commence par la question utile la moins coûteuse et n'ajoute de profondeur que lorsque la décision l'exige. Cela sépare le dépannage de l'infrastructure de l'hygiène de la liste, tout en reliant les deux à la réputation de l'expéditeur.
Commencer par le domaine
Effectuez une vérification MX avant de diagnostiquer une liste de destinataires. Confirmez que le domaine publie des enregistrements d'échange de courrier, inspectez les noms d'hôte de destination et vérifiez l'ordre des priorités. Si une migration a récemment eu lieu, recherchez spécifiquement les anciens enregistrements qui pourraient encore attirer la livraison.
Examinez ensuite les contrôles DNS associés. MX établit la route entrante, tandis que SPF, DKIM et DMARC aident les systèmes récepteurs à évaluer les envois authentifiés. Le routage peut être sain alors que l'un de ces contrôles reste incomplet ; la préparation d'une campagne nécessite donc une vue d'ensemble.
Passer des domaines aux adresses
Une fois que le domaine dispose d'une route plausible, effectuez une vérification au niveau SMTP sur les adresses réelles. Séparez les résultats clairs des résultats incertains plutôt que de forcer chaque réponse dans une décision binaire.
Un modèle pratique de segmentation se présente ainsi :
- Envoyer : adresses présentant un résultat clairement positif et aucun signal disqualifiant.
- Supprimer : résultats invalides et adresses ne devant pas recevoir d'emails.
- Examiner : adresses catch-all, de rôle ou jetables nécessitant une décision commerciale délibérée.
- Réessayer : résultats inconnus pouvant refléter un comportement temporaire du serveur ou des réponses non concluantes.
Cette approche protège la liste sans prétendre que chaque serveur récepteur expose les mêmes informations. La détection catch-all reste particulièrement importante, car l'acceptation au niveau du domaine ne confirme pas la boîte aux lettres elle-même.
Appliquer les vérifications au bon moment
Les équipes marketing devraient vérifier les listes avant une campagne et répéter le processus lorsque leur source de données change. Les équipes commerciales devraient contrôler les contacts importés ou achetés avant de les ajouter à des séquences. Les équipes produit devraient utiliser une validation en temps réel lors de l'inscription lorsque des adresses fictives ou mal saisies risqueraient de créer des problèmes ultérieurs de support et d'activation.
Une API de validation d'email convient au dernier cas d'utilisation en renvoyant des résultats lisibles par machine qu'une application peut interpréter immédiatement. Pour les opérations par lots, les mêmes catégories de résultats prennent en charge les filtres d'exportation et les workflows de suppression.
Règle de décision : si vous dépannez le routage d'un domaine, commencez par MX. Si vous décidez d'envoyer un email à une personne, ajoutez une vérification SMTP.
Les équipes devraient également documenter la raison de chaque statut. Une adresse supprimée en raison d'une boîte aux lettres invalide diffère d'une adresse catch-all conservée pour examen, et toutes deux diffèrent d'une réponse inconnue en attente d'une nouvelle tentative. Cet historique accélère les futurs audits et aide les responsables de campagne à comprendre pourquoi une adresse n'a pas été contactée.
Un outil de vérification des enregistrements MX est donc nécessaire, mais insuffisant. Il confirme la couche de routage publique, tandis que les diagnostics SMTP testent la couche opérationnelle. Utilisé conjointement avec SPF, DKIM, DMARC, la segmentation des listes et une gestion raisonnable des nouvelles tentatives, le workflow fournit aux équipes une base plus claire pour protéger les taux de rebond et la réputation de l'expéditeur.
BillionVerify combine l'inspection MX avec la vérification d'email au niveau SMTP, en renvoyant des résultats structurés qui aident les équipes à distinguer les adresses valides, invalides, catch-all, inconnues et ne devant pas recevoir d'emails. Consultez BillionVerify pour évaluer comment son workflow de vérification peut s'intégrer à votre campagne, votre CRM, votre processus d'inscription ou vos emails sortants.