Qu'est-ce qu'une recherche ESP / MX ?
Tout domaine acceptant du courrier publie un ou plusieurs enregistrements MX (Mail Exchanger) dans le DNS. Ces enregistrements pointent vers les noms d'hôte des serveurs de courrier responsables de la réception, avec une préférence numérique qui décide de l'ordre de résolution. Les motifs des noms d'hôte sont généralement distinctifs — Google Workspace publie `aspmx.l.google.com`, Microsoft 365 publie `*.mail.protection.outlook.com`, Zoho publie `mx.zoho.com`, etc.
Un vérificateur ESP interroge ces enregistrements MX, les trie par préférence et compare les noms d'hôte à une base de fournisseurs connus. Le protocole est régi par **RFC 5321** (la spécification SMTP moderne) et **RFC 7505** (qui définit le 'Null MX' pour les domaines qui ne reçoivent jamais de courrier).
Pourquoi vérifier les enregistrements ESP / MX ?
1Adaptez l'outreach au fournisseur
Gmail, Microsoft et les filtres sur site notent le contenu différemment — connaître la destination guide les objets et le HTML
2Confirmez les bascules de migration
Après être passé d'un fournisseur à un autre, vérifiez que les enregistrements MX pointent vers la nouvelle plateforme avant de désactiver l'ancienne
3Détectez le courrier mal routé
Une faute de frappe ou un MX obsolète envoie silencieusement le courrier au mauvais fournisseur — le vérificateur le révèle aussitôt
4Auditez les portefeuilles de domaines
Lors de l'acquisition ou de l'audit d'une entreprise, voyez d'un coup d'œil la plateforme de messagerie utilisée par chaque domaine
Comment fonctionne la détection ESP — étape par étape
Vous saisissez un domaine. Le vérificateur interroge ses enregistrements MX via le DNS.
Chaque enregistrement MX est analysé en un numéro de préférence et un nom d'hôte.
Les enregistrements sont triés par préférence — le numéro le plus bas est essayé en premier par les serveurs d'envoi.
Les noms d'hôte sont comparés à des motifs de fournisseurs connus (Google, Microsoft, Zoho, Proofpoint, Mimecast et des dizaines d'autres).
Le fournisseur détecté est affiché, avec la liste MX complète triée par préférence pour que vous puissiez auditer vous-même le routage.
Syntaxe de l'enregistrement MX
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.Description des champs
préférence— la plus basse gagne, cet hôte est essayé en premierhôte— nom d'hôte du serveur de réceptionTTL— durée de vie en cache en secondesIN— classe d'enregistrement InternetMX— type d'enregistrementÉchecs ESP / MX courants et solutions
Aucun enregistrement MX publié
Sans enregistrements MX, le domaine ne peut pas recevoir de courrier — publiez les enregistrements fournis par votre fournisseur
MX de l'ancien fournisseur toujours actif
Après la migration, l'ancien MX répond encore — supprimez les enregistrements obsolètes pour arrêter les boucles de courrier
Même préférence pour chaque enregistrement
Soit intentionnel (round-robin), soit accidentel — consultez la documentation du fournisseur
MX pointant vers un CNAME
RFC 2181 interdit qu'un MX pointe vers un CNAME — faites pointer le MX directement vers un hôte avec un enregistrement A/AAAA
Foire aux questions
Un vérificateur ESP (Email Service Provider) inspecte les enregistrements MX d'un domaine et les compare à une base de fournisseurs connus comme Google Workspace, Microsoft 365, Zoho, Proofpoint et Mimecast. Les noms d'hôte MX révèlent en général le fournisseur sans ambiguïté, même si le domaine lui-même est personnalisé.
Connaître l'ESP destinataire vous aide à adapter l'outreach — Gmail et Outlook notent le contenu différemment — et à déboguer les problèmes de livraison en consultant les règles publiées du fournisseur. Pour votre propre domaine, cela confirme que vous ne pointez pas les MX vers une plateforme obsolète après une migration.
La préférence MX (parfois appelée priorité) est un nombre qui indique aux serveurs d'envoi quel hôte MX essayer en premier. Les nombres les plus bas passent en premier ; le reste sert de repli si le principal est inaccessible. Le vérificateur trie les enregistrements par préférence pour rendre l'ordre de résolution évident.
Les fournisseurs publient plusieurs MX pour la redondance. Si l'hôte principal est en panne, les serveurs d'envoi réessaient le suivant selon la préférence. Google Workspace et Microsoft 365 publient typiquement 4–5 entrées MX sur des infrastructures différentes pour garantir l'acceptation du courrier même lors de pannes régionales.
Oui. Un domaine sans MX ne peut pas recevoir d'e-mails. Le RFC 5321 dit que les serveurs d'envoi devraient se rabattre sur l'enregistrement A/AAAA, mais la plupart des expéditeurs en production traitent l'absence de MX comme un rebond définitif. Si votre vérificateur ESP ne renvoie aucun MX sur un domaine censé recevoir du courrier, publiez les bons MX immédiatement.
Il fonctionne sur tout domaine publiant des MX. Les domaines parqués ou inutilisés exposent souvent les MX par défaut de votre bureau d'enregistrement ou une configuration 'sans MX', et le vérificateur les signale clairement. C'est utile pour auditer des portefeuilles entiers de domaines.