Changer de prestataire email sans casser DMARC

exemple.fr.  IN TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all"

Avant la bascule, toujours : le DKIM du nouveau, activé et prouvé

Deuxième chantier préparatoire, au moins aussi important : la signature DKIM du nouveau prestataire doit être activée, publiée et vérifiée avant qu'un seul utilisateur ne bascule. Concrètement : chez Google Workspace, la publication du sélecteur google._domainkey en TXT et l'activation de la signature dans la console ; chez Microsoft 365, deux enregistrements CNAME (selector1._domainkey et selector2._domainkey) pointant vers l'infrastructure Microsoft, puis l'activation explicite de la signature pour le domaine — sans cette dernière étape, les messages partent signés par le domaine technique onmicrosoft.com, sans alignement avec le domaine visible.

Hors des deux grandes suites, le geste est identique mais la console change de place — et c'est là que les migrations perdent leurs journées. Chez GoDaddy comme chez IONOS, l'enregistrement se pose dans l'interface DNS du registrar, laquelle n'offre pas toujours de champ dédié à DMARC et impose de le saisir en TXT brut ; chez Infomaniak et chez Zoho Mail, le sélecteur DKIM est généré depuis le panneau d'administration puis recopié à la main dans la zone, avec le risque de troncature qu'entraîne toute clé longue. La difficulté n'est jamais conceptuelle : elle est dans l'endroit où le bouton se cache.

La vérification ne se fait pas sur la foi de la console d'administration, mais sur un message réel : un envoi de test vers des boîtes externes chez plusieurs fournisseurs, puis la lecture de l'en-tête Authentication-Results — dkim=pass ne suffit pas, il faut que le d= de la signature corresponde au domaine émetteur. C'est cet alignement, et lui seul, que DMARC comptabilise.

Vient ensuite la période de recouvrement : deux à quatre semaines pendant lesquelles les deux prestataires sont pleinement authentifiés et la migration avance par vagues — un service pilote d'abord, puis les équipes par groupes, les applications en dernier. Chaque vague qui bascule le fait vers une destination dont SPF et DKIM sont déjà verts. C'est tout le cœur de la méthode : la preuve précède le mouvement.

Pendant : les rapports RUA au jour le jour

Une fois la bascule engagée, les rapports agrégés (RUA) changent de statut : de tableau de bord hebdomadaire, ils deviennent l'instrument de pilotage quotidien. Chaque matin de la fenêtre de migration, quelques questions simples trouvent leur réponse dans les données de la veille. Le volume se déplace-t-il bien de l'ancienne source vers la nouvelle, au rythme des vagues ? Quels flux restent accrochés à l'ancienne infrastructure — et sont-ils identifiés, planifiés, ou oubliés ? Le nouveau prestataire produit-il des échecs d'alignement résiduels, signe d'un domaine par défaut ou d'un chemin de retour mal réglé ?

Les rapports jouent aussi leur rôle de vigie : une source totalement inconnue qui apparaît en pleine migration est soit un flux interne oublié qui refait surface, soit une usurpation opportuniste — les fraudeurs aiment les périodes de flottement, où un email « informatique » annonçant un changement de messagerie paraît plausible. Dans les deux cas, la découverte au jour le jour vaut infiniment mieux que la découverte au bout d'un mois.

Un pic d'échecs localisé sur un flux précis est un signal d'arrêt : la vague suivante attend que la cause soit comprise et corrigée. C'est la discipline qui distingue une migration pilotée d'une migration subie.

Redescendre la politique d'un cran : un arbitrage, pas un réflexe

Faut-il assouplir la politique DMARC pendant la fenêtre ? La réponse honnête : parfois, et jamais par défaut. Un domaine à p=reject dont l'inventaire laisse des zones d'ombre — applications mal cartographiées, filiales autonomes, historique DNS douteux — peut légitimement redescendre à p=quarantine le temps de la bascule : un flux oublié finira en spam, récupérable, au lieu d'être détruit.

_dmarc.exemple.fr.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:rua@exemple.fr"

Mais cette redescente est un arbitrage documenté, pas un geste technique anodin : elle rouvre une fenêtre d'usurpation sur toute sa durée. La décision mérite une trace écrite — motif, périmètre, date de retour prévue — et la remontée à p=reject fait partie intégrante du plan de migration, pas d'un vague « plus tard ». À noter que DMARCbis, le standard courant, a supprimé la balise pct qui permettait autrefois un durcissement progressif en pourcentage : les crans de politique sont désormais francs, et le mode test s'exprime par le drapeau t=y. Redescendre d'un cran est donc un choix entier, assumé comme tel.

Le point de comparaison utile : un domaine dont l'inventaire est complet et le DKIM du nouveau prestataire prouvé migre très bien à p=reject constant. La redescente compense un défaut de visibilité — elle ne remplace pas le travail de préparation.

