Courriel : Plusieurs enregistrements MX — comment la priorité fonctionne vraiment (et erreurs courantes)

janvier 15, 2026 • février 3, 2026 • Lecture : 27 min • Views: 3

Cet article vous a aidé ?

Vous avez modifié les enregistrements MX pour « ajouter de la redondance », êtes rentré chez vous, et vous vous êtes réveillé avec une avalanche de tickets :
certains expéditeurs ne peuvent pas livrer, d’autres livrent lentement, et quelques messages rebondissent avec des erreurs qui ressemblent à un roman de Kafka.
Le système de messagerie est « up », mais la livraison n’est pas un état binaire. C’est un processus négocié entre le DNS, les clients SMTP, les politiques et le temps.

Les enregistrements MX multiples sont l’un de ces boutons qui semblent simples et qui contrôlent discrètement qui vous contacte, quand, et à quel point ils vont insister.
La « priorité » existe, mais ce n’est pas le genre de priorité que beaucoup imaginent. Si vous la traitez comme un interrupteur actif/standby clair, elle vous punira.

Priorité MX : ce que cela signifie vraiment (et ce que ce n’est pas)

Un enregistrement MX dit : « Pour ce domaine, voici les hostnames qui acceptent le mail SMTP, et voici un ordre de préférence. »
La valeur numérique s’appelle la préférence (souvent appelée familièrement « priorité »). Les nombres plus bas sont préférés. C’est la partie que tout le monde retient.
La partie que beaucoup oublient : les expéditeurs SMTP ne sont pas obligés de faire ce que vous souhaitez ; ils suivent les standards et leurs propres politiques opérationnelles.

La préférence MX n’est pas une vérification de santé.
Elle ne prouve pas que le serveur est joignable, configuré, autorisé ou prêt.
Elle ne garantit même pas qu’un expéditeur essaiera d’abord le plus bas si le cache local ou la politique dit le contraire.
C’est un indice. Un bon indice. Mais toujours un indice.

Le sens pratique des enregistrements MX multiples est le suivant :

La préférence la plus basse est essayée en premier dans le cas normal.
La préférence plus élevée est essayée si la plus basse échoue (connection refused, timeout, 4xx, etc.), puis les expéditeurs mettent généralement en file et réessaient plus tard.
La même préférence entraîne un partage de charge (pas garanti équitablement, mais c’est l’intention).
Le basculement est probabiliste et dépend du temps : il dépend de la rapidité des échecs, de la durée des files d’attente et du comportement des schedules de retry.

Considérez la préférence MX comme une politique de routage pour le logiciel des autres, exécutée selon leur calendrier.
C’est moins un feu de circulation et plus une série de panneaux routiers dans une autre ville.

Deux règles qui sauvent des carrières

Si un hostname figure dans MX, il doit pouvoir accepter le mail pour le domaine (et le traiter correctement), sinon vous vous inscrivez à des pertes nondéterministes, des délais et des rebonds.
Ne publiez jamais une cible MX que vous ne pouvez pas surveiller et exploiter.
« C’est juste un backup » est la façon la plus sûre d’obtenir des relais de spam surprises, des pannes surprises et des conversations juridiques surprises.

Une citation, un rappel de réalité

Idée paraphrasée (souvent attribuée à la pensée fiabilité des systèmes) : L’espoir n’est pas une stratégie ; la conception et la vérification le sont.
C’est l’état d’esprit à adopter lorsque vous publiez du DNS qui influence la livraison de mails à l’échelle mondiale.

Algorithme de sélection : comment les expéditeurs choisissent parmi les cibles MX

Voici l’algorithme simplifié que la plupart des clients SMTP suivent, basé sur le comportement standard :

Rechercher les enregistrements MX pour le domaine du destinataire.
S’il n’y en a pas, revenir à une recherche A/AAAA sur le domaine lui-même (oui, encore courant).
Trier les cibles MX par préférence croissante (nombre le plus bas en premier).
Pour les cibles avec la même préférence, randomiser ou faire une rotation de l’ordre.
Pour chaque cible dans l’ordre :
- Résoudre A/AAAA pour le(s) hostname(s) MX.
- Essayer la livraison vers une des IP résolues (la politique varie : certains essaient toutes, certains en choisissent une, certains préfèrent IPv6).
- Si la livraison échoue avec une erreur transitoire, continuer à la cible suivante ou mettre en file et réessayer plus tard.
- Si la livraison échoue de façon permanente (5xx), générer un bounce.

Voilà le chemin heureux. En production, ça devient intéressant :

