Email : TTL lors d’une migration — l’astuce simple qui évite les interruptions

janvier 2, 2026 • février 3, 2026 • Lecture : 29 min • Views: 9

Cet article vous a aidé ?

Les migrations de messagerie n’échouent généralement pas parce que la synchronisation IMAP a été lente ou parce que quelqu’un a mal lu un assistant fournisseur.
Elles échouent parce que le courrier continue d’arriver à l’ancien emplacement après que vous avez « basculé », ou pire : la moitié du monde va vers l’ancien,
l’autre moitié vers le nouveau, et vous découvrez ce que signifie la distribution fragmentée à 2 h du matin.

La solution est ennuyeuse, fiable et absolument non optionnelle : contrôlez la mise en cache DNS avec le TTL avant de basculer.
Vous ne pouvez pas éliminer la propagation, mais vous pouvez la rendre courte, mesurable et réversible.

TTL en une phrase (et pourquoi c’est important pour les e‑mails)

Le TTL (Time To Live) indique combien de temps une réponse DNS peut être mise en cache avant que le résolveur doive redemander.
Lors d’une migration de messagerie, le TTL détermine combien de temps les expéditeurs continueront d’utiliser les anciens enregistrements MX après que vous les ayez modifiés.

Cela paraît simple parce que ça l’est. C’est aussi l’un des rares leviers de migration que vous pouvez actionner des semaines à l’avance,
sans toucher aux serveurs de messagerie.

La vérité opérationnelle est la suivante : un basculement n’est pas le moment où vous changez le DNS ; c’est le moment où suffisamment de résolveurs
cessent de croire l’ancienne réponse. Le TTL est le calendrier que vous remettez à Internet.

Ce qui casse réellement lors des basculements d’e‑mail

1) Distribution fragmentée (la catastrophe silencieuse)

Certains expéditeurs résolvent votre MX vers l’ancien fournisseur. D’autres résolvent vers le nouveau fournisseur. Les deux acceptent le courrier.
Les utilisateurs signalent des messages « manquants », et les deux ont raison. Le courrier est livré. Juste pas au même endroit.

Si vous prévoyez une coexistence, la distribution fragmentée peut être planifiée. La plupart des équipes ne le sont pas.
La plupart créent cela par accident et l’appellent « intermittent ».

2) Backscatter et nouvelles tentatives qui ressemblent à des pertes

SMTP est un système de stockage et de retransmission. Les expéditeurs réessaient en cas d’échecs transitoires.
Quand vous changez les MX et qu’il y a un mauvais paramétrage (TLS, réputation d’IP, greylisting, pare‑feu),
vous pouvez obtenir un arriéré de tentatives qui arrivent plus tard. Les utilisateurs appellent ça « perdu », puis le message arrive à 15 h.

3) Désalignement des authentifications (SPF/DKIM/DMARC)

Changer d’endroit d’envoi est souvent lié à changer d’endroit de réception.
Si le nouveau fournisseur signe DKIM différemment, ou si vous envoyez depuis de nouvelles IP sans mettre à jour SPF,
vous pouvez réussir la livraison mais perdre la confiance. Cela signifie dossier spam, pas panne. En pratique, c’est une panne.

4) Hypothèses trop confiantes sur la « propagation DNS »

Les équipes traitent le DNS comme un brouillard magique de cohérence éventuelle. Ce n’est pas du brouillard. Ce sont des caches avec des règles.
Les règles sont mesurables. Si vous ne les mesurez pas, vous ne migrez pas ; vous jouez.

Blague n°1 : la propagation DNS, c’est comme « attendre que l’internet se mette à jour »—ce qui est adorable jusqu’à ce que vous réalisiez qu’Internet ne prend pas de tickets.

Faits intéressants et un peu d’histoire (pour arrêter de deviner)

