Le basculement dans le DNS : MX, SPF, DKIM et DMARC

Module 4: Déménager sa messagerie · Temps de lecture : 12 minutes

Objectif pédagogique : après cette leçon, vous saurez planifier et exécuter le basculement DNS pour la messagerie dans le bon ordre, afin qu'aucun e-mail ne se perde, que vos e-mails sortants n'atterrissent pas en spam et qu'Outlook ne continue pas discrètement à frapper à la porte de l'ancien prestataire.

Notions clés : TTL, bascule MX, SPF (un seul enregistrement), sélecteur DKIM, DMARC (p=none, rua), autodiscover, autoconfig, enregistrement de vérification, domaine accepté

Cinq enregistrements, un seul moment

Pour la messagerie sur votre propre domaine, plusieurs enregistrements dans le DNS déterminent ensemble si le courrier arrive et si votre courrier est jugé fiable :

Lors d'un déménagement, presque tout cela change. L'art consiste dans l'ordre des opérations. Si vous basculez le MX pendant que SPF et DKIM ne valent encore que pour Microsoft, votre courrier arrivera bien, mais celui que vous envoyez tombera en spam. Si vous basculez SPF en premier, Microsoft ne pourra plus envoyer correctement en votre nom pendant les jours précédents.

Cette leçon porte sur l'ordre des opérations. Le détail du fonctionnement de chaque enregistrement est expliqué dans le cours DNS (leçons 4.1 à 4.5).

Étape 1, deux jours avant : abaisser le TTL et faire une sauvegarde

Chaque enregistrement DNS a un TTL (time to live) : la durée pendant laquelle les autres serveurs peuvent mémoriser la réponse. Si le TTL de votre MX est de 86400 secondes (un jour), certains serveurs continueront à envoyer vers l'ancien serveur pendant un jour après le basculement.

Abaissez donc au moins un ancien TTL à l'avance : le TTL du MX, du SPF et de l'autodiscover à 300 ou 3600 secondes. Pour un TTL d'un jour, faites-le donc au moins un jour à l'avance ; deux jours, c'est confortable. Faites en même temps une sauvegarde de votre zone DNS, ou notez tous les enregistrements actuels. Vous pourrez ainsi toujours revenir en arrière.

Bakkerij De Korrel voit :

example.com.            3600  IN  MX   0 example-com.mail.protection.outlook.com.
example.com.            3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey    3600  IN  CNAME selector1-example-com._domainkey.korrel.onmicrosoft.com.
selector2._domainkey    3600  IN  CNAME selector2-example-com._domainkey.korrel.onmicrosoft.com.
_dmarc.example.com.     3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
autodiscover            3600  IN  CNAME autodiscover.outlook.com.
example.com.            3600  IN  TXT  "MS=ms12345678"

Le TTL est déjà de 3600 (une heure). Ils fixent MX et SPF à 300.

Étape 2, avant le basculement : préparer DKIM et SPF pour le nouveau prestataire

Les enregistrements qui ne cassent rien, vous les mettez déjà en place à l'avance :

• DKIM du nouveau prestataire. Le nouveau prestataire fournit un sélecteur et une clé, par exemple x._domainkey avec un enregistrement TXT v=DKIM1; k=rsa; p=.... Comme le sélecteur porte un nom différent de celui de Microsoft (selector1 et selector2), ils coexistent sans problème. Chaque destinataire ne regarde que le sélecteur indiqué dans la signature du message.
• Étendre le SPF, ne pas le remplacer. Il ne peut y avoir qu'un seul enregistrement SPF. Ajoutez le nouveau prestataire dans le même enregistrement, afin que pendant les jours de transition, les deux puissent envoyer :

"v=spf1 include:spf.protection.outlook.com include:spf.mailaanbieder.example ~all"