Le cache DNS signifie qu’un expéditeur peut continuer à utiliser d’anciennes réponses MX plus longtemps que votre fenêtre de changement, selon le TTL et le comportement du resolver.
La politique locale peut outrepasser votre conception : certains grands providers traitent différemment certaines plages IP, ou font du routage « sticky » pour réduire le churn des connexions.
Les échecs au niveau connection ne se valent pas : un « connection refused » rapide déclenche un basculement immédiat ; un timeout brûle des secondes et peut bloquer le débit des files.
Le greylisting et le rate limiting peuvent transformer votre « backup » en aimant pour des retries lents.

Si vous voulez un basculement net, le seul MX ne vous l’apportera pas. Il vous donne une livraison éventuelle dans des conditions raisonnables.
Si vous avez besoin d’un routage déterministe, vous entrez dans le domaine de la gestion de trafic devant le SMTP (ou de l’utilisation d’un service mail qui le fournit).

Blague #1 : la priorité MX, c’est comme un organigramme. Ça a l’air autoritaire jusqu’à ce que vous regardiez comment les décisions sont réellement prises.

Faits intéressants et contexte historique

Le mail est plus ancien que la plupart de vos outils de supervision, et il conserve des comportements hérités qui comptent encore.
Voici des faits concrets qui expliquent pourquoi « ajouter un autre MX » est rarement « simple ».

Les enregistrements MX ont été introduits pour découpler le routage mail des hostnames. Le routage initial du mail dépendait fortement des tables hosts et d’adressage direct ; MX a rendu ça plus flexible.
La préférence MX est volontairement simple. C’est un mécanisme d’ordre, pas un cadre de poids+santé comme les load balancers modernes.
Le fallback vers A/AAAA quand MX est absent fait toujours partie du comportement courant. C’est pourquoi les domaines « naked » reçoivent parfois du mail par accident.
Certains expéditeurs traitent les MX de même préférence comme un ensemble en rotation. Le but est la distribution, mais la distribution réelle dépend de l’implémentation et du cache.
Le « backup MX » était autrefois un pattern courant. Le store-and-forward avait du sens quand les liaisons étaient instables ; aujourd’hui c’est souvent une responsabilité à moins d’être contrôlé.
SMTP est construit autour des retries. Les échecs temporaires sont attendus ; les files et le backoff sont des fonctionnalités, pas des bugs.
Le TLS opportuniste a changé ce que « joignable » signifie. Un serveur peut accepter TCP/25 mais échouer la politique de livraison si TLS ou les vérifications de certificat sont appliquées par l’expéditeur.
L’adoption d’IPv6 a introduit de nouvelles asymétries. Un expéditeur peut préférer IPv6, et votre chemin v6 peut être « up » au niveau routage mais « down » en réalité (firewalls, rDNS, réputation).
Les grands providers appliquent des comportements au-delà des standards de base. Le throttling, la réputation et les heuristiques peuvent dominer ce que vous percevez comme « livraison ».

Où les conceptions multi-MX échouent en production

L’hypothèse séduisante mais fausse : « Un nombre plus élevé signifie standby »

Les gens publient MX 10 pour le primaire, MX 20 pour le standby, et supposent que le standby ne sera utilisé que si le primaire est down.
Ce n’est pas garanti. « Down » est ambigu : injoignable ? rejetant ? lent ? 4xx intermittent ? DNS stale ? IPv6 défaillant ?
Beaucoup d’expéditeurs essaieront le secondaire si le primaire est simplement lent ou présente des échecs intermittents.

Alors votre standby devient un chemin d’ingress de production sans le durcissement de production.
Il peut ne pas avoir la bonne configuration TLS, ou être dans un chemin de filtrage différent, ou ne pas être autorisé à envoyer des bounces correctement.

Préférence égale comme « load balancing » sans symétrie

Si vous publiez deux MX avec la même préférence, vous invitez la distribution de charge.
C’est acceptable seulement si les deux endpoints sont identiques opérationnellement du point de vue SMTP :
même posture anti-spam, mêmes limites de taux, même politique TLS, même identité de bannière, même routage interne, même capacité d’accepter pour tous les destinataires.

Dans le monde réel, un nœud est un peu plus vieux, un peu mal configuré, un peu moins surveillé.
Devinez d’où viennent la plupart de vos rebonds étranges.

Un « backup MX » qui accepte pour tout le monde devient un piège à spam

Mode d’échec classique : le backup MX accepte le courrier pour des domaines qu’il ne livre pas finalement, parce qu’il est configuré pour accepter inbound.
Pas un open relay dans le sens évident « envoyer n’importe où », mais dans le sens « accepter pour n’importe quel destinataire au moment SMTP, puis échouer ensuite ».
Les spammeurs adorent ça car cela masque la validité des destinataires et transfère la douleur à votre file.