Le DNS est plus ancien que la plupart des fournisseurs SaaS de messagerie. Le système de noms de domaine a été conçu au début des années 1980 pour remplacer la distribution de HOSTS.TXT à grande échelle. Le courrier s’y est appuyé, et c’est toujours le cas.
Les enregistrements MX existent parce que SMTP avait besoin d’indirection. Le routage ancien du courrier avait besoin d’un moyen de dire « le courrier pour ce domaine va là », pas « l’enregistrement A de ce domaine est le serveur de mails ». MX a formalisé cela.
Le TTL n’est pas nouveau ; ce qui a changé, c’est le comportement des caches. Les résolveurs récursifs modernes, les résolveurs ISP et les caches d’entreprise conservent agressivement les réponses, et certains ajoutent des comportements « utiles » comme le préfetching.
La mise en cache négative existe. Les réponses NXDOMAIN peuvent être mises en cache selon les valeurs SOA de la zone, donc « on va ajouter cet enregistrement plus tard » peut encore vous nuire pendant un certain temps.
SMTP a été conçu pour les réessais, pas pour la livraison instantanée. La file et le réessai expliquent pourquoi le courrier est résilient… et pourquoi les erreurs de migration peuvent mettre des heures à se manifester.
Certains expéditeurs conservent les résultats plus longtemps que prévu. Alors que les résolveurs devraient respecter le TTL, certains environnements conservent effectivement les réponses en raison d’acheminements internes, de caches politiques ou de comportements stales des recursors.
Les agents de transfert de mails utilisent l’ordre de préférence MX. La valeur de préférence la plus basse gagne. Un mauvais ordre peut faire passer le courrier silencieusement vers un endroit « valide » mais incorrect.
Les TTL longs étaient historiquement utilisés pour réduire la charge DNS. À l’époque où la bande passante et le CPU coûtaient cher, les administrateurs mettaient des TTL de plusieurs heures pour éviter que les résolveurs n’inondent les serveurs faisant autorité.
Les migrations d’e‑mail sont devenues plus difficiles quand l’authentification s’est renforcée. SPF (années 2000), DKIM (fin des années 2000) et DMARC (années 2010) ont amélioré la confiance mais augmenté le nombre d’éléments mobiles pendant le basculement.

L’« astuce simple » : mise en scène du TTL pour éviter les interruptions

Vous ne devez pas « simplement baisser le TTL quand vous êtes prêt ». C’est l’erreur classique. Baisser le TTL n’aide qu’après que
le nouveau TTL a eu le temps de remplacer les anciennes réponses mises en cache. Si votre MX a un TTL de 3600 secondes et que vous le baissez à 300
secondes à midi, un résolveur qui a mis en cache à 11:59 a toujours le droit de croire la réponse à 3600 secondes jusqu’à 12:59.

L’astuce consiste à planifier les changements de TTL de sorte que, le jour du basculement, Internet soit déjà habitué à vérifier plus fréquemment.
Alors votre basculement MX devient une fenêtre courte au lieu d’un mystère de plusieurs heures.

Le schéma de base

Jours avant le basculement : abaissez le TTL sur les MX (et tous les enregistrements liés que vous modifierez) à quelque chose comme 300 secondes.
Attendez au moins l’ancien TTL + marge de sécurité (je préfère 2× l’ancien TTL si possible) afin que les caches se rafraîchissent naturellement.
Basculement : changez les MX vers le nouveau fournisseur pendant que le TTL est bas.
Après stabilisation : remontez le TTL à une valeur raisonnable (souvent 1800–3600 secondes) pour réduire le volume de requêtes et le bruit.

Quels enregistrements mettre en scène (la plupart des équipes en oublient au moins un)

Le MX est la vedette, mais les migrations de messagerie touchent une petite constellation de DNS. Mettez en scène le TTL pour tout ce que vous changerez pendant la fenêtre :

MX (évident)
A/AAAA pour les noms d’hôtes de mail référencés par les MX (parfois le fournisseur vous donne des noms que vous ne contrôlez pas ; parfois si)
TXT pour les changements SPF (si vous changez l’outbound)
TXT pour les enregistrements DKIM des sélecteurs (si vous les faites tourner ou ajouter)
TXT pour DMARC (si vous durcissez la politique après migration)
CNAME pour les points d’accès autodiscover/autoconfig (la douleur côté client reste de la douleur)
SRV dans certains environnements d’entreprise (moins courant, mais ne présumez pas)

Quel est un « TTL bas » ?

300 secondes (5 minutes) est la valeur de référence. 60 secondes est tentant mais souvent inutile : tous les résolveurs ne se comportent pas mieux à 60 qu’à 300, et vous augmentez le volume de requêtes et le risque de limitation de débit ou du bruit dans les logs.
Si votre fournisseur DNS est instable, un TTL trop bas peut amplifier l’instabilité en une panne visible.

Ce que le TTL ne résout pas

Le TTL réduit le temps que met le monde à remarquer vos nouveaux enregistrements. Il ne :

Ne force pas un expéditeur à réessayer immédiatement.
Ne corrige pas les problèmes de pare‑feu ou d’accessibilité du port 25.
Ne répare pas l’alignement SPF/DKIM.
Ne déplace pas magiquement le courrier déjà livré vers l’ancien mailbox.

Une citation à garder sur un pense‑bête

Everything fails all the time. — Werner Vogels

Traitez le basculement MX comme une panne que vous planifiez pour survivre. La mise en scène du TTL est votre gain de résilience le plus simple.

Calendriers qui fonctionnent : T‑7 jours à T+2 jours

Voici un calendrier de migration qui suppose que vous changez le routage entrant (basculement MX) et éventuellement l’outbound.
Adaptez les jours à votre organisation, mais respectez l’ordre. La messagerie punit l’improvisation.

