Aller au contenu
DMARC
← Blog

Fusion-acquisition : consolider les domaines email sans trou d'authentification

Par Thomas · RSSI virtuel · 30 août 2026

Dans une opération de fusion-acquisition, l'email ne figure presque jamais dans la data room. Les juristes épluchent les contrats, les financiers retraitent les comptes, les équipes techniques auditent le code et l'infrastructure — mais personne ne demande la liste des zones DNS ni l'état des politiques DMARC de la cible. Le jour du closing, l'acquéreur devient pourtant responsable d'un patrimoine qu'il n'a pas construit : des dizaines de domaines email accumulés au fil des marques, des filiales et des rachats précédents, au niveau d'authentification parfaitement hétérogène.

Le sujet dépasse la dette technique. La période d'intégration est précisément celle où l'usurpation d'identité rapporte le plus : l'opération est annoncée publiquement, les adresses changent, les redirections se multiplient, et chaque salarié s'attend à recevoir des messages inhabituels d'interlocuteurs encore inconnus. Les fraudeurs lisent la presse économique — un communiqué de rachat est, de leur point de vue, un calendrier d'attaque.

Ce guide déroule la méthode pour traverser l'opération sans ouvrir de trou d'authentification : la due diligence email avant l'intégration, la sécurisation de la période de transition, la stratégie de consolidation des domaines, la gouvernance du DNS après la fusion, et le sort des domaines hérités qui ne serviront plus jamais.

Ce qu'une acquisition apporte vraiment : un parc de domaines inconnu

Sur le papier, l'opération porte sur une société et son domaine principal. Dans les faits, la cible arrive avec un parc entier : les domaines des marques commerciales, les déclinaisons locales des entités par pays (.de, .es, .co.uk), les domaines historiques des sociétés qu'elle avait elle-même absorbées dix ans plus tôt, les noms défensifs enregistrés contre le typosquattage, les domaines de campagne créés par le marketing pour un lancement puis jamais décommissionnés, et une traîne de noms parqués dont plus personne ne connaît l'origine.

Le niveau d'authentification de ce parc est systématiquement hétérogène. Un domaine principal parfois bien configuré ; quelques p=none posés un jour sans que personne ne lise ensuite les rapports ; des SPF contradictoires, retouchés par des prestataires successifs ; des sélecteurs DKIM pointant vers des plateformes résiliées ; et une majorité de domaines sans aucun enregistrement. Pire : la liste des juristes — marques déposées, noms renouvelés au registrar — ne recoupe qu'imparfaitement la réalité opérationnelle. Des zones DNS vivent chez un deuxième registrar, ouvertes par une agence locale, parfois sous un compte personnel.

L'erreur classique consiste à ne traiter que le domaine principal de la cible et à découvrir le reste du parc au fil des incidents. La bonne approche prend le problème dans l'autre sens : inventorier d'abord, décider ensuite.

La due diligence email : trois inventaires avant d'intégrer

Idéalement, cette due diligence se mène avant le closing, au même titre que l'audit de sécurité ; à défaut, elle ouvre les premières semaines de l'intégration. Elle tient en trois inventaires.

Le premier est le parc de domaines lui-même : quels noms, chez quels registrars, sous quels comptes, renouvelés par qui et jusqu'à quand. La comptabilité fournisseurs de la cible (factures de renouvellement) et une recherche par titulaire complètent utilement la liste officielle — c'est souvent là qu'apparaissent les domaines ouverts par une filiale ou une agence.

Le deuxième est l'état d'authentification, domaine par domaine : présence et contenu du SPF, sélecteurs DKIM actifs, enregistrement DMARC et sa politique, MX, et — signal précieux — présence d'une adresse rua, qui dit si quelqu'un, un jour, a regardé les rapports. Le tout tient dans un tableau d'une colonne par mécanisme, qui devient la carte de risque de l'intégration.

Le troisième, le plus long, porte sur les expéditeurs tiers de la cible : CRM, facturation, paie, support, plateformes marketing, outils métier qui envoient « au nom de » ses domaines. La méthode est exactement celle de l'inventaire des expéditeurs tiers, avec une difficulté propre aux fusions : l'écosystème à cartographier n'est connu de personne dans l'équipe d'intégration, et les personnes qui le connaissaient quittent parfois l'entreprise avec l'opération.

Un réflexe immédiat rapporte beaucoup : publier v=DMARC1; p=none; rua=mailto:… sur chaque domaine de la cible qui n'a rien. Quelques enregistrements TXT suffisent pour que les données remontent pendant toute l'intégration — au moment des décisions de consolidation, des semaines de rapports seront déjà disponibles.

La période de transition : le moment le plus exposé

La transition commence en général par une décision d'apparence anodine : rediriger les adresses de l'ancienne société vers les nouvelles. prenom.nom@exemple.net devient un transfert automatique vers prenom.nom@exemple.fr, souvent pour des centaines de boîtes d'un coup. Or le transfert SMTP classique casse SPF : chaque message qu'un tiers envoie à l'ancienne adresse et qui repart vers la nouvelle échoue la vérification à l'arrivée, puisque l'IP du serveur de transfert ne figure pas dans le SPF de l'expéditeur d'origine. DKIM survit tant que le contenu n'est pas modifié, et ARC aide chez les grands fournisseurs, mais un flux massif de redirections dégrade mécaniquement l'alignement, pollue les rapports des deux parcs de faux positifs — et fait perdre les messages des expéditeurs en p=reject dont la signature DKIM ne tient pas.