Si votre backup MX n’a pas de validation des destinataires (ou ne peut pas l’effectuer parce qu’il n’a pas accès à l’annuaire), il doit être configuré extrêmement prudemment.
Sinon vous construisez une responsabilité avec une excellente disponibilité.

Erreurs DNS : MX pointant vers des IP, CNAMEs ou hostnames cassés

Les cibles MX doivent être des hostnames qui résolvent en enregistrements A et/ou AAAA. Elles ne peuvent pas être des adresses IP brutes.
Beaucoup de fournisseurs DNS vous laisseront taper n’importe quoi. Les expéditeurs SMTP ne le feront pas.

CNAME-at-MX est largement déconseillé et souvent rejeté par des validateurs. Certains resolvers le suivent ; certains systèmes le traitent comme une mauvaise configuration.
Vous ne voulez pas du « certains » quand l’écosystème mail global est le client.

Mise en cache négative et mythes de propagation

Quand vous « corrigez le DNS », vous ne réparez pas instantanément le mail. Les resolvers mettent en cache.
Certains mettent en cache trop longtemps. Certains ignorent votre TTL. Certains ont des réponses obsolètes à cause de resolvers intermédiaires.
Votre supervision peut montrer la bonne réponse tandis qu’un grand expéditeur voit encore l’ancienne.

Mode opératoire de diagnostic rapide

Quand la livraison de mail est étrange, ne commencez pas par toucher les numéros MX.
Commencez par trouver où la livraison échoue : réponse DNS, reachability TCP, dialogue SMTP, rejet de politique, ou comportement de file.

Premier point : confirmer ce que le monde voit (DNS, depuis plusieurs points de vue)

Interrogez MX et A/AAAA pour le domaine et pour chaque cible MX.
Vérifiez les TTL et si les réponses diffèrent entre resolvers.
Confirmez qu’il n’y a pas de CNAME sur la cible MX.

Deuxième point : tester TCP/25 et la bannière SMTP sur chaque cible MX (IPv4 et IPv6)

Les échecs rapides (refused) sont de bons signaux ; les timeouts tuent le débit.
Vérifiez firewall, routage, et blocages opérateur.
Confirmez le hostname correct et les capacités TLS si requis.

Troisième point : examiner l’acceptation serveur et le comportement des files

Rejetez-vous à la connexion, au HELO/EHLO, au MAIL FROM, ou au RCPT TO ?
Délayez-vous (4xx) à cause du greylisting, du rate limiting, d’un DNSBL, ou d’une politique ?
Votre « backup » met-il en file indéfiniment parce qu’il ne peut pas livrer en interne ?

Quatrième point : corréler avec les logs et les patterns des expéditeurs

Quelles IP distantes se connectent à quelle cible MX ?
Les grands providers utilisent-ils systématiquement le secondaire ?
Les échecs se regroupent-ils sur IPv6, une AZ, ou un hostname spécifique ?

Tâches pratiques : commandes, sorties et décisions

Voici les tâches que j’exécute réellement quand quelqu’un dit « le basculement MX ne fonctionne pas » ou « le mail est retardé ».
Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision à prendre.

Task 1: See the MX set as your resolver sees it

cr0x@server:~$ dig +nocmd example.com MX +noall +answer
example.com.        300     IN      MX      10 mx1.example.net.
example.com.        300     IN      MX      20 mx2.example.net.

Signification : La préférence 10 est essayée avant 20. Le TTL est de 300 secondes.

Décision : Si l’ensemble est incorrect, corrigez le DNS d’abord. S’il est correct, poursuivez ; les numéros MX seuls n’expliquent pas les « retards ».

Task 2: Check whether MX targets actually resolve (A and AAAA)

cr0x@server:~$ dig +nocmd mx1.example.net A mx1.example.net AAAA +noall +answer
mx1.example.net.    300     IN      A       203.0.113.10
mx1.example.net.    300     IN      AAAA    2001:db8:10::10

Signification : IPv4 et IPv6 sont publiés.

Décision : Si vous publiez AAAA, vous devez exploiter IPv6. Si IPv6 est cassé, corrigez-le ou cessez de l’annoncer.

Task 3: Detect a CNAME hiding behind an MX hostname

cr0x@server:~$ dig +nocmd mx2.example.net CNAME +noall +answer
mx2.example.net.    300     IN      CNAME   mail-gw.provider.example.

Signification : Votre hostname MX est un CNAME.

Décision : Remplacez par un nom A/AAAA directement. Certains expéditeurs échoueront ou traiteront cela comme une mauvaise configuration.

