Enregistrements MX (Mail eXchange) et vérifications de livraison de courriel

1. Enregistrements MX

Ce bloc liste les enregistrements MX retournés par vos serveurs DNS, incluant la priorité, le nom d’hôte cible et souvent les IP résolues.

Pourquoi c’est important

Sans enregistrements MX corrects, les serveurs distants ne savent pas où livrer le courriel pour votre domaine. Toutes les autres vérifications de la section MX dépendent d’abord de cette liste.

Comment DNSprobe vérifie ce point

DNSprobe interroge tous les serveurs de noms autoritaires pour l’enregistrement MX de votre domaine et affiche l’ensemble unique trouvé. Il indique aussi si certains MX inhabituels n’apparaissent que sur une partie des serveurs.

Problèmes courants détectés

• Aucun enregistrement MX pour le domaine, obligeant les expéditeurs à se rabattre sur les enregistrements A/AAAA si leur configuration le permet.
• Enregistrements MX pointant vers des noms d’hôtes inexistants ou manifestement fictifs.
• MX résiduels laissés en place après une migration vers un nouveau fournisseur de courriel.

Bonnes pratiques

• Définir des enregistrements MX explicites, même si le courriel est traité par le même serveur que votre site web.
• Utiliser des noms d’hôtes dédiés et clairs pour les serveurs de courriel (par exemple mail.example.com ou mx1.example.com).
• Supprimer les anciens MX lorsque vous migrez vers une nouvelle plateforme de messagerie.

2. Enregistrements MX différents selon les NS

Ce test vérifie que tous vos serveurs de noms autoritaires publient le même ensemble d’enregistrements MX.

Pourquoi c’est important

Si les serveurs de noms n’annoncent pas les mêmes MX, certains expéditeurs utiliseront un serveur de courriel tandis que d’autres viseront un autre chemin. Cela peut causer des rebonds aléatoires, des délais ou un routage inattendu.

Comment DNSprobe vérifie ce point

DNSprobe interroge chaque serveur de noms pour les enregistrements MX et compare les résultats en détail. Il indique si les ensembles correspondent exactement ou si certains NS ont des MX manquants ou supplémentaires.

Problèmes courants détectés

• Un serveur de noms annonce encore un ancien serveur MX provenant d’une configuration précédente.
• Zones DNS primaires cachées versus secondaires publics qui ne sont pas synchronisés pour les enregistrements MX.
• Modifications manuelles effectuées sur un seul serveur plutôt que sur un fichier de zone centralisé.

Bonnes pratiques

• S’assurer que tous les serveurs de noms autoritaires servent exactement les mêmes données MX.
• Utiliser une réplication automatique ou un fournisseur qui gère la zone de manière centralisée.
• Après toute modification MX, vérifier que chaque NS répond avec les nouveaux enregistrements.

3. Validité des noms MX

Ce test vérifie la syntaxe de vos noms d’hôtes MX et repère les erreurs fréquentes.

Pourquoi c’est important

Les cibles d’un MX doivent être des noms de domaine pleinement qualifiés, pas de simples labels, pas des adresses de courriel et pas des IP littérales. Des noms invalides peuvent être ignorés ou mal interprétés par certains expéditeurs.

Comment DNSprobe vérifie ce point

DNSprobe examine chaque cible MX pour s’assurer qu’il s’agit d’un nom d’hôte valide, respectant les limites de longueur et ne contenant pas de caractères évidemment erronés comme des espaces ou un « @ ».

Problèmes courants détectés

• MX pointant directement vers une adresse courriel (par exemple [email protected]).
• Cibles MX non pleinement qualifiées ou contenant des caractères non autorisés.
• Points en trop ou noms tronqués qui ne correspondent à aucun enregistrement DNS réel.

Bonnes pratiques

• Utiliser des noms d’hôtes pleinement qualifiés comme cibles MX.
• Éviter les noms génériques ou temporaires; privilégier des noms stables qui correspondent à vos certificats TLS.
• Lorsque possible, laisser votre fournisseur DNS ou courriel proposer les noms d’hôtes pour réduire les risques de fautes de frappe.

4. IP des MX publiques