La boulangerie avait -all. Pendant la transition, ils choisissent temporairement ~all (softfail) : si un serveur venait tout de même à manquer, le message serait plutôt jugé suspect que rejeté. Cela suit la règle empirique : ~all si vous n'êtes pas tout à fait certain, -all si vous savez avec certitude que tous les expéditeurs sont inclus.

N'oubliez pas les autres expéditeurs de votre liste de la leçon 4.1 : la boutique en ligne, le service de newsletter, la comptabilité. Ils restent dans l'enregistrement SPF.

Étape 3, le moment du basculement : MX et autodiscover

Au moment convenu, une fois la première copie des boîtes aux lettres terminée (leçon 4.2) :

1. Remplacez les enregistrements MX par ceux du nouveau prestataire. Supprimez l'ancien MX ; ne le laissez pas en « réserve » avec une priorité plus élevée, car du courrier arriverait alors chez l'ancien prestataire dès que le nouveau serait un peu lent.
2. Adaptez autodiscover. Outlook recherche ses paramètres via autodiscover.example.com. Si cela pointe encore vers autodiscover.outlook.com, Outlook continuera d'essayer de se connecter chez Microsoft, même si vous ajoutez un nouveau compte. Supprimez-le ou faites-le pointer vers ce qu'indique votre nouveau prestataire. Certains prestataires utilisent à la place autoconfig.example.com (Thunderbird) ou des enregistrements SRV comme _imaps._tcp et _submission._tcp (RFC 6186).
3. Effectuez une deuxième copie des boîtes aux lettres, afin que le courrier des dernières heures soit également transféré.

Il y a une surprise chez Microsoft 365 qui en prend beaucoup au dépourvu. Tant que example.com figure dans l'environnement Microsoft 365 en tant que domaine accepté, Microsoft livre le courrier entre utilisateurs de ce même environnement en interne, sans tenir compte du MX. Si un collègue qui travaille encore dans Outlook chez Microsoft envoie un e-mail à un autre collègue, ce message arrive dans l'ancienne boîte aux lettres. C'est pourquoi vous basculez tous les collaborateurs le même jour, et vous retirez le domaine de l'environnement Microsoft après la période de transition.

Étape 4, DMARC : surveiller pendant la transition

DMARC indique aux destinataires ce qu'ils doivent faire si un message échoue au contrôle SPF ou DKIM, et vous envoie des rapports. La boulangerie avait p=quarantine. C'est bien, mais dangereux pendant un basculement : si DKIM n'est pas encore activé chez le nouveau prestataire, leur propre courrier atterrit en spam chez les clients.

L'approche sûre :

• Si vous n'avez pas encore de DMARC, commencez par p=none avec une adresse rua. Rien ne sera alors fait avec votre courrier, mais vous recevrez des rapports.
• Si vous avez déjà quarantine ou reject, vérifiez avant le basculement, à l'aide d'un message test, que DKIM fonctionne chez le nouveau prestataire (l'en-tête d'un message reçu affiche dkim=pass avec d=example.com). En cas de doute, passez temporairement à p=none et surveillez les rapports pendant quelques semaines.
• Renforcez ensuite progressivement : none, puis quarantine, puis éventuellement reject. Selon la nouvelle norme DMARC (RFC 9989), vous pouvez aussi utiliser t=y pendant la phase de test ; l'ancienne balise pct disparaît.

Étape 5, après quelques semaines : le ménage

Si tout fonctionne bien pendant quelques semaines, nettoyez les anciens enregistrements :

• l'ancien include du SPF (et éventuellement retour à -all) ;
• les anciens enregistrements DKIM (selector1 et selector2) ;
• l'enregistrement de vérification MS=ms... et d'éventuels autres enregistrements pour Microsoft, comme enterpriseregistration et lyncdiscover si vous en aviez ;
• le TTL, ramené à une valeur normale, comme 3600 ;
• le domaine à retirer de l'ancien environnement Microsoft ou Google.