Task 4: Compare answers from different resolvers (spot propagation/caching issues)

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com.        300     IN      MX      10 mx1.example.net.
example.com.        300     IN      MX      20 mx2.example.net.

cr0x@server:~$ dig @8.8.8.8 example.com MX +noall +answer
example.com.        3600    IN      MX      5 oldmx.example.org.

Signification : Différents resolvers ne sont pas d’accord. L’un sert encore l’ancien MX avec un TTL plus long.

Décision : Attendez-vous à une coupure retardée. Gardez l’ancienne infrastructure active jusqu’à l’expiration des caches, ou réduisez le TTL bien avant les migrations.

Task 5: Verify TCP/25 reachability quickly (IPv4)

cr0x@server:~$ nc -vz -w 3 203.0.113.10 25
Connection to 203.0.113.10 25 port [tcp/smtp] succeeded!

Signification : Le port 25 est joignable et l’hôte écoute.

Décision : Si cela échoue, corrigez firewall/routage/blocages opérateur avant de toucher au DNS. Le « basculement » MX n’aidera pas si les deux sont bloqués.

Task 6: Verify TCP/25 reachability (IPv6)

cr0x@server:~$ nc -6 -vz -w 3 2001:db8:10::10 25
nc: connect to 2001:db8:10::10 port 25 (tcp) failed: No route to host

Signification : Le chemin IPv6 est cassé.

Décision : Si vous ne pouvez pas réparer IPv6 rapidement, retirez AAAA pour les hostnames MX (ou corrigez routage/firewall). Sinon certains expéditeurs resteront bloqués sur des timeouts.

Task 7: Check the SMTP banner and basic dialogue

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.net:25 -servername mx1.example.net -crlf
CONNECTED(00000003)
220 mx1.example.net ESMTP Postfix
EHLO test.example
250-mx1.example.net
250-STARTTLS
250 PIPELINING

Signification : Le serveur répond et propose STARTTLS. L’identité de la bannière semble cohérente.

Décision : Si STARTTLS échoue ou que la bannière est incorrecte (par ex. un hostname cloud générique), attendez-vous à des problèmes de réputation et de politique. Corrigez TLS et l’identité avant d’ajouter plus de MX.

Task 8: Ask which MX is chosen by your MTA (from a Linux host)

cr0x@server:~$ postconf -n | grep -E 'myhostname|mydestination|relayhost'
myhostname = app1.internal.example
mydestination = $myhostname, localhost.localdomain, localhost
relayhost =

Signification : Cet hôte livrera directement (pas de relayhost configuré).

Décision : Si vous aviez l’intention de relayer via un smart host, configurez relayhost. Sinon cette machine fait maintenant partie de votre surface de livraison de mail.

Task 9: Trace an outbound delivery decision (Postfix)

cr0x@server:~$ postmap -q example.com /etc/postfix/transport
smtp:

Signification : Aucun transport spécial ; utilisera les recherches MX SMTP normales.

Décision : Si vous devez forcer un saut suivant spécifique (par ex. éviter un MX cassé pendant un incident), utilisez une entrée temporaire dans transport map.

Task 10: Look for deferrals and why they happen (queue inspection)

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
7F2A51C02F     4210 Mon Jan  4 10:12:19  alerts@example.com
                                         (connect to mx1.example.net[203.0.113.10]:25: Connection timed out)
                                         user@example.com

-- 1 Kbytes in 1 Request.

Signification : L’expéditeur subit des timeouts vers le primaire. C’est le slow-fail, le pire type.

Décision : Corrigez la connectivité ou le firewall. Si vous ne pouvez pas, réduisez temporairement les settings de timeout (avec précaution) et assurez-vous que le secondaire est sain.

Task 11: Confirm which remote IPs are hitting which MX (log sampling)

cr0x@server:~$ sudo grep -E 'connect from' /var/log/mail.log | tail -n 5
Jan  4 10:15:01 mx2 postfix/smtpd[18422]: connect from mail-oi1-f170.google.com[209.85.167.170]
Jan  4 10:15:09 mx2 postfix/smtpd[18422]: connect from mta7.am0.yahoodns.net[67.195.228.94]
Jan  4 10:15:14 mx2 postfix/smtpd[18422]: connect from outbound.protection.outlook.com[40.92.72.65]
Jan  4 10:15:18 mx2 postfix/smtpd[18422]: connect from mail.example-sender.net[198.51.100.44]
Jan  4 10:15:22 mx2 postfix/smtpd[18422]: connect from unknown[192.0.2.55]

Signification : Les gros providers se connectent à mx2 (le « secondaire »).