T‑7 à T‑3 jours : rendre le DNS ennuyeux

Inventoriez les TTL actuels pour les MX et les enregistrements liés.
Baissez les TTL à 300 secondes pour les enregistrements que vous allez changer.
Confirmez que le DNS faisant autorité sert bien le nouveau TTL (ne vous fiez pas à l’interface).
Exécutez une vérification « pré‑basculement » depuis plusieurs résolveurs (votre ISP, des résolveurs publics, des recursors d’entreprise).

T‑2 à T‑1 jours : vérifier que la nouvelle réception accepte le courrier

Confirmez que le SMTP entrant fonctionne vers le nouveau fournisseur (domaines de test, utilisateurs pilotes, ou MX alternatifs).
Confirmez les réglages anti‑spam, TLS, règles de connecteurs, et listes d’autorisation/blacklists entrantes.
Préparez le rollback : les anciens enregistrements MX prêts à être restaurés, et confirmez que l’ancien côté peut toujours accepter le courrier.

T‑0 jour : basculement, observation, et pas de panique

Changez les MX.
Surveillez le flux entrant et le comportement des files des deux côtés.
Confirmez les résultats d’authentification (SPF/DKIM/DMARC) sur des messages réels.
Suivez le trafic tardif qui arrive encore sur l’ancien système ; décidez de transférer, relayer ou récupérer.

T+1 à T+2 jours : stabiliser et remonter le TTL

Remontez le TTL à 1800–3600 secondes une fois que vous êtes confiants.
Poursuivez la surveillance des réessais et du courrier différé.
Désactivez l’ancien flux entrant progressivement, pas immédiatement, sauf si le risque l’exige.

Playbook de diagnostic rapide

Quand le message inévitable « la messagerie est en panne » arrive, vous avez besoin d’une méthode rapide pour localiser le goulot d’étranglement.
Ne commencez pas par argumenter sur la propagation DNS. Commencez par réduire le périmètre affecté.

Première étape : est‑ce le DNS, la connectivité SMTP, ou la politique d’acceptation ?

Vérifiez quel MX le monde voit depuis au moins deux résolveurs indépendants.
Vérifiez si la destination accepte TCP/25 et répond avec une bannière SMTP.
Vérifiez si le serveur accepte un message de test (même juste MAIL FROM/RCPT TO).

Deuxième étape : le courrier est‑il livré ailleurs ?

Cherchez dans les logs/queues de l’ancien système les réceptions récentes.
Vérifiez la trace de messages du nouveau système pour les tentatives de livraison.
Cherchez des rebonds et des messages différés dans les logs des expéditeurs (si internes) ou dans les en‑têtes de rebond fournis par les utilisateurs.

Troisième étape : l’authentification cause‑t‑elle une « panne douce » ?

Vérifiez que le SPF inclut les bons systèmes d’envoi.
Vérifiez la signature DKIM et l’exactitude du sélecteur.
Vérifiez que la politique DMARC ne rejette pas du nouveau courrier légitime.

Quatrième étape : quelque chose met‑il en cache plus longtemps que le TTL ?

Vérifiez les forwarders/recursors d’entreprise pour des données obsolètes.
Vérifiez si des appliances de sécurité en amont filtrent/ mettent en cache le DNS.
Décidez s’il faut contourner temporairement par des vidages de cache locaux pour des applications critiques (rare, mais parfois nécessaire).

Tâches pratiques : commandes, sorties et décisions (12+)

La différence entre une migration calme et un gros incident tient souvent à la capacité de répondre vite à des questions simples :
« Quel MX est actif ? », « Qui met quoi en cache ? », « Le port 25 est‑il joignable ? », « Rejetons‑nous le courrier pour des raisons de politique ? »
Voici des tâches pratiques que vous pouvez exécuter depuis une machine Linux avec des outils courants.

Task 1: Query current MX and TTL from your default resolver

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

Ce que cela signifie : Le TTL est de 3600 secondes. Beaucoup de résolveurs peuvent conserver cette réponse jusqu’à une heure après mise en cache.

Décision : Si le basculement est prévu dans la journée, vous êtes en retard. Baissez le TTL maintenant et acceptez une transition plus longue, ou replanifiez.

Task 2: Query authoritative nameservers directly (bypass caches)

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

Ce que cela signifie : L’autorité sert maintenant le TTL 300. Les caches convergeront au fur et à mesure que leurs anciens TTL expireront.

Décision : Notez l’heure du changement. Le basculement sûr le plus tôt possible est après l’expiration de l’ancien TTL + marge.