Si vous laissez l'ancien include en place, l'ancien prestataire pourra encore envoyer des e-mails au nom de votre domaine pendant des années. C'est une porte grande ouverte.

En pratique : à quoi cela ressemble chez un prestataire

Dans Mon WebOké, l'onglet DNS affiche la carte Définir l'e-mail. Elle montre le MX, le SPF et le DMARC avec un point de couleur, et en haut à droite, le prestataire de messagerie qu'elle reconnaît grâce à votre MX. Avec Configuration rapide, vous définissez en une seule fois les enregistrements pour un prestataire, et l'avertissement en jaune signale que les enregistrements MX et SPF existants seront remplacés. Faites donc d'abord une sauvegarde DNS, puis vérifiez que l'enregistrement SPF contient encore vos autres expéditeurs. Sur la page produit d'une offre d'hébergement se trouve la carte Définir l'e-mail, qui indique pour chaque enregistrement s'il est Correct, À vérifier, Incorrect ou Non trouvé, et affiche la valeur avec un bouton de copie. Si le DNS se trouve chez un autre prestataire, reprenez ces valeurs chez lui. D'autres prestataires et panneaux DNS proposent des vues comparables ; les enregistrements eux-mêmes sont partout identiques.

Résumé

• Abaissez le TTL au moins un ancien TTL à l'avance et faites une sauvegarde de votre zone DNS.
• Mettez en place le DKIM du nouveau prestataire et un enregistrement SPF étendu (un seul enregistrement, les deux prestataires) déjà avant le basculement.
• Basculez le MX et l'autodiscover en même temps, et faites basculer tous les collaborateurs le même jour ; sinon Microsoft continue de livrer le courrier interne dans les anciennes boîtes aux lettres.
• Pendant la transition, ne rendez pas DMARC plus strict que ce que vous savez avec certitude ; si vous n'avez pas encore de DMARC, commencez par p=none avec des rapports.
• Après quelques semaines, nettoyez l'ancien include, les anciens enregistrements DKIM, les enregistrements de vérification et le domaine dans l'ancien environnement.

Quiz

Exercice

Exercice A4.3 : Vos enregistrements de messagerie en un coup d'œil. Indiquez votre domaine, et le sélecteur DKIM de votre (nouveau) prestataire. Le programme vérifie si le MX pointe vers votre prestataire, s'il existe exactement un enregistrement SPF, si la clé DKIM figure sur ce sélecteur et s'il existe exactement un enregistrement DMARC. Il mesure aussi le TTL de votre MX auprès du serveur de noms faisant autorité : pour un basculement planifié, celui-ci doit être de 3600 ou moins.

Exercice E4.3 : Votre scénario de bascule. Rédigez pour votre propre domaine le scénario de cette leçon : pour chaque étape, la date et l'heure, les enregistrements avant et après (ancien et nouveau SPF sur une seule ligne), qui s'en charge, et ce que vous vérifiez après chaque étape.

Pour aller plus loin

Les étapes de ces articles valent pour les services de WebOké ; chez d'autres prestataires, cela fonctionne de manière comparable.

• Guide WebOké 6.7: La carte Configurer la messagerie (MX, SPF, DKIM, DMARC)
• Guide WebOké 5.6: Configurer rapidement la messagerie dans le DNS
• Guide WebOké 5.7: Rétablir le DNS et créer une sauvegarde DNS
• Guide DirectAdmin 10.4: Après le déménagement : enregistrements MX et vos appareils
• Cours DNS gratuit 4.3: SPF : qui a le droit d'envoyer des e-mails au nom de votre domaine ?
• Cours DNS gratuit 4.4: DKIM : la signature sous votre mail
• Cours DNS gratuit 4.5: DMARC : que doivent faire les destinataires avec les faux e-mails
• Cours DNS gratuit 6.3: Le DNS lors d'un transfert
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (enregistrements SRV pour les logiciels de messagerie)