Switching email providers is intimidating for a simple reason: email is often the single most critical tool in a business. A few hours of downtime, an address that stops receiving mail for two days, or worse, emails lost for good — and the whole company grinds to a halt.

This guide walks through, step by step, a real migration: 23 email accounts across 3 domain names, moved from Gandi to Microsoft 365, with zero downtime and no data loss. The method applies to most migrations, whatever your starting provider (OVH, LWS, Google Workspace...).

Key takeaway: a successful email migration isn't decided at the moment messages are transferred, but in how you prepare the DNS records and the order in which you make changes. That's what prevents downtime.

1. The upfront audit: list everything before touching anything

Before changing a single DNS record, you need a full picture of what exists:

  • The exact list of active mailboxes, with their data volume (some mailboxes built up over years can be several GB)
  • The domains involved — for a business with several brands or sites, each domain has its own MX records to migrate separately
  • Services that depend on the current email addresses: website forms, connected third-party tools (CRM, invoicing), existing forwards
  • Devices that need reconfiguring: Outlook on computers, phones, tablets

This step avoids the classic bad surprise: discovering after the fact that an address was also used to receive notifications from an accounting tool.

2. Set up mailboxes in Microsoft 365 before touching DNS

The golden rule: everything is prepared on the Microsoft 365 side before a single DNS record is switched. That means creating users, assigning licences, and verifying domain ownership in the Microsoft 365 tenant (via a temporary TXT record provided by Microsoft).

At this stage, emails still arrive normally at the old provider — nothing is switched over on the receiving end yet.

3. Transferring the data: IMAP or native migration tool

To transfer email history, there are two main approaches:

  • IMAP migration via the Microsoft 365 admin centre: works with most providers, including Gandi, provided you have the IMAP credentials for each mailbox
  • PST export/import for cases where IMAP access is limited or to preserve a specific folder structure

For a migration of 23 accounts, a bulk IMAP transfer (via a CSV file listing mailboxes and their credentials) lets you run all migrations in parallel rather than one by one, which significantly cuts the total time.

Worth noting: the initial transfer can take several hours depending on volume. It's best to run a first full sync, then a differential sync right before the final cutover, to catch any emails received in between.

4. The DNS cutover: MX, SPF, DKIM, DMARC

This is the most sensitive step, since it determines where new emails actually land. Four records are involved:

The MX record

It indicates which server receives email for the domain. This is the main change: replacing Gandi's MX records with the ones provided by Microsoft 365 (usually in the format yourdomain-fr.mail.protection.outlook.com).

SPF (Sender Policy Framework)

This TXT record lists the servers authorised to send email on behalf of your domain. It needs updating to include Microsoft 365's servers — typically by adding include:spf.protection.outlook.com to the existing record, rather than replacing it entirely (especially if other services, like a CRM, already send email on your behalf).

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs outgoing emails to prove they haven't been tampered with. Microsoft 365 provides two CNAME records to add, then DKIM is enabled from the admin centre.

DMARC

DMARC builds on SPF and DKIM to tell receiving servers what to do with emails that fail those checks (reject them, quarantine them, or do nothing). It's the last record to configure, once SPF and DKIM are validated and stable.

Why this order? Setting DMARC to strict mode before SPF and DKIM are fully working can cause your own legitimate emails to be rejected by recipients' servers. Always enable DMARC last, in monitoring mode before switching to strict.

5. Cutover day: minimising the downtime window

DNS propagation can take anywhere from a few minutes to 48 hours depending on servers. To limit lost emails during this window:

  • Lower the TTL (time to live) of DNS records 24 to 48h before cutover, to speed up propagation on the day
  • Switch outside business hours when possible
  • Keep the old provider active for a few days after cutover, to catch any emails that transited through the old server during propagation

6. Setting up devices and checking everything works

Once DNS has switched over, the last step is reconfiguring Outlook on workstations (or moving to Outlook on the web if the company doesn't use a desktop client) and on phones. This is also a good time to check the security configuration of devices connected to the new business mailbox.

A final check is essential: send and receive a test email from each mailbox, confirm old emails are all present, and verify that SPF/DKIM/DMARC pass their checks (free tools like MXToolbox let you test this in seconds).

In summary

A successful email migration rests on three principles: fully prepare the new environment before touching DNS, transfer the data in advance so only the essential switch happens on the day, and configure SPF/DKIM/DMARC in the right order so as not to break your email deliverability.