Task 3: Compare different public resolvers (real propagation, not vibes)

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "== $r =="; dig +noall +answer example.com MX @$r; done
== 1.1.1.1 ==
example.com.        3600    IN      MX      10 mx1.oldmail.example.net.
example.com.        3600    IN      MX      20 mx2.oldmail.example.net.
== 8.8.8.8 ==
example.com.        300     IN      MX      10 mx1.oldmail.example.net.
example.com.        300     IN      MX      20 mx2.oldmail.example.net.
== 9.9.9.9 ==
example.com.        1800    IN      MX      10 mx1.oldmail.example.net.
example.com.        1800    IN      MX      20 mx2.oldmail.example.net.

Ce que cela signifie : Différents résolveurs ont mis en cache à différents moments. C’est normal et c’est précisément la raison pour laquelle la mise en scène du TTL est importante.

Décision : Ne basculez pas tant que les grands résolveurs n’affichent pas de manière cohérente le TTL bas, sauf si vous pouvez tolérer la distribution fragmentée.

Task 4: Confirm what hostnames the MX records point to (and whether you control their DNS)

cr0x@server:~$ dig +noall +answer mx1.oldmail.example.net A
mx1.oldmail.example.net. 300 IN A 203.0.113.10

Ce que cela signifie : La cible MX se résout en une IP avec TTL 300. Si cet enregistrement est dans une zone fournisseur que vous ne contrôlez pas, vous ne pouvez pas mettre en scène son TTL.

Décision : Si vous le contrôlez, mettez‑le en scène. Sinon, acceptez que le fournisseur assume ce risque.

Task 5: Check for “dangling” MX targets (a classic cutover foot-gun)

cr0x@server:~$ dig +noall +answer mx-new.example.com A

Ce que cela signifie : Aucune réponse. Si vous pointez un MX vers un nom qui ne se résout pas, les expéditeurs mettront en file et réessaieront, et les utilisateurs diront que le mail est mort.

Décision : Ne basculez pas. Corrigez le DNS d’abord. Vérifiez aussi le timing du cache négatif via le SOA.

Task 6: Check SOA values to understand negative caching behavior

cr0x@server:~$ dig +noall +answer example.com SOA
example.com. 3600 IN SOA ns1.dnsprovider.net. hostmaster.example.com. 2026010401 7200 900 1209600 300

Ce que cela signifie : Le dernier champ (300) est le TTL de mise en cache négative dans de nombreuses implémentations.

Décision : Si vous êtes sur le point d’ajouter des enregistrements manquants, attendez‑vous à ce que NXDOMAIN persiste jusqu’à cette valeur après que les caches l’ont vue.

Task 7: Validate SMTP reachability to the new MX host (TCP/25)

cr0x@server:~$ nc -vz mx1.newmail.example.net 25
Connection to mx1.newmail.example.net 25 port [tcp/smtp] succeeded!

Ce que cela signifie : Le chemin réseau est ouvert. Cela ne prouve pas l’acceptation, mais cela lève le premier obstacle.

Décision : Si cela échoue, corrigez le pare‑feu/groupes de sécurité cloud/routage avant de toucher aux MX.

Task 8: Check the SMTP banner and basic handshake

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx1.newmail.example.net:25 -servername mx1.newmail.example.net
CONNECTED(00000003)
---
220 mx1.newmail.example.net ESMTP ready
...
250-STARTTLS
250 SIZE 52428800

Ce que cela signifie : Le serveur parle SMTP et propose STARTTLS. Vous avez la preuve qu’il est vivant et relativement moderne.

Décision : Si STARTTLS est requis par la politique, assurez‑vous qu’il est proposé et que les certificats valident dans votre environnement.

Task 9: Do a minimal SMTP transaction to validate acceptance policy

cr0x@server:~$ printf "EHLO test.example\r\nMAIL FROM:<probe@example.org>\r\nRCPT TO:<postmaster@example.com>\r\nDATA\r\nSubject: smtp probe\r\n\r\nhello\r\n.\r\nQUIT\r\n" | nc -w 5 mx1.newmail.example.net 25
220 mx1.newmail.example.net ESMTP ready
250-mx1.newmail.example.net
250 PIPELINING
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF;
250 2.0.0 Queued
221 2.0.0 Bye

Ce que cela signifie : Le nouveau système accepte le courrier pour votre domaine et le met en file pour livraison. C’est le cœur du « entrant fonctionne ».

Décision : Si RCPT TO est rejeté, corrigez la vérification du domaine, les domaines acceptés, les règles de routage ou les réglages anti‑spam.

Task 10: Check SPF record content before and after outbound changes

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.oldprovider.example -all"

Ce que cela signifie : SPF autorise actuellement uniquement l’ancien fournisseur.

Décision : Si l’outbound va changer, ajoutez l’include du nouvel expéditeur ou les IP avant que les utilisateurs commencent à envoyer depuis la nouvelle plateforme.