Ce test vérifie que les adresses IP associées à vos MX sont joignables sur Internet (non privées ou réservées).

Pourquoi c’est important

Les serveurs de courriel doivent être atteignables depuis d’autres réseaux. Si les MX pointent vers des IP privées ou réservées, les systèmes externes ne peuvent pas livrer de courriel.

Comment DNSprobe vérifie ce point

DNSprobe résout les enregistrements A et AAAA pour chaque nom MX et vérifie si les IP obtenues se trouvent dans des plages privées, de loopback ou non routables.

Problèmes courants détectés

• Enregistrements MX pointant vers des IP privées RFC1918 comme 10.x.x.x ou 192.168.x.x.
• Noms MX ne résolvant que vers des adresses IPv6 locales ou de loopback.
• IP internes temporaires accidentellement publiées dans le DNS public.

Bonnes pratiques

• Publier uniquement des IP globalement routables pour les noms MX.
• Séparer les vues DNS internes et externes si vous avez besoin d’IP MX privées pour l’interne.
• Coordonner avec votre FAI ou hébergeur pour que le DNS inversé corresponde aussi à ces IP publiques.

5. Vérification CNAME sur les MX

Ce test confirme que les cibles de vos enregistrements MX ne sont pas des CNAME, ce qui est interdit par les standards DNS.

Pourquoi c’est important

Selon les RFC, un MX doit pointer directement vers des enregistrements A/AAAA, pas vers des alias CNAME. Certains résolveurs suivent les CNAME, d’autres peuvent les considérer comme des erreurs, entraînant des comportements incohérents.

Comment DNSprobe vérifie ce point

DNSprobe récupère les enregistrements MX puis vérifie le type DNS de chaque cible. Si l’une d’elles est un CNAME, le rapport l’indique.

Problèmes courants détectés

• Cible MX définie uniquement comme CNAME vers un autre hôte.
• Chaînes de CNAME multiples pour atteindre le véritable serveur de courriel.
• Configurations temporaires ou de migration où l’on utilise des CNAME par commodité au lieu d’enregistrements A/AAAA directs.

Bonnes pratiques

• Définir les cibles MX comme des noms d’hôtes disposant d’enregistrements A/AAAA directs.
• Si vous avez besoin d’indirection, gérer cela au niveau A/AAAA plutôt qu’avec des CNAME pour les cibles MX.
• Réviser les noms MX à chaque changement d’infrastructure de messagerie.

6. A sur MX retourne un CNAME

Ce test vérifie si les requêtes A/AAAA pour les noms MX retournent d’abord un CNAME au lieu d’adresses directes.

Pourquoi c’est important

Même si le MX lui-même n’est pas un CNAME, certains DNS répondent aux requêtes A/AAAA avec un CNAME intermédiaire. Cela peut perturber certains résolveurs, outils de monitoring ou configurations TLS.

Comment DNSprobe vérifie ce point

DNSprobe envoie des requêtes A/AAAA pour chaque nom MX et examine si la première réponse est une adresse ou un CNAME qui renvoie ailleurs.

Problèmes courants détectés

• Noms MX qui se résolvent via un ou plusieurs sauts CNAME au lieu d’enregistrements A/AAAA directs.
• Configurations de type CDN ou répartition de charge réutilisées pour le courriel alors qu’elles ne sont pas adaptées.
• Indirections laissées en place après un déplacement du serveur de messagerie réel.

Bonnes pratiques

• Privilégier des enregistrements A/AAAA directs pour les noms MX.
• Éviter de partager des noms d’hôtes web/CDN avec vos points d’entrée de courriel.
• Si vous utilisez des CNAME en interne, masquer cette complexité derrière un nom externe possédant un A/AAAA direct.

7. MX n’est pas une IP

Ce test confirme que vos enregistrements MX ne pointent pas directement vers des adresses IP numériques.

Pourquoi c’est important

Les enregistrements MX doivent référencer des noms d’hôtes, pas des littéraux IP. Utiliser une IP brute enfreint certaines règles DNS et rend les changements d’infrastructure plus difficiles.

Comment DNSprobe vérifie ce point

DNSprobe examine chaque cible MX et signale toute valeur qui ressemble à une adresse IPv4 ou IPv6 au lieu d’un nom d’hôte.