Décision : Traitez mx2 comme de la production. S’il n’est pas équivalent à mx1, vous avez créé un split-brain des politiques d’acceptation.

Task 12: Test recipient acceptance at SMTP time (RCPT TO behavior)

cr0x@server:~$ swaks --to nonexistent-user@example.com --server mx2.example.net --timeout 10
=== Trying mx2.example.net:25...
=== Connected to mx2.example.net.
<-  220 mx2.example.net ESMTP Postfix
 -> EHLO client.example
<-  250-mx2.example.net
<-  250 PIPELINING
 -> MAIL FROM:<test@client.example>
<-  250 2.1.0 Ok
 -> RCPT TO:<nonexistent-user@example.com>
<-  250 2.1.5 Ok
 -> DATA
<-  554 5.7.1 Service unavailable; Client host blocked

Signification : mx2 accepte un destinataire invalide au RCPT time (250) mais échoue ensuite. C’est une recette pour du backscatter et la croissance des files.

Décision : Configurez la validation des destinataires (rejeter les utilisateurs inconnus au RCPT TO) ou assurez-vous que mx2 ne soit pas listé comme MX pour des domaines qu’il ne peut pas valider.

Task 13: Verify reverse DNS for the MX IPs (reputation basics)

cr0x@server:~$ dig +short -x 203.0.113.10
mx1.example.net.

Signification : Le PTR correspond au hostname utilisé dans l’identité SMTP.

Décision : Si le PTR manque ou est générique, corrigez-le. Certains récepteurs traitent le rDNS mismatched comme un signal de confiance et throttleront ou rejetteront.

Task 14: Check SPF alignment for inbound gateways that might generate bounces

cr0x@server:~$ dig +short example.com TXT
"v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"

Signification : Seules ces IPs sont autorisées à envoyer au nom de example.com.

Décision : Si votre « secondaire » envoie des mails qui prétendent provenir de votre domaine (y compris les DSN), assurez-vous que SPF (et DKIM/DMARC le cas échéant) ne provoquent pas de rejets.

Task 15: Confirm DMARC policy (to predict how strict receivers will be)

cr0x@server:~$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com"

Signification : Politique stricte ; les mails mal alignés sont rejetés.

Décision : Si vous routez le mail via des gateways différentes, maintenez les signatures/alignements cohérents. Sinon certains chemins échoueront et sembleront « aléatoires ».

Task 16: Spot SMTP timeouts vs refusals (kernel counters can hint)

cr0x@server:~$ sudo ss -tn state syn-sent '( dport = :25 )' | head
State    Recv-Q   Send-Q     Local Address:Port      Peer Address:Port
SYN-SENT 0        1          10.0.0.15:45822         203.0.113.10:25
SYN-SENT 0        1          10.0.0.15:45824         203.0.113.10:25

Signification : De nombreuses connexions SYN-SENT indiquent des timeouts ou des paquets filtrés, pas des rejets au niveau application.

Décision : Examinez les règles de firewall et le filtrage en amont. Si vous voyez des accumulations SYN-SENT, changer la préférence MX ne servira à rien.

Trois mini-histoires d’entreprise (anonymisées mais douloureusement réelles)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse (« Standby signifie inutilisé »)

Une entreprise de taille moyenne gérait son inbound sur une paire de MTA dans deux centres de données différents. MX 10 pointait vers le primaire.
MX 20 pointait vers un serveur « backup » qui n’avait pas été touché depuis des mois parce qu’il était « seulement pour les urgences ».
L’équipe se sentait rassurée. Deux MX ! Résilience acquise ! Ils ont même dit à la direction que c’était « actif-passif ».

Puis un changement de firewall a introduit une perte de paquets intermittente vers le DC primaire. Pas une panne — juste assez de SYN/ACK perdus pour provoquer des timeouts.
Certains expéditeurs ont réessayé et ont finalement atteint le secondaire. D’autres ont mis en file pendant des heures avant d’essayer le secondaire.
Quelques-uns ont abandonné après l’expiration de leur politique de retry. Le symptôme ressemblait à du courrier aléatoirement manquant. C’est le pire type d’incident.

Le backup MTA fonctionnait avec une configuration plus ancienne qui n’appliquait pas la validation des destinataires au RCPT time.
Il acceptait les mails pour des destinataires mal tapés, puis échouait la livraison en interne. Le disque de la file s’est rempli. Puis il a commencé à échouer aussi pour du courrier légitime.
Pendant ce temps, le primaire était « majoritairement up », donc la supervision n’alertait pas jusqu’à ce que les humains interviennent.