Task 11: Confirm DKIM selector records exist (common “it worked in the wizard” trap)

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ce que cela signifie : L’enregistrement du sélecteur est présent dans le DNS. Sans lui, les destinataires ne peuvent pas vérifier vos signatures.

Décision : Si il manque, n’activez pas encore les politiques « DKIM requis » ou DMARC strict. Corrigez le DNS d’abord.

Task 12: Confirm DMARC policy (to avoid self-inflicted rejection)

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

Ce que cela signifie : Alignement strict et politique de rejet. Pendant la migration, cela peut transformer de petites dérives d’authentification en échec dur.

Décision : Si vous changez l’outbound ou DKIM, envisagez d’assouplir temporairement en p=quarantine ou les modes d’alignement jusqu’à stabilisation.

Task 13: Verify what MX is currently being used by an MTA via DNS lookup trace

cr0x@server:~$ dig +trace example.com MX
; <<>> DiG 9.18.24 <<>> +trace example.com MX
.                       518400  IN      NS      a.root-servers.net.
...
example.com.            300     IN      MX      10 mx1.newmail.example.net.
example.com.            300     IN      MX      20 mx2.newmail.example.net.

Ce que cela signifie : Le trace montre la chaîne d’autorité et les réponses MX finales. Si c’est correct mais que certains clients voient encore l’ancien MX, c’est un cache en aval.

Décision : Utilisez ceci pour prouver ce que l’autorité sert ; concentrez‑vous ensuite sur les résolveurs, pas sur des captures d’écran d’UI DNS.

Task 14: Inspect local resolver cache behavior (systemd-resolved example)

cr0x@server:~$ resolvectl query example.com --type=MX
example.com: 10 mx1.oldmail.example.net
             20 mx2.oldmail.example.net

-- Information acquired via protocol DNS in 1.9ms.
-- Data is authenticated: no

Ce que cela signifie : Votre hôte voit encore l’ancien MX. Cela peut être votre cache local, pas le monde.

Décision : Videz les caches locaux (avec prudence) ou interrogez un résolveur externe directement pour éviter un auto‑diagnostic erroné.

Task 15: Confirm old system is still receiving mail (to detect split delivery)

cr0x@server:~$ tail -n 5 /var/log/maillog
Jan 04 01:10:21 oldmx postfix/smtpd[18273]: connect from mail-oi1-f170.google.com[209.85.167.170]
Jan 04 01:10:22 oldmx postfix/smtpd[18273]: 3F2A01234: client=mail-oi1-f170.google.com[209.85.167.170]
Jan 04 01:10:22 oldmx postfix/cleanup[18280]: 3F2A01234: message-id=<CA+demo@example.org>
Jan 04 01:10:23 oldmx postfix/qmgr[912]: 3F2A01234: from=<sender@example.org>, size=1842, nrcpt=1 (queue active)
Jan 04 01:10:23 oldmx postfix/local[18290]: 3F2A01234: to=<user@example.com>, relay=local, delay=1.1, dsn=2.0.0, status=sent

Ce que cela signifie : L’ancien MX reçoit toujours du courrier de certaines sources. C’est la distribution fragmentée en action.

Décision : Décidez de relayer/transférer depuis l’ancien vers le nouveau, ou de garder l’ancien mailbox accessible jusqu’à ce que les retardataires s’estompent.

Task 16: Measure “who is still using old MX” by sampling Received headers

cr0x@server:~$ grep -m 1 -i '^Received:' /var/mail/user | head -n 1
Received: from mx1.oldmail.example.net (mx1.oldmail.example.net [203.0.113.10]) by oldmx.example.com with ESMTP id 3F2A01234

Ce que cela signifie : Le message a transité par l’ancienne infrastructure. Les en‑têtes sont de l’or forensique pendant les migrations.

Décision : Si des partenaires clés continuent de router vers l’ancien MX plusieurs jours après, enquêtez pour savoir s’ils utilisent des résolveurs internes avec des caches persistants ou des routes statiques.

Trois mini‑histoires d’entreprise (comment ça tourne mal en vrai)

Mini‑histoire n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne est passée d’une stack Postfix/Dovecot auto‑hébergée à une plateforme de messagerie hébergée. Le plan était simple : synchroniser les boîtes, basculer les MX le vendredi soir, et considérer le travail terminé.

Le chef de projet a supposé que la « propagation DNS » se ferait en minutes parce que leur console DNS s’est mise à jour instantanément.
Ils n’ont pas vérifié le TTL existant. Il était réglé sur 14 400 secondes (4 heures), vestige d’une époque où leurs serveurs faisant autorité étaient fragiles et où ils cherchaient à réduire la charge de requêtes.