Problèmes courants détectés

• Enregistrements MX configurés directement avec des adresses IPv4.
• Enregistrements MX configurés directement avec des adresses IPv6.
• Configurations mixtes où certains MX sont des noms d’hôtes et d’autres des IP.

Bonnes pratiques

• Toujours pointer les MX vers des noms d’hôtes que vous contrôlez.
• Modifier l’IP en ajustant l’enregistrement A/AAAA plutôt que le MX lui-même.
• Aligner le nom DNS avec vos certificats TLS et votre DNS inversé.

8. Nombre d’enregistrements MX

Ce test compte le nombre d’enregistrements MX distincts publiés pour votre domaine et commente la redondance.

Pourquoi c’est important

Un seul serveur MX représente un point de défaillance unique. Des entrées MX supplémentaires avec des priorités appropriées offrent des chemins de secours pour le courriel entrant.

Comment DNSprobe vérifie ce point

DNSprobe compte les enregistrements MX distincts et met en évidence les cas où il n’y a qu’une seule entrée ou au contraire un nombre inhabituellement élevé.

Problèmes courants détectés

• Un seul enregistrement MX, donc aucune redondance si ce serveur tombe.
• Plusieurs MX qui pointent tous vers la même machine, ce qui n’apporte qu’une redondance illusoire.
• Très grand nombre d’entrées MX avec des priorités mal planifiées.

Bonnes pratiques

• Utiliser au moins deux enregistrements MX sur des infrastructures indépendantes lorsque c’est possible.
• Attribuer les numéros de préférence les plus bas aux serveurs principaux et les plus élevés aux serveurs de secours.
• S’assurer que les serveurs de secours sont réellement distincts (machines ou fournisseurs différents).

9. IPs A des MX incohérentes

Ce test compare les enregistrements A/AAAA des noms MX tels que vus par chaque serveur de noms.

Pourquoi c’est important

Si les serveurs DNS ne résolvent pas un même nom MX vers les mêmes IP, le courriel peut être routé vers des machines inattendues, voire erronées.

Comment DNSprobe vérifie ce point

DNSprobe résout chaque nom MX via tous les serveurs de noms autoritaires et compare les ensembles d’IP retournés.

Problèmes courants détectés

• Enregistrements A/AAAA des noms MX non synchronisés entre les serveurs DNS.
• Fuites d’IP internes visibles depuis certains serveurs DNS mais pas les autres.
• Migration incomplète où seuls certains NS ont été mis à jour vers la nouvelle IP de serveur de courriel.

Bonnes pratiques

• Maintenir des enregistrements A/AAAA identiques pour les noms MX sur tous les serveurs de noms autoritaires.
• Utiliser une source de vérité unique pour le DNS et propager automatiquement les changements.
• Après un changement d’IP, vérifier que tous les NS répondent avec les nouvelles adresses.

10. Enregistrements A des MX dupliqués

Ce test repère les situations où plusieurs noms MX se résolvent vers une même adresse IP.

Pourquoi c’est important

Plusieurs noms MX pointant vers un seul serveur ne procurent pas de vraie redondance et peuvent rendre le diagnostic plus confus.

Comment DNSprobe vérifie ce point

DNSprobe résout tous les noms MX, regroupe les résultats par IP et indique les cas où plusieurs noms partagent la même adresse.

Problèmes courants détectés

• Deux ou plusieurs enregistrements MX qui se résolvent tous vers un seul serveur de courriel.
• Anciens noms MX conservés mais pointant toujours vers la même IP après consolidation.
• Valeurs de priorité donnant l’illusion de redondance alors que tout aboutit à une seule machine.

Bonnes pratiques

• Lorsque vous publiez plusieurs MX, les faire vraiment pointer vers des serveurs ou IP distincts.
• Si vous utilisez plusieurs noms pour des raisons de marque, envisager un vrai équilibrage de charge ou cluster derrière ces noms.
• Réviser régulièrement les enregistrements MX pour retirer les noms inutilisés pointant toujours vers des serveurs actifs.

11. DNS inversé des IP MX (PTR)