La correction a été brutalement ennuyeuse : rendre les deux MTA équivalents, ajouter des contrôles de destinataire appropriés, aligner les politiques et TLS, et surveiller la deliverability, pas seulement l’uptime des processus.
Ils ont aussi appris à traiter les timeouts comme des événements de gravité un. Les refus échouent vite ; les timeouts échouent lentement et volent votre débit.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux (« Préférence égale pour load-balance »)

Une autre organisation voulait réduire la charge entrante sur une seule passerelle. Ils ont publié deux MX à préférence 10.
Ils s’attendaient à un split 50/50 propre et se sont félicités d’avoir évité un load balancer.
Distribution via DNS ! Classique.

Ça a plutôt bien marché — jusqu’à ce que ça ne marche plus. Une passerelle avait une configuration TLS un peu plus stricte : ciphers plus récents, chaîne de certificats différente, comportement de handshake légèrement différent.
Un sous-ensemble de stacks expéditeurs plus anciens a échoué la négociation STARTTLS et est retombé sur du plaintext — ou a échoué complètement selon leur politique.
Soudain, « certains partenaires ne peuvent pas nous envoyer de mails » est devenu un ticket récurrent.

Pire, le filtrage anti-spam n’était pas identique. Une passerelle apprenait plus vite (plus de CPU, règles plus récentes), donc les spammeurs ont migré vers la plus faible.
La réputation de l’IP de cette passerelle s’est dégradée, ce qui a ralenti le courrier légitime de certains providers à cause du throttling.
Tout le monde a blâmé le DNS parce que c’était ce qui avait changé. Le DNS était innocent ; l’asymétrie était coupable.

Ils sont finalement passés à un modèle où les deux cibles MX étaient vraiment identiques en politique et cadence de patch, et ils ont validé l’interopérabilité TLS en staging.
Les MX de préférence égale ne sont pas « mauvais ». Les endpoints inégaux derrière des MX de préférence égale le sont.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée (« Conserver l’ancien MX, baisser le TTL tôt »)

Une grande entreprise est passée d’une passerelle on-premise à un service de sécurité mail hébergé.
Le plan de migration n’était pas glamour. C’était une checklist : baisser le TTL des MX quelques jours à l’avance, publier le nouveau MX avec une préférence plus élevée en premier, vérifier l’acceptation,
puis permuter les préférences pendant une fenêtre calme. Garder l’ancienne passerelle en ligne pendant toute la période d’évaporation des caches.

Pendant la bascule, un problème inattendu sur un resolver DNS régional a fait que certains clients recevaient des réponses MX obsolètes.
Logiquement, ces clients ont continué à envoyer au vieil équipement. Mais la vieille passerelle était toujours en service, acceptait et routait vers le nouveau service.
Personne n’a remarqué côté business. C’est le meilleur résultat : invisiblement correct.

L’équipe avait aussi une supervision ennuyeuse et efficace : des tests SMTP synthétiques vers chaque cible MX, suivant la latence de connexion et le succès de STARTTLS.
Quand le service hébergé a eu un bref épisode de rate-limiting, les checks synthétiques ont vu des 4xx augmenter immédiatement.
L’équipe a coordonné avec le fournisseur et ajusté temporairement leurs propres throttles entrants.

Personne n’a reçu de trophée. Mais personne n’a été réveillé à 3h du matin non plus, ce qui est la chose la plus proche d’un trophée pour les opérations.

Blague #2 : « C’est juste du DNS » est l’équivalent email de « c’est juste un petit changement ». Les deux expressions vieillissent mal.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: Some senders deliver to secondary even when primary is “up”

Cause racine : Le primaire est lent ou subit des timeouts intermittents ; les expéditeurs basculent selon leur logique de retry. Peut aussi être IPv6 cassé sur le primaire.

Correctif : Éliminez les timeouts. Vérifiez la joignabilité TCP, les SYN-SENT, les drops de firewall, et IPv6. Assurez-vous que le primaire échoue vite quand il est malade (ou retirez les chemins cassés).

2) Symptom: Mail is delayed for hours, then arrives in bursts

Cause racine : Les expéditeurs mettent en file à cause d’erreurs transitoires (4xx) ou de timeouts. Votre « basculement » MX se produit, mais sur un schedule de retry long.

Correctif : Trouvez l’étape SMTP exacte qui renvoie du 4xx. Corrigez les rate limits, le greylisting, les triggers DNSBL, ou le filtrage en amont. Réduisez les blocages causés par les timeouts.

3) Symptom: Random bounces referencing one MX hostname

Cause racine : Configuration inégale entre les cibles MX (TLS, anti-spam, exigences d’auth, validation des destinataires, ou routage en aval).