Ils ont basculé les MX à 21 h. À 21:15, la première alerte est tombée : certains utilisateurs recevaient dans la nouvelle inbox, d’autres non. À 22 h, les cadres envoyaient des captures d’écran. À minuit, le support avait une file de tickets « e‑mails manquants » qui étaient réels, parce que le courrier était réparti sur deux systèmes sans pont automatique.

L’équipe a tenté de « forcer la propagation » (ce qui n’existe pas) en multipliant les changements DNS. Ça a empiré.
Certains résolveurs se sont rafraîchis et ont obtenu une autre réponse ; d’autres sont restés figés. Leur surveillance, qui utilisait un unique résolveur public, affichait « MX correct ». La réalité s’en fichait.

La correction finale n’a pas été héroïque. Ils ont réactivé la livraison sur l’ancien système, configuré un transfert de l’ancien vers le nouveau,
et attendu la fin des TTL. Le postmortem a conclu par une phrase qui devrait être imprimée sur des mugs : ils ont confondu « le changement d’autorité est actif » avec « les clients ont redemandé ».

Mini‑histoire n°2 : L’optimisation qui s’est retournée contre eux

Une grande entreprise disposait d’une équipe DNS centrale fière de ses performances. Elle exécutait des résolveurs de cache agressifs et en faisait même un front via des forwarders internes sur des sites distants. La latence était excellente. La fiabilité était plutôt bonne. Puis l’équipe mail a planifié une migration de locataire.

L’équipe mail a fait la bonne chose : elle a baissé le TTL MX à 300 secondes une semaine à l’avance. Elle a vérifié les serveurs faisant autorité. Elle a lancé dig depuis quelques portables. Tout semblait prêt.

Le basculement a eu lieu et… les sites distants ont continué à livrer vers l’ancien fournisseur pendant des heures. Pas des minutes.
L’« optimisation » de l’équipe DNS était un comportement de préfetch et de distribution : les résolveurs pré‑récupéraient avant l’expiration du TTL et les forwarders distants avaient leurs propres couches de cache. Le TTL était respecté dans la lettre, mais le comportement effectif pendant les fenêtres de changement était collant.

L’équipe mail a d’abord blâmé le nouveau fournisseur. Le fournisseur a blâmé l’expéditeur. Pendant ce temps, l’ancien fournisseur continuait d’accepter le courrier parce que personne ne voulait le décommissionner pendant la transition. La distribution fragmentée est devenue un problème toute la journée qui n’affectait que certains sites, ce qui est la pire sorte de problème : celui qui ressemble à une erreur utilisateur.

La solution a été de contourner le cache « intelligent » durant le basculement : pointer temporairement les sites distants vers un résolveur qui ne préfetchait pas et n’enchaînait pas les caches, puis revenir après la fenêtre.
De plus, l’équipe DNS a documenté ses couches de cache et ajouté un drapeau de gestion du changement pour les « fenêtres de migration », où le préfetch est désactivé.

Mini‑histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise financière a migré la messagerie dans le cadre d’une refonte identités et postes de travail. La partie messagerie n’était pas glamour. C’était précisément la raison de son succès. Ils ont suivi une checklist, s’y sont tenus, et ont refusé de basculer sans preuves.

Deux semaines avant le basculement, ils ont baissé le TTL sur MX, SPF, sélecteurs DKIM et enregistrements autodiscover. Ils ont horodaté le changement et calculé l’heure « sûre » de basculement en fonction de l’ancien TTL. Ils ont lancé des requêtes contre leurs serveurs faisant autorité et trois résolveurs externes deux fois par jour et consigné les résultats dans un runbook partagé.

Le jour du basculement, leur monitoring ne vérifiait pas seulement « MX égal attendu ». Il vérifiait « MX TTL bas », « bannière SMTP correspond au nouveau système », et « messages de test acceptés et tracés de bout en bout ». Ils ont aussi gardé l’ancien système entrant en ligne mais configuré pour relayer le courrier vers le nouveau système. Les retardataires n’étaient plus un problème visible par les utilisateurs. C’étaient juste une métrique.

La migration a tout de même rencontré des problèmes mineurs : quelques partenaires avaient des hôtes MX codés en dur dans leurs appareils (oui, c’est réel),
et une application interne utilisait un résolveur local qui ne se rafraîchissait pas souvent. Mais parce que le DNS avait été mis en scène, ils ont pu se concentrer sur ces cas limites sans chaos global.

Leur secret n’était pas un outil. C’était la discipline. La pratique ennuyeuse était « mesurer avant de changer, et garder un rollback qui fonctionne ». Le résultat a été un basculement si discret que la direction a oublié qu’il avait eu lieu, ce qui est le plus grand compliment en opérations.