Ce test vérifie si les IP derrière vos enregistrements MX possèdent un enregistrement PTR et si celui-ci semble cohérent avec le nom de votre serveur.

Pourquoi c’est important

Beaucoup de serveurs de réception utilisent le PTR comme un des signaux de filtrage anti-spam. Un DNS inversé absent ou incohérent ne bloque pas toujours le courriel, mais peut nuire à votre réputation et à votre délivrabilité.

Comment DNSprobe vérifie ce point

DNSprobe effectue une requête PTR pour chaque IP de MX, affiche le nom retourné, puis compare grossièrement ce nom avec votre nom MX pour voir s’ils semblent liés.

Problèmes courants détectés

• Aucun enregistrement PTR défini pour l’IP du serveur MX.
• PTR pointant vers un nom générique du FAI, sans lien avec votre domaine.
• PTR pointant vers un nom d’hôte qui ne se résout pas de nouveau vers la même IP (absence de cohérence aller-retour).

Bonnes pratiques

• Configurer des enregistrements PTR renvoyant vers un nom d’hôte que vous contrôlez, généralement le même (ou très proche) que votre nom MX.
• S’assurer que le nom renvoyé par le PTR possède un enregistrement A/AAAA pointant sur la même IP.
• Aligner le PTR, le nom d’hôte MX et la bannière SMTP pour maximiser la délivrabilité.

12. Tester les enregistrements MX manuellement depuis votre propre terminal

La section MX de DNSprobe vérifie quels serveurs de messagerie (MX) sont publiés pour votre domaine, s’ils utilisent des IP publiques et si le reverse DNS est correctement configuré. Vous pouvez reproduire la plupart de ces vérifications depuis un terminal en interrogeant les enregistrements MX et A, puis en testant éventuellement la connectivité SMTP sur le port 25.

Linux : utiliser dig (outils BIND) et nc

Sur la plupart des distributions Linux, les outils dig et nc (netcat) sont disponibles dans les dépôts par défaut. Les commandes ci-dessous affichent les enregistrements MX de votre domaine, résolvent les noms d’hôtes utilisés comme cibles MX, puis testent en option si l’hôte principal de messagerie accepte les connexions SMTP sur le port 25 :

                dig example.com MX
                dig example.com MX +noall +answer
    
                # Lister les enregistrements MX et leurs valeurs de priorité pour example.com    
                dig mail.example.com A +noall +answer
    
                # Résoudre l’enregistrement A de votre hôte mail (par exemple mail.example.com), puis tester en option le port TCP 25    
                nc -vz mail.example.com 25
        

macOS : utiliser dig et nc avec les outils intégrés

macOS inclut dig et nc dans ses outils en ligne de commande. Ouvrez Terminal et exécutez les mêmes commandes que sous Linux pour afficher les enregistrements MX, résoudre l’hôte de messagerie et vérifier la joignabilité SMTP de base sur le port 25 :

                dig example.com MX
                dig example.com MX +noall +answer
    
                # Lister les enregistrements MX et leurs valeurs de priorité pour example.com    
                dig mail.example.com A +noall +answer
    
                # Résoudre l’enregistrement A de votre hôte mail (par exemple mail.example.com), puis tester en option le port TCP 25    
                nc -vz mail.example.com 25
        

Windows : utiliser nslookup et PowerShell

Sous Windows, vous pouvez utiliser nslookup pour interroger les enregistrements MX et A, puis la commande Test-NetConnection de PowerShell pour tester si l’hôte MX est joignable sur le port 25. Exécutez les commandes suivantes depuis une fenêtre Invite de commandes ou PowerShell :

                nslookup -type=MX example.com
    
                REM Afficher les enregistrements MX et leurs priorités pour example.com    
                nslookup -type=A mail.example.com
    
                REM Résoudre l’enregistrement A de votre hôte mail (par exemple mail.example.com), puis tester le port TCP 25 avec Test-NetConnection    
                Test-NetConnection mail.example.com -Port 25
        

Important : ne testez que des hôtes de messagerie et des domaines que vous possédez ou que vous êtes autorisé à analyser. Des tests de connectivité SMTP ou des scans de ports répétés sur des systèmes tiers sans autorisation peuvent être considérés comme un comportement abusif par certains fournisseurs.