G-LAW
Email migration.
Migration and authentication of professional email for a Belgian law firm.
Documented technical scope for G-Law -
Scope
Three professional mailboxes
-
Cutover
Phased migration
-
Authentication
Sending domain
Kanexio supported the firm's email migration. G-LAW's website was not created by Kanexio.
Client
G-Law
Sector
Law firm
Domain
g-law.be
CONTEXT
A methodical approach to business email migration.
For a law firm, email connects daily exchanges, calendars and archives. The project covered three professional mailboxes and authentication of the sending domain.
CHALLENGE
Prepare every stage of the cutover.
The scope was to transfer three professional mailboxes, check configurations and document SPF, DKIM and DMARC mechanisms. This page describes the scope without turning the absence of reported incidents into an absolute guarantee.
APPROACH
Three pillars for a controlled cutover.
Audit and scoping
Mailbox inventory, dependency identification and preparation of the cutover plan.
Phased migration
Planned transfer of the three professional mailboxes and checks at each configuration stage.
Domain authentication
Configuration of SPF, DKIM and DMARC mechanisms, accompanied by project documentation.
DELIVERED SCOPE
A documented migration and its mechanisms.
3
Mailboxes within the migration scope
FPS
Authentication mechanism configured
DKIM + DMARC
Signature and domain policy documented
TRANSPARENCY
A technical scope, not an absolute promise.
The mailbox count and configured mechanisms come from Kanexio project documentation. Migration logs and user data are not public. This study therefore claims neither “zero loss” nor “zero interruption”.
What is documented and what is not claimed
-
Project scope
Migration of three mailboxes and SPF, DKIM and DMARC configuration.
-
Limit of public evidence
Logs and user data are not public. No absolute absence of incidents is asserted.
Understand what was configured
One domain.
Complementary checks.
Open each mechanism to discover its role. The diagram explains authentication principles; it does not simulate a real send.
SPFWho is authorised to send?+
The receiving server checks the authorisations published for the sending domain. SPF verifies whether the sending server is among the authorised servers.
Source: Google Workspace documentation ↗DKIMWhich signature accompanies the message?+
The sending service applies a digital signature. The recipient uses the signing domain's public key to verify it. This signature covers the signed parts of the message.
Source: Google Workspace documentation ↗DMARCHow is the displayed domain protected?+
DMARC links the domain displayed in the sender address to a domain validated by SPF or DKIM. It also publishes a policy for messages that fail this check: no specific action, quarantine or rejection requested from the recipient.
Source: Google Workspace documentation ↗Sources consulted on 12 September 2026. The checks above describe the protocols; private migration data and logs remain confidential.
A critical migration to coordinate?
Let's discuss scoping, migration and checks suited to your needs. An initial conversation with no obligation.