Erreurs courantes : symptôme → cause → correction

1) Symptom: Some senders deliver to old provider hours after MX cutover

Cause racine : Le TTL n’a pas été baissé assez tôt, ou plusieurs couches de cache (forwarders d’entreprise, résolveurs de site) conservent des réponses obsolètes.

Correction : Baissez le TTL plusieurs jours à l’avance la prochaine fois. Pour l’instant, gardez l’ancien entrant acceptant et relayer/transférer vers le nouveau système. Identifiez les résolveurs tenaces et contournez‑les temporairement.

2) Symptom: Mail queues on sender side with “connection timed out”

Cause racine : Le port 25 est bloqué vers le nouveau MX, ou le nouveau fournisseur exige des IP sources spécifiques/configuration de connecteur.

Correction : Validez la joignabilité TCP/25 depuis l’extérieur de votre réseau. Ajustez le pare‑feu, les groupes de sécurité cloud, et les connecteurs/allowlists du fournisseur.

3) Symptom: Bounces saying “Recipient address rejected” after cutover

Cause racine : Domaine non entièrement vérifié/accepté sur la nouvelle plateforme ; règles de routage mal configurées ; boîte pas encore provisionnée.

Correction : Confirmez les domaines acceptés, le provisioning des destinataires, et les politiques catch‑all/alias. Testez RCPT TO sur plusieurs destinataires.

4) Symptom: Email “works” but is now landing in spam or being rejected by strict receivers

Cause racine : SPF pas mis à jour pour le nouvel outbound, DKIM pas signé ou sélecteur manquant, DMARC en alignement strict rejette.

Correction : Mettez à jour le SPF pour inclure les nouvelles sources d’envoi, publiez les sélecteurs DKIM, vérifiez la signature, assouplissez temporairement la politique DMARC pendant la transition.

5) Symptom: Internal users see new MX; external partners see old MX

Cause racine : Votre DNS interne diffère du public (split‑horizon) ou les forwarders internes surchargent le DNS public.

Correction : Assurez‑vous que le DNS interne reflète le MX public ou est délibérément géré différemment. Pendant le basculement, évitez les vues incohérentes sauf si vous faites intentionnellement du routage progressif.

6) Symptom: Outlook/mobile clients break during cutover even though SMTP delivery works

Cause racine : Enregistrements autodiscover/autoconfig pointent encore vers d’anciens endpoints ; TTL trop élevé sur les enregistrements CNAME/SRV.

Correction : Mettez en scène le TTL et mettez à jour les enregistrements de configuration client. Testez depuis des appareils et réseaux propres.

7) Symptom: After switching MX, some mail disappears “into the ether”

Cause racine : L’ancien système accepte mais stocke localement ; pas de relai/transfert ; les utilisateurs cessent de consulter l’ancienne boîte.

Correction : Configurez l’ancien entrant pour relayer vers le nouveau durant la transition. Communiquez l’accès aux anciennes boîtes jusqu’à la fin du trafic.

Blague n°2 : La seule chose plus persistante que le cache DNS est un cadre qui « veut juste une mise à jour rapide » pendant un incident.

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

Phase 1: Inventory and staging (do this early)

Listez tous les enregistrements que vous allez changer : MX, SPF TXT, DKIM TXT, DMARC TXT, autodiscover CNAME/SRV, toute passerelle entrante.
Consignez les TTL actuels et calculez votre fenêtre de mise en scène (l’ancien TTL est l’attente minimale avant de voir les bénéfices).
Baissez les TTL à 300 secondes sur ces enregistrements.
Vérifiez que le DNS faisant autorité sert le nouveau TTL (interrogez @nameserver, pas votre cache de portable).
Vérifiez que plusieurs résolveurs externes convergent vers le TTL bas au fil du temps.

Phase 2: Pre-cutover verification (prove the new system works)

Confirmez que les endpoints MX acceptent TCP/25 et présentent des bannières SMTP valides.
Effectuez une transaction SMTP contrôlée vers un destinataire de test.
Vérifiez la trace de message sur la nouvelle plateforme pour voir s’il est accepté et délivré.
Assurez‑vous que l’ancienne plateforme peut rester en ligne pour recevoir/relayer le courrier durant la transition.
Préparez le rollback : valeurs MX exactes, TTL, et la personne autorisée à exécuter la restauration.

Phase 3: Cutover execution (keep the blast radius small)

Changez les MX vers le nouveau fournisseur pendant que le TTL est bas.
Interrogez immédiatement l’autorité et plusieurs résolveurs pour confirmer que les nouvelles réponses sont actives.
Envoyez des mails de test depuis au moins deux sources externes (boîte personnelle + un service que vous contrôlez).
Surveillez les logs de l’ancien système pour le trafic entrant ; si il reçoit encore, relayez/transférez.
Suivez les échecs : timeouts, rejets 5xx, placement en spam. Corrigez d’abord les plus impactants (généralement accessibilité ou politique d’acceptation).

