Un MX record indique quels serveurs reçoivent le courrier pour un domaine. Il pointe vers un nom d'hôte. Le résolveur suit ce nom pour trouver des enregistrements A ou AAAA. Le serveur expéditeur peut alors livrer les messages.
Un MX record contient un nom un type une priorité une cible et un TTL. Le TTL indique combien de temps la réponse reste en cache dans le résolveur local.
| Nom | Type | Priorité | Cible | TTL en secondes |
|---|
| @ | MX | 10 | mail.exemple.net. | 3600 |
Dans cet exemple le nom @ vise la racine du domaine. La cible est un nom d'hôte qui doit publier A ou AAAA. Une priorité plus faible est préférée. Un TTL à 3600 correspond à une heure.
Publier plusieurs MX records pour un même nom est courant. Le serveur expéditeur choisit d'abord la priorité la plus basse. En cas d'échec, il tente la suivante.
| Nom | Type | Priorité | Cible | TTL en secondes |
|---|
| @ | MX | 10 | mx1.exemple.net. | 3600 |
| @ | MX | 20 | mx2.exemple.net. | 3600 |
Cette redondance augmente la continuité de service. Elle ne remplace pas une supervision active ni des tests réguliers.
Un MX record pointe vers un nom pas vers une adresse. La cible ne doit pas être un CNAME. Le nom visé doit publier A ou AAAA et être joignable sur le port 25. Le MX peut exister à l'apex ou sur un sous domaine si l'adresse courriel utilise ce sous domaine.
Un TTL court rend un changement visible plus vite. Utile lors d'un passage vers un nouveau service de messagerie.
Un TTL moyen ou long réduit les requêtes vers les serveurs autoritaires. Adapté à un service stable.
Réduire le TTL quelques heures avant la bascule puis le remonter quand tout est validé.
Bon à savoir
Les enregistrements MX servent à la réception. Le courrier sortant utilise d'autres réglages comme SPF, DKIM, DMARC et la configuration du relais sortant.
Publier le MX sur le domaine qui reçoit le courrier. Le plus souvent, c'est la racine. Pour un domaine dédié comme support.exemple.com publier le MX sur ce sous domaine. Les hôtes de messagerie référencés par les enregistrements MX gardent leurs propres A ou AAAA.
À éviter
Pointer un MX vers un CNAME ou vers une adresse directe.
Oublier l'enregistrement A ou AAAA de la cible.
Laisser un ancien MX actif après une migration.
Un DNS lookup en ligne permet d'entrer un nom de domaine. On obtient la liste des MX avec leurs priorités leurs cibles et le TTL visible depuis Internet. C'est un premier contrôle utile. Faire ensuite un test local depuis sa machine.
Windows fournit nslookup. On peut l'utiliser en mode interactif.
nslookup
set q=mx
exemple.com
nslookup
set q=mx
server 1.1.1.1
exemple.com
La première partie interroge selon la configuration réseau de la machine. La seconde force l'usage d'un résolveur tiers ici celui de Cloudflare.
Sur ces systèmes la commande dig est pratique et facile à utiliser.
dig MX exemple.com
dig MX exemple.com @1.1.1.1
Plusieurs lignes indiquent plusieurs serveurs. Le plus petit nombre de priorité est préféré. Des priorités identiques se partagent les tentatives de manière équilibrée.
Un TTL restant élevé peut expliquer un décalage après un changement.
Une cible sans A ni AAAA empêche la livraison.
- Préparer les hôtes de messagerie avec leurs A ou AAAA.
- Réduire le TTL des MX à 300 voire 60 secondes quelques heures avant la bascule.
- Ajouter les nouveaux MX avec la priorité prévue. Conserver les anciens pendant la transition.
- Tester la réception depuis plusieurs réseaux. Vérifier les en têtes des messages reçus.
- Retirer les anciens MX puis remonter le TTL quand tout est stable.
Astuce pratique
Noter la liste complète des MX avant modification. Conserver la date les priorités le TTL et la raison du changement. Cette trace évite les erreurs et facilite un retour arrière.
Publier les MX fournis par le prestataire. Les cibles appartiennent au domaine du prestataire. Garder un TTL raisonnable.
Pointer les MX vers le fournisseur de filtrage. Ce fournisseur relaye ensuite vers vos serveurs. Surveiller la latence et la disponibilité.
Déclarer un serveur secondaire avec une priorité plus élevée. Il retient les messages si le serveur principal est indisponible puis les remet quand il revient.
- En cas de rebond vérifier que la cible du MX résout en A ou AAAA.
- Vérifier l'accessibilité réseau sur le port 25 vers la cible.
- Si des MX pointent encore vers l'ancien prestataire les retirer après la bascule.
- Si la réponse reste ancienne attendre l'expiration du TTL et purger le cache du résolveur local si possible.
En résumé, un enregistrement MX indique le serveur de réception pour un domaine. Il pointe vers un nom d'hôte qui publie A ou AAAA. La priorité la plus basse est choisie en premier. Un TTL bien choisi facilite les changements. La vérification passe par un outil en ligne puis par nslookup et par dig.
Avec ces repères la gestion reste claire. Les changements se déroulent sans stress. Les messages arrivent sans incident.