Correctif : Rendre les cibles MX symétriques ou retirer la plus faible. Si vous ne pouvez pas les rendre équivalentes, ne les annoncez pas de façon égale (ou pas du tout).

4) Symptom: Mail loops or “relaying denied” from the secondary

Cause racine : Le secondaire n’est pas configuré pour accepter le mail pour le domaine, ou ne peut pas router vers la destination interne. Arrive souvent avec un « backup MX » qui ne connaît pas vos domaines.

Correctif : Assurez-vous que le secondaire est auteur pour le domaine destinataire et dispose des routes de transport correctes. Validez avec des tests SMTP RCPT et une livraison bout en bout.

5) Symptom: “Host not found” bounces after an MX change

Cause racine : Le hostname cible MX n’a pas d’A/AAAA, a été mal saisi, ou repose sur une chaîne CNAME qui casse chez certains resolvers.

Correctif : Publiez des A/AAAA directs pour les cibles MX ; retirez le CNAME-at-MX ; vérifiez avec dig depuis plusieurs resolvers.

6) Symptom: Delivery failures only from IPv6-capable senders

Cause racine : AAAA existe mais le chemin IPv6 est cassé (routage, firewall, NAT64 étrange, blocages opérateur) ou le reverse DNS manque pour IPv6.

Correctif : Soit exploitez pleinement IPv6 (connectivité, rDNS, réputation), soit ne publiez pas AAAA pour les hosts MX.

7) Symptom: Increased spam after adding a backup MX

Cause racine : Le backup MX accepte des destinataires invalides (pas de validation au RCPT TO), devenant une cible attractive et un fardeau de file.

Correctif : Rejetez les destinataires invalides au RCPT time, ou assurez-vous que le backup MX a accès aux maps d’annuaire / destinataires. Ajoutez des contrôles de relais stricts et de la supervision.

8) Symptom: “Works in our tests” but partners report failures

Cause racine : Vous avez testé depuis un seul réseau/resolver. Les partenaires frappent d’autres resolvers, ont des réponses en cache, des stacks TLS différents, ou des contraintes de politique.

Correctif : Testez depuis plusieurs réseaux et resolvers. Validez l’interopérabilité TLS et le dialogue SMTP. Supervisez depuis des probes externes, pas seulement en interne.

Listes de contrôle / plan étape par étape

Checklist : concevoir plusieurs enregistrements MX (ce qu’il faut faire, pas ce qu’il faut espérer)

Décidez l’intention : distribution (préférence égale) ou ordre de préférence (primaire/secondaire). Ne mélangez pas les narratifs.
Faites de chaque MX annoncé une cible de qualité production : patchs, supervision, capacité, logs, backups, et ownership on-call.
Maintenez la politique cohérente : TLS, politique de ciphers, anti-spam, rate limiting, validation des destinataires, et identité de bannière.
Exploitez IPv6 délibérément : publiez AAAA seulement si vous avez testé reachability, rDNS et les chemins firewall.
Fixez des TTL sensés : baissez le TTL bien avant les migrations planifiées ; évitez les changements de TTL frénétiques le même jour.
Évitez le CNAME-at-MX : publiez A/AAAA directement pour le hostname MX.
Planifiez la mise en file : comprenez que le basculement peut signifier une livraison différée. Communiquez ceci aux parties prenantes.
Validez bout en bout : testez l’acceptation SMTP et le routage interne, pas seulement « le port est ouvert ».

Step-by-step : cutover MX sans drame (édition minimaliste)

T-7 jours : Baissez le TTL des MX (par ex. 3600 → 300). Laissez l’ancien TTL suffisamment longtemps pour propager en sécurité.
T-3 jours : Mettez le nouveau MX en ligne. Assurez-vous qu’il peut accepter le mail pour le domaine et livrer en interne.
T-2 jours : Publiez le nouveau MX avec une préférence plus élevée (comme canary). Exemple : MX existant 10, nouveau MX 20.
T-2 à T-1 jours : Observez les logs. Confirmez qui se connecte au nouveau MX et que les messages se livrent correctement.
T-0 : Intervertissez les préférences (le nouveau devient le numéro le plus bas). Gardez l’ancien MX en ligne avec la préférence plus élevée.
T+1 jour : Poursuivez la surveillance depuis plusieurs resolvers et checks SMTP synthétiques.
T+fenêtre d’expiration des caches : Retirez l’ancien MX seulement après être sûr que les resolvers obsolètes ne l’alimentent plus en trafic.

Checklist : « backup MX » fait correctement (rare, mais possible)