Phase 4: Stabilization and cleanup (don’t leave sharp edges)

Une fois stable, remontez le TTL à 1800–3600 secondes (ou votre standard).
Revenez sur la politique DMARC si vous l’aviez assouplie ; resserrez progressivement.
Laissez l’ancien entrant en service assez longtemps pour capter les réessais et les retardataires ; puis décommissionnez délibérément.
Consignez ce que vous avez appris : timeline de propagation réelle, résolveurs récalcitrants, et ce qui a fonctionné en monitoring.

FAQ

1) If I lower TTL to 300 seconds, does that guarantee the cutover completes in 5 minutes?

Non. Cela signifie que les caches ont la permission de conserver les réponses pendant 5 minutes après les avoir récupérées. Si un résolveur a récupéré juste avant que vous baissiez le TTL, il peut garder l’ancienne réponse pendant la durée de l’ancien TTL. C’est pourquoi il faut planifier à l’avance.

2) How far in advance should I lower TTL?

Au moins l’ancien TTL, plus une marge. Si le TTL MX est 3600, baissez‑le au moins un jour avant un basculement majeur pour ne pas courir après des caches aléatoires. Pour des TTL très longs (8–24 heures), planifiez une semaine à l’avance et dormez mieux.

3) Should I lower TTL for SPF/DKIM/DMARC too?

Si vous prévoyez de les changer pendant la fenêtre de migration, oui. Les échecs d’authentification ne ressemblent pas souvent à une « panne », mais ils ressemblent à « le courrier a cessé d’arriver », ce qui revient au même.

4) What TTL value should I use during the cutover?

300 secondes est une bonne valeur par défaut. Descendez plus bas seulement si vous avez une raison précise et que vous faites confiance à votre fournisseur DNS sous charge.

5) Can I “force DNS propagation” by changing records multiple times?

Non. Les changements répétés peuvent créer des oscillations où différents caches détiennent des réponses différentes. Faites un changement planifié, vérifiez‑le à l’autorité, et laissez les caches expirer naturellement.

6) If email is delayed after cutover, is that always DNS?

Pas du tout. Les réessais SMTP, le greylisting, les rejets par politique entrante, les problèmes de négociation TLS et le filtrage anti‑spam peuvent tous créer des délais. Le DNS est juste la première chose à prouver ou à éliminer.

7) What’s the safest rollback plan for MX changes?

Conservez les anciennes valeurs MX et assurez‑vous que l’ancien système peut toujours accepter le courrier. Avec le TTL mis en scène bas, le rollback est rapide.
Sans mise en scène, le rollback peut prendre autant de temps que le basculement — parfois plus, car les caches sont maintenant mixtes.

8) Do I need to coordinate with partners or big senders?

Si vous avez des partenaires clés qui envoient du courrier à haute valeur (banques, paie, systèmes de billetterie), informez‑les de la fenêtre de basculement.
Demandez aussi s’ils codent en dur des routes. Certains systèmes legacy stockent littéralement le nom d’hôte MX dans leur configuration.

9) What about on-prem environments with internal DNS split-horizon?

Décidez si les utilisateurs internes doivent suivre le MX public ou une route différente. Si le DNS interne est différent, documentez‑le et testez‑le. Le split‑horizon va bien quand il est intentionnel, et fait mal quand il est accidentel.

10) When should I raise TTL back up?

Après avoir observé une livraison entrante stable et confirmé que le trafic tardif vers l’ancien système est proche de zéro (ou du moins relayé en sécurité). Typiquement 24–72 heures après le basculement est conservateur et raisonnable.

Conclusion : prochaines étapes pour rester en poste

La mise en scène du TTL n’est pas une astuce. C’est une hygiène opérationnelle de base. Si vous la faites tôt, votre basculement MX devient un changement contrôlé avec une fenêtre de convergence courte et un vrai rollback.
Si vous la sautez, vous vous engagez dans une distribution fragmentée, la confusion, et un appel incident où tout le monde débat de la « propagation » comme si c’était la météo.

Étapes pratiques :

Tout de suite : lancez dig et enregistrez le TTL MX actuel.
Aujourd’hui : baissez le TTL à 300 secondes pour chaque enregistrement lié au mail que vous prévoyez de changer.
Demain : vérifiez les réponses faisant autorité et recoupez avec plusieurs résolveurs.
Jour du basculement : changez les MX une fois, testez l’acceptation SMTP, et surveillez les flux entrants anciens et nouveaux.
Après : remontez le TTL, puis nettoyez l’authentification et décommissionnez l’ancien entrant délibérément.