G-LAW
Migration de messagerie.
Migration et authentification de la messagerie professionnelle pour un cabinet d'avocats belge.
Périmètre technique documenté pour G-Law -
Périmètre
Trois boîtes professionnelles
-
Bascule
Migration progressive
-
Authentification
Domaine d’envoi
Kanexio a accompagné la migration de messagerie du cabinet. Le site web de G-LAW n’a pas été réalisé par Kanexio.
Client
G-Law
Secteur
Cabinet juridique
Domaine
g-law.be
CONTEXTE
Une messagerie professionnelle à migrer avec méthode.
Pour un cabinet d'avocats, la messagerie relie les échanges quotidiens, les agendas et les archives. Le projet portait sur trois boîtes professionnelles et sur l'authentification du domaine d'envoi.
DÉFI
Préparer chaque étape de la bascule.
Le périmètre consistait à transférer trois boîtes professionnelles, contrôler les configurations et documenter les mécanismes SPF, DKIM et DMARC. Cette page décrit le périmètre, sans transformer l'absence d'incident déclaré en garantie absolue.
APPROCHE
Trois piliers pour une bascule maîtrisée.
Audit et cadrage
Inventaire des boîtes, identification des dépendances et préparation du plan de bascule.
Migration progressive
Transfert planifié des trois boîtes professionnelles et contrôle des étapes de configuration.
Authentification du domaine
Configuration des mécanismes SPF, DKIM et DMARC, accompagnée d’une documentation de projet.
PÉRIMÈTRE LIVRÉ
Une migration et ses mécanismes documentés.
3
Boîtes dans le périmètre de migration
SPF
Mécanisme d’authentification configuré
DKIM + DMARC
Signature et politique de domaine documentées
TRANSPARENCE
Périmètre technique, pas promesse absolue.
Le nombre de boîtes et les mécanismes configurés proviennent de la documentation de projet Kanexio. Les journaux de migration et les données utilisateurs ne sont pas publics. Cette étude ne revendique donc ni « zéro perte » ni « zéro interruption ».
Ce qui est documenté et ce qui n’est pas revendiqué
-
Périmètre de projet
La migration de trois boîtes et la configuration de SPF, DKIM et DMARC.
-
Limite de la preuve publique
Les journaux et données utilisateurs ne sont pas publics. Aucune absence absolue d’incident n’est affirmée.
Comprendre ce qui a été configuré
Un domaine.
Des contrôles complémentaires.
Ouvrez chaque mécanisme pour découvrir son rôle. Le schéma explique les principes de l’authentification ; il ne simule pas un envoi réel.
SPFQui est autorisé à envoyer ?+
Le serveur qui reçoit le message consulte les autorisations publiées pour le domaine d’envoi. SPF permet de vérifier si le serveur expéditeur figure parmi les serveurs autorisés.
Source : documentation Google Workspace ↗DKIMQuelle signature accompagne le message ?+
Le service d’envoi appose une signature numérique. Le destinataire utilise la clé publique du domaine signataire pour la vérifier. Cette signature porte sur les parties signées du message.
Source : documentation Google Workspace ↗DMARCComment protéger le domaine affiché ?+
DMARC relie le domaine affiché dans l’expéditeur à un domaine validé par SPF ou DKIM. Il publie aussi une politique pour les messages qui échouent à ce contrôle : aucune action particulière, mise en quarantaine ou rejet demandé au destinataire.
Source : documentation Google Workspace ↗Sources consultées le 12 septembre 2026. Les contrôles ci-dessus décrivent les protocoles ; les données et journaux privés de la migration restent confidentiels.
Une migration critique à orchestrer ?
Discutons du cadrage, de la migration et des contrôles adaptés à vos enjeux. Premier échange sans engagement.