La validation des destinataires est non négociable : rejetez les destinataires inconnus au RCPT time.
Limites store-and-forward : plafonnez la croissance de la file ; alertez tôt ; assurez l’espace disque et la marge I/O.
Contrôles de relais stricts : ne le laissez jamais devenir un relais à usage général.
Politique cohérente : même posture TLS et filtrage que le primaire pour éviter la dérive de réputation.
Ownership opérationnel : supervisé, patché, testé et inclus dans les exercices d’incident.

FAQ

1) Does a lower MX number guarantee senders will always use that server?

Non. C’est un ordre de préférence, pas un mécanisme d’application. Les expéditeurs peuvent mettre en cache d’anciennes réponses, appliquer leurs propres politiques,
et basculer quand l’hôte préféré est lent, en timeout, ou rejette transitoirement.

2) If my primary MX is down, will mail immediately go to the secondary?

Parfois. Si « down » se traduit par des échecs rapides (connection refused), beaucoup d’expéditeurs essaieront rapidement le MX suivant.
Si « down » ressemble à des timeouts, ils peuvent brûler du temps par tentative puis mettre en file et réessayer plus tard, entraînant des délais.

3) Should I set equal MX preference values for load balancing?

Seulement si les deux endpoints sont équivalents opérationnellement et politiquement. La préférence égale signifie « n’importe lequel fait l’affaire ».
Si l’un est plus faible, vous aurez des pannes partielles étranges qui semblent aléatoires.

4) Can an MX record point directly to an IP address?

Non. Les cibles MX doivent être des hostnames qui résolvent en IP via A/AAAA.
Si vous avez besoin d’un contrôle d’acheminement direct par IP, vous cherchez un outil autre que MX.

5) Is it okay for an MX target to be a CNAME?

C’est largement déconseillé et provoque des problèmes d’interopérabilité. Certains systèmes suivent le CNAME ; d’autres le considèrent invalide ou se comportent de façon incohérente.
Publiez A/AAAA directement pour le hostname MX.

6) How many MX records should I publish?

Deux est courant. Plus de trois aide rarement et augmente souvent la surface de mauvaise configuration.
Chaque MX que vous publiez doit être maintenu comme s’il recevait du vrai trafic — parce qu’il le fera.

7) Can I use a “backup MX” that only stores mail and forwards later?

Vous pouvez, mais il doit valider les destinataires (sinon vous accepterez des junk que vous ne pouvez pas livrer), et il doit être sécurisé et supervisé.
Beaucoup d’organisations modernes préfèrent utiliser un service de sécurité inbound réputé plutôt que de gérer leur propre store-and-forward.

8) Why do I see mail hitting my secondary MX even when everything is healthy?

Parce que certains expéditeurs distribuent sur une préférence égale, à cause de caches DNS, heuristiques de l’expéditeur qui préfèrent un certain chemin,
ou parce que votre primaire échoue parfois lentement (timeouts), poussant des retries vers le secondaire.

9) Do TTL changes take effect immediately?

Les changements de TTL n’affectent que les caches qui interrogent après le changement. Les resolvers qui ont mis en cache l’ancien enregistrement le conserveront jusqu’à expiration,
et certains resolvers intermédiaires se comportent mal. Planifiez les réductions de TTL à l’avance.

10) Does MX priority influence outbound mail from my domain?

Pas directement. MX sert au routage inbound vers votre domaine. L’outbound est dirigé par la configuration de votre MTA, les settings relayhost, et le routage des providers.
Les gens confondent cela constamment, surtout pendant les migrations.

Conclusion : prochaines étapes à effectuer aujourd’hui

Les enregistrements MX multiples ne sont pas une case magique de redondance. Ils sont un contrat publié avec le monde :
« Voici les portes que vous pouvez utiliser pour nous livrer du mail. » Chaque porte doit s’ouvrir de façon fiable.

Étapes pratiques :

Inventoriez votre jeu MX et vérifiez que chaque cible résout (A/AAAA) et répond sur TCP/25 depuis l’extérieur de votre réseau.
Si vous publiez IPv6, testez la joignabilité SMTP IPv6 et le rDNS. Si vous ne pouvez pas l’exploiter, cessez de l’annoncer.
Rendez vos endpoints MX identiques en politique : comportement TLS, validation des destinataires, anti-spam, et routage en aval.
Créez un petit monitor synthétique : connectez-vous, lisez la bannière, envoyez EHLO, tentez STARTTLS, et enregistrez la latence. Alertez sur les timeouts et la hausse des 4xx.
Pour les changements futurs, baissez le TTL tôt et gardez l’ancien MX actif suffisamment longtemps pour que les caches expirent.

Faites cela, et la « priorité MX » deviendra un outil utile au lieu d’un mystère récurrent.