Après : la purge de l'ancien prestataire

La migration ne s'achève pas quand le dernier utilisateur bascule, mais quand l'ancien prestataire a perdu tout pouvoir d'émission. Cette purge, trop souvent négligée, comporte trois volets. Le SPF d'abord : l'include de l'ancien est retiré dès que trente jours de rapports RUA ne montrent plus aucune émission légitime par son infrastructure. Le DKIM ensuite : les sélecteurs de l'ancien prestataire sont révoqués du DNS — des clés de signature qui traînent sont autant de pouvoirs de signature laissés à un tiers désormais hors contrat, exactement le risque que couvre la rotation propre des clés de signature. Les accès enfin : comptes de service, mots de passe d'application, connecteurs SMTP sortants, boîtes partagées et redirections temporaires créées « pour la transition » sont fermés un à un.

Un domaine mal purgé traîne des autorisations fantômes pendant des années : un include SPF qui délègue l'émission à une infrastructure oubliée, une clé DKIM active chez un prestataire quitté depuis longtemps. C'est précisément le genre de passif que révèle, côté acheteur, l'historique email d'un domaine racheté — mieux vaut ne pas être le vendeur qui l'a laissé.

Les oubliés classiques : imprimantes, applications métier, alias

Trois familles d'expéditeurs échappent presque systématiquement aux plans de migration, parce qu'aucun humain ne les voit émettre. Les copieurs et scanners d'abord : la fonction « scan vers email » est configurée en SMTP authentifié sur l'ancien serveur, avec un mot de passe posé il y a cinq ans par un prestataire disparu. Le jour où l'ancien SMTP s'éteint, la numérisation cesse — et le lien avec la migration de messagerie n'est pas fait immédiatement.

Les applications métier ensuite : ERP qui envoie les factures, CRM qui envoie les relances, supervision qui envoie les alertes, sauvegardes qui envoient leurs comptes rendus, scripts planifiés écrits par un développeur parti depuis. Chacun embarque des identifiants SMTP de l'ancien monde. Le symptôme typique est différé : tout fonctionne pendant trois semaines, puis les relances trimestrielles de facturation échouent en masse — parce que ce flux-là n'émet qu'une fois par trimestre.

Les alias et redirections enfin : une redirection réémet le message depuis l'infrastructure qui redirige, ce qui casse SPF en aval ; seule une signature DKIM intacte maintient alors l'authentification. Une migration redessine ces chemins de réacheminement, et un alias historique peut passer d'un cas « DKIM survit » à un cas « plus rien ne passe ». Les rapports RUA de la période de recouvrement sont le seul endroit où ces flux discrets se voient.

La check-list de fin de migration

Une migration est terminée quand chaque ligne de cette liste est un état constaté — pas une intention :

• l'include SPF de l'ancien prestataire est retiré, et le compteur de résolutions DNS revérifié après retrait ;
• les sélecteurs DKIM de l'ancien prestataire sont révoqués du DNS, et la date de révocation consignée ;
• les comptes de service, mots de passe d'application et connecteurs SMTP de l'ancienne infrastructure sont fermés ;
• trente jours de rapports RUA ne montrent plus aucune émission par l'ancien prestataire ;
• la politique DMARC est remontée à son niveau antérieur si elle avait été redescendue, et l'arbitrage archivé ;
• l'inventaire des expéditeurs est à jour, copieurs, applications métier et alias compris ;
• la documentation DNS reflète l'état final : SPF allégé, sélecteurs actifs, enregistrement DMARC.

Sept lignes, aucune héroïque ; leur seule difficulté est d'exister par écrit et d'être vérifiées à date fixe plutôt qu'« un jour ».

En résumé

Une migration de messagerie casse DMARC quand elle est jouée dans le désordre : SPF remplacé au lieu d'étendu, DKIM jamais prouvé, ancien prestataire coupé trop tôt ou jamais purgé. La séquence sûre inverse la charge : avant la bascule, un SPF additif fait coexister les deux prestataires et le DKIM du nouveau est vérifié sur des messages réels ; pendant, les rapports RUA se lisent au jour le jour et la politique ne redescend d'un cran que sur arbitrage documenté, avec date de retour ; après, l'ancien prestataire perd méthodiquement tout pouvoir d'émission — include retiré, clés révoquées, comptes fermés. Les copieurs, les applications métier et les alias de redirection sont les oubliés qui décident, à eux seuls, si la migration se termine bien.

Le bon point de départ ne dépend d'aucun calendrier de bascule : une analyse DMARC gratuite du domaine montre, avant même de choisir la date, qui émet réellement sous son nom et ce que la migration devra préserver. Et pour piloter la fenêtre de recouvrement sur les rapports du jour plutôt qu'à l'aveugle, l'ouverture d'un compte donne à la migration l'instrument qui lui manque le plus souvent : la preuve, jour après jour, que rien ne s'est cassé.