Deuxième risque, plus grave : l'usurpation opportuniste. L'annonce d'une fusion est publique par construction — communiqué, presse spécialisée, registres légaux. Le scénario le plus rentable est la fraude au changement de coordonnées bancaires : une facture « suite à notre fusion, nos coordonnées évoluent », envoyée aux fournisseurs et clients des deux entités depuis un domaine usurpé ou ressemblant. Les conditions sont idéales : tout le monde s'attend à du changement, les circuits de validation sont désorganisés, les interlocuteurs ne se connaissent pas encore. Un domaine de la cible resté en p=none pendant cette fenêtre est une porte ouverte, au pire moment.

Troisième risque, silencieux : la dilution des responsabilités. Deux équipes IT coexistent, les périmètres se recouvrent, et les rapports agrégés n'ont plus de lecteur attitré pendant des mois. La parade tient en une décision : désigner dès la signature un responsable unique de l'authentification email des deux parcs, avec l'ensemble des rapports regroupés au même endroit.

La stratégie de consolidation : quel domaine survit

La première décision structurante est le choix du domaine survivant — le plus souvent celui de l'acquéreur, parfois celui de la cible quand sa marque commerciale est conservée. Quand la marque doit survivre sans son domaine, un sous-domaine de transition du domaine survivant (marque.exemple.fr) offre une voie propre : identité visible préservée, authentification placée sous la politique organisationnelle du groupe, et un seul parc à gouverner. Vient ensuite le calendrier, en trois phases.

La double vie. Les deux domaines émettent en parallèle pendant la migration des boîtes et des outils, sous surveillance des rapports. C'est la phase où les flux applicatifs — facturation, CRM, notifications, paie — basculent un à un vers le domaine survivant, avec la même mécanique qu'une migration de fournisseur de messagerie : source par source, jamais en big bang.

Le gel d'émission. À une date annoncée en interne, plus aucun envoi légitime ne part de l'ancien domaine. Les rapports servent alors de preuve : quelques semaines de volume légitime nul confirment que le gel est effectif et qu'aucun flux oublié ne subsiste. Le mode test de DMARCbis (t=y, successeur du pct retiré du standard) permet de durcir la politique en observant l'effet avant de la rendre définitive.

Le verrouillage. Le SPF de l'ancien domaine est réduit à v=spf1 -all, la politique passe à p=reject, complétée sur le domaine organisationnel par sp=reject et par le tag np= de DMARCbis, qui couvre les sous-domaines inexistants — précieux sur un domaine dont l'arborescence historique n'est plus maîtrisée. La réception, elle, peut continuer : conserver les MX pendant des années pour ne perdre aucun message adressé aux anciennes adresses est parfaitement compatible avec le rejet de l'usurpation en émission.

Gouvernance : à qui appartient le DNS après la fusion

La question paraît administrative ; elle est structurante. Tant que les zones DNS de la cible restent chez son registrar historique, sous les comptes de ses anciens prestataires, chaque enregistrement d'authentification peut être modifié hors de tout contrôle. Le chantier de gouvernance tient en cinq points : consolider les comptes registrar sous l'entité qui gouverne ; révoquer les accès des agences, prestataires et salariés partis avec l'opération ; placer les zones sous contrôle de changement, idéalement en infrastructure-as-code ; nommer un propriétaire par domaine ; et centraliser la réception de tous les rapports dans un même outil multi-domaines.

Le modèle cible est celui de la gouvernance d'un parc multi-marques : politique centrale, exécution déléguée aux entités, et aucun enregistrement d'authentification modifié hors du circuit. Les mois qui suivent une fusion sont exactement ceux où un prestataire oublié retouche un SPF « comme avant » et casse un alignement sans que personne ne comprenne d'où vient l'incident — la trace de qui possède quoi, tenue à jour, est le seul antidote.

Le sort des domaines hérités dormants

Une fois la consolidation achevée, il reste la traîne : les marques abandonnées, les noms des sociétés absorbées au fil des années, conservés pour la propriété intellectuelle ou par simple prudence. Ces domaines n'émettront plus jamais un email légitime — chacun reste pourtant une identité usurpable, dotée de l'historique et de la crédibilité d'une vraie marque.

Le traitement est standard et détaillé dans la protection des domaines parqués : SPF réduit à v=spf1 -all, politique p=reject — avec une adresse rua, pour voir les tentatives d'usurpation continuer d'échouer —, et MX nul (RFC 7505) si le domaine ne reçoit plus rien. Deux rituels complètent le dispositif : à chaque renouvellement, vérifier que le verrouillage est toujours en place ; et avant chaque abandon envisagé, se rappeler qu'un domaine expiré se rachète — il ressusciterait alors, avec vingt ans d'historique de marque, entre les mains d'un inconnu.

En résumé

Une fusion-acquisition apporte toujours un parc de domaines plus grand, plus vieux et moins bien authentifié que prévu. La méthode tient en cinq temps : inventorier — domaines, politiques, expéditeurs tiers de la cible — avant ou dès le closing ; poser p=none et des adresses de rapport partout où il n'y a rien ; traverser la transition en sachant que les redirections massives dégradent SPF et que l'annonce publique attire la fraude ; consolider par phases — double vie, gel d'émission, verrouillage en p=reject ; puis gouverner le DNS unifié comme un actif, jusqu'aux domaines dormants réduits à v=spf1 -all.

Le premier pas ne demande ni budget ni accès : passer chaque domaine du parc — ceux de l'acquéreur comme ceux de la cible — par l'analyse DMARC gratuite donne en quelques secondes la carte des trous d'authentification. Pour suivre ensuite des dizaines de domaines pendant l'intégration et documenter la montée vers p=reject, l'ouverture d'un compte centralise rapports, alertes et historique — l'outillage naturel d'une consolidation qui ne laisse aucun domaine derrière elle.

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.