Recherche et test MX
Voyez les MX d’un domaine et leur priorité en quelques secondes, gratuit, sans compte. Un MX absent ou mal dirigé explique souvent un courrier entrant perdu.
Qu’est-ce qu’un MX dans le DNS ?
Un enregistrement MX (Mail Exchange) désigne dans le DNS les serveurs qui reçoivent les e-mails d’un domaine. Chacun a une priorité et les serveurs d’envoi les essaient du plus petit nombre au plus grand. Sans MX, les expéditeurs se rabattent sur le A ou AAAA du domaine (règle du MX implicite, RFC 5321), souvent un serveur web sans messagerie : la livraison échoue après des jours de tentatives plutôt qu’aussitôt.
Lire votre résultat
| Résultat | Signification | Que faire |
|---|---|---|
| Serveur de messagerie (MX) présent | Le domaine publie au moins un serveur de messagerie, listé ici par priorité. | Vérifiez que chaque hôte relève d’un fournisseur actuel. Un ancien hôte resté listé peut capter des tentatives de livraison. |
| Enregistrement MX absent | Aucun serveur de messagerie publié. Les expéditeurs se rabattent sur le A ou AAAA du domaine (MX implicite, RFC 5321), rarement un serveur mail : la livraison échoue lentement. | Publiez un MX pour votre fournisseur. Si le domaine ne doit jamais recevoir d’e-mail, publiez plutôt un MX nul. |
| MX nul (priorité 0, hôte .) | Le domaine déclare exprès qu’il n’accepte aucun e-mail (RFC 7505). C’est correct pour un domaine web seul ou d’envoi seul. | Rien, si c’est voulu. Si le domaine doit recevoir, remplacez-le par un vrai MX vers votre fournisseur. |
| Plusieurs hôtes, priorités différentes | Les expéditeurs essaient la priorité la plus basse d’abord, puis descendent la liste si un hôte est injoignable. | Vérifiez que l’hôte de secours accepte bien le courrier du domaine. Un secours qui refuse la livraison est pire que rien. |
| Domaine publicitaire | Le domaine est listé comme publicitaire et n’est pas audité. | Utilisez le domaine qui envoie et reçoit vraiment votre courrier. |
| Domaine non auditable | Le domaine n’existe pas, ou son DNS ne se résout pas publiquement de notre côté. | Revérifiez l’orthographe et que les serveurs de noms répondent aux requêtes publiques. |
Ce que ce test peut prouver
Le test MX de Palisade prouve ce que le DNS public renvoie pour les MX du domaine : quels hôtes sont publiés, dans quel ordre de priorité, et si le domaine publie un MX nul déclarant qu’il refuse tout e-mail. Il ne se connecte pas à ces hôtes : il ne peut dire si un serveur accepte les connexions, si un e-mail précis a été livré ni comment un destinataire filtrera le courrier reçu.
MX ne gère que la réception. Votre courrier sortant inspire-t-il confiance ? Autre question, réglée par SPF, DKIM et DMARC : lancez le score de sécurité e-mail pour voir les quatre.
De l’enregistrement publié au courrier qui arrive
Un MX correct amène le courrier à votre serveur. Faire accepter vos propres e-mails partout est la moitié la plus dure, et elle repose sur des preuves : quels expéditeurs utilisent votre domaine, si chacun s’aligne via SPF ou DKIM, et ce que les destinataires signalent. Palisade fait des rapports agrégés DMARC un flux priorisé pour identifier les expéditeurs, analyser les échecs d’alignement, relire les changements proposés et mener chaque domaine à l’application.
Pour les MSP, c’est multi-client : chaque domaine client testé, corrigé et appliqué depuis une console, avec un prix par domaine client qui baisse quand vous grandissez, sans mesurer le volume d’e-mails.
Tests et termes liés
Le logiciel DMARC qui fait le travail
Palisade transforme les rapports DMARC en tâches priorisées (expéditeurs, alignement) : validez chaque changement et menez vos domaines vers l’application depuis une console.
Audit de domaine gratuit, sans carte. Une carte lance l’essai de 15 jours.
Base de connaissances e-mail
Comment marchent les MX ?
Les MX pointent vers les noms d’hôte des serveurs qui reçoivent les e-mails de votre domaine, jamais vers des IP. Chacun a une priorité. Un serveur d’envoi lit vos MX et essaie d’abord la priorité la plus basse ; si cet hôte est indisponible, il passe au suivant.
Pourquoi publier plusieurs MX ?
Plusieurs MX offrent une autre destination quand l’hôte principal est injoignable. Les expéditeurs suivent la liste par priorité : un second hôte réduit le risque qu’une panne passagère tourne en rebonds ou retards.
Comment configurer les MX de mon domaine ?
Ouvrez la gestion DNS chez le fournisseur qui héberge le DNS du domaine, ajoutez un MX par hôte de réception et donnez à chacun une priorité. Les noms d’hôte visés doivent se résoudre par des A ou AAAA.
Que signifie un MX nul ?
Un MX unique de priorité 0 et d’hôte « . » (le label racine) est un MX nul, défini par RFC 7505. Il déclare exprès que le domaine n’accepte aucun e-mail : le bon réglage pour un domaine web seul ou d’envoi seul. Les expéditeurs rejettent aussitôt au lieu de se rabattre sur l’adresse et de réessayer des jours.
Que se passe-t-il si mes MX manquent ou sont faux ?
Le courrier ne s’arrête pas net. Selon RFC 5321, un domaine sans MX a un MX implicite de priorité 0 vers lui-même : les expéditeurs se rabattent sur son A ou AAAA, souvent un serveur web sans messagerie, et la livraison échoue après des jours de tentatives. Si le domaine ne doit pas recevoir, publiez un MX nul : les expéditeurs ont une réponse claire dès le premier essai.
Combien de temps pour qu’un changement MX s’applique ?
Les changements se propagent à mesure que les caches expirent, selon le TTL des enregistrements. Tant que tous les caches n’ont pas expiré, certains expéditeurs utilisent l’ancienne valeur : gardez l’ancien hôte actif jusqu’à la fin du déploiement.
Un même serveur pour le MX et le site web ?
Techniquement oui, mais les séparer vaut mieux pour la performance et la sécurité, et une panne web n’arrête pas le courrier.
Les MX jouent-ils sur l’authentification ?
Pas directement. MX régit la réception ; SPF, DKIM et DMARC, l’authentification de vos envois. Ils vont ensemble : vos hôtes de réception sont souvent la plateforme par laquelle vous envoyez, et c’est elle qu’il faut autoriser dans SPF et faire signer en DKIM.
Quelles sont les erreurs MX courantes ?
Pointer un MX vers une IP au lieu d’un nom d’hôte, vers un hôte sans A ni AAAA, laisser l’hôte d’un ancien fournisseur après une migration, et supprimer tout MX sur un domaine qui devrait publier un MX nul.
Puis-je utiliser un fournisseur e-mail tiers ?
Oui. Pointez vos MX vers les noms d’hôte fournis, retirez ceux de l’ancien fournisseur une fois la migration finie, et mettez à jour SPF et DKIM en même temps pour que vos envois restent authentifiés.
Chaque balise et mécanisme de DMARC, SPF et DKIM, expliqués au même endroit.
DMARC
- vVersion
- La balise Version est indispensable dans un DMARC et doit valoir strictement « DMARC1 ». Si la valeur est incorrecte ou la balise absente, l’enregistrement DMARC n’est pas valide et il est ignoré.
- pPolitique DMARC
- La balise de politique DMARC accepte trois valeurs pour le courrier qui échoue : none ne demande aucune application, quarantine un traitement suspect, reject le rejet. Les destinataires décident en dernier et peuvent filtrer ou rejeter via d’autres contrôles en p=none. Les rapports agrégés se demandent à part, via la balise rua.
- ruaDestination des rapports agrégés
- La destination des rapports agrégés est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour envoyer les rapports agrégés. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- rufDestination forensique
- La destination des rapports forensiques (d’échec) est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour livrer les rapports d’échec. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- spSous-domaines
- Par défaut, la politique des sous-domaines hérite de la balise de politique du domaine principal (p=), décrite plus haut, sauf mention contraire. Comme pour le domaine, les valeurs possibles sont « none », « quarantine » ou « reject ». Cette option reste toutefois peu utilisée en pratique.
- adkimAlignement DKIM
- Cette balise fixe l’alignement de la signature DKIM, c’est-à-dire la correspondance entre le domaine DKIM et le domaine d’origine du « Header From ». Valeurs possibles : « r » (relaxed) et « s » (strict). Par défaut, « r » accepte une correspondance partielle entre ces domaines, tandis que « s » exige qu’ils soient identiques.
- aspfAlignement SPF
- Cette balise fixe l’alignement SPF, c’est-à-dire la compatibilité entre le domaine SPF (l’expéditeur) et le domaine du « Header From ». Deux valeurs : « r » (relaxed) et « s » (strict). Par défaut, « r » tolère une correspondance partielle entre les domaines. À l’inverse, « s » exige une correspondance exacte des domaines.
- foOptions forensiques
- Les options des rapports forensiques sont « 0 », « 1 », « d » et « s ». Par défaut, « 0 » déclenche un rapport seulement quand les alignements SPF et DKIM échouent tous deux. « 1 » en déclenche un dès que SPF ou DKIM ne passe pas. « d » produit un rapport pour les échecs de validation DKIM, « s » pour les problèmes SPF. Pour recevoir ces rapports forensiques, il faut renseigner la balise « ruf ».
- rfFormat des rapports
- Le format des rapports d’échec peut valoir « afrf » ou « iodef », les deux seules options autorisées.
- pctPourcentage (historique)
- L’ancienne balise Pourcentage demandait d’appliquer quarantine ou reject à une partie seulement du courrier en échec DMARC. La RFC 9989 a retiré pct, l’application partielle étant mise en œuvre de façon inégale. Les nouveaux enregistrements l’omettent et échelonnent via les rapports agrégés, des politiques entières et des sous-domaines à faible volume.
- riFréquence des rapports
- L’intervalle des rapports indique, en secondes, la fréquence des rapports XML. La valeur standard est 86400 secondes, soit un rapport par jour. Notez toutefois que, quel que soit l’intervalle indiqué, les fournisseurs d’accès (FAI) envoient en général ces rapports selon leur propre calendrier, le plus souvent une fois par jour également.
SPF
- v
- La balise de version doit valoir « spf1 », exclusivement. Une version fausse ou absente fait ignorer l’enregistrement SPF.
- ip4
- Cette balise liste les adresses IPv4 autorisées à envoyer pour le domaine.
- ip6
- Cette balise indique les adresses IPv6 autorisées à envoyer au nom du domaine.
- a
- La balise A valide l’expéditeur via l’adresse IP du domaine, le domaine courant par défaut s’il n’est pas précisé.
- mx
- La balise MX valide l’enregistrement MX du serveur mail, le domaine courant par défaut s’il n’est pas précisé.
- ptr
- La balise PTR lance un contrôle PTR des noms d’hôte des IP clientes, déconseillé par la RFC 7208 (trop de requêtes DNS).
- exists
- La balise exists vérifie la présence d’un enregistrement A sur le domaine indiqué.
- include
- La balise include est essentielle à un SPF exact : elle confirme aux destinataires que chaque domaine ou sous-domaine listé envoie légitimement.
- all
- La balise all est obligatoire, en fin d’enregistrement SPF : ses qualificateurs (~, +, -, ?) disent aux destinataires comment traiter les sources non autorisées.
DKIM
- v
- La balise de version indique la version de DKIM, qui doit toujours valoir 1.
- p
- La balise de clé publique, une chaîne créée à la configuration DKIM, ne doit pas être vide pour rester valide.
- t
- Cette balise liste des indicateurs séparés par deux-points ; seuls « y » et « s » sont définis, les autres doivent être ignorés.
- s
- Cette balise précise les types de service concernés. Les serveurs destinataires ignorent les types absents ou inconnus.
- h
- Cette balise indique les algorithmes de hachage permis (tous par défaut). Les destinataires ignorent ceux qu’ils ne connaissent pas ; l’expéditeur fixe la liste.
- n
- Cette balise est un champ de note facultatif pour les administrateurs, à n’utiliser qu’au besoin.