Migrating email from cPanel to Microsoft 365: a step-by-step guide for SMBs

Email hosted on a shared cPanel server works for years, until the day it doesn’t: a mail client that stops connecting, a brute-force protection that locks the account, messages to Gmail that never arrive. The short answer: you can move to Microsoft 365 without losing a single message, as long as you follow a strict order. Create the tenant, create every mailbox, copy history over IMAP, and only cut over DNS once the copy is synced. Here is the exact sequence we apply, including the traps we have hit in the field.

Why move email off cPanel

Shared hosting puts many companies on the same server. Brute-force blocklists are shared: another customer’s failed logins can lock your own tools out. Authentication stays password-only, with no native second factor, and shared mailboxes simply do not exist.

Criterion	Shared cPanel email	Microsoft 365
Authentication	Password only	Modern authentication with MFA
Shared mailboxes	No, accounts with a shared password	Yes, free, with delegated rights
Sending reputation	Tied to the shared server	Microsoft infrastructure, per-domain DKIM
Calendars and contacts	Depends on the mail client	Synced across every device
Administration	Per mailbox, in cPanel	Centralised, with audit logs

For email alone, the Business Basic licence is enough; it comes with a 50 GB mailbox per user. We compare plans in Business Basic, Standard and Premium explained, and if you are still weighing Google, in Microsoft 365 or Google Workspace.

Step 0. Take inventory before touching anything

Most migration incidents come from an incomplete inventory. Before starting, list:

• Every address: named mailboxes, service addresses, aliases, forwarders and mailing lists configured in cPanel.
• Non-human senders: multifunction printers that email scans, a website or contact form that sends mail, business software that emails invoices. Each will need reconfiguring.
• The current DNS zone: who manages it (host, registrar, Cloudflare), and a copy of every existing record.
• The mail clients in use: Outlook, Thunderbird, Apple Mail, phones. Each reconnects differently.

Also lower the TTL of the MX and autodiscover records a few days before cutover, so the change propagates faster when the time comes.

Step 1. Create the tenant and attach the domain

The tenant name, in onmicrosoft.com, is permanent: keep it short and clean. Add your domain with a single TXT verification record, and decline the automatic service connection. At this stage, mail must keep flowing to the old host.

One surprise: changing your own username from the Microsoft 365 admin center signs you out before the change is saved. Use the Entra admin center instead, which applies it without dropping the session. Turn on MFA for admin accounts right away.

Step 2. Prepare the destination mailboxes

Every address must exist at Microsoft before the cutover, or mail bounces. Service addresses such as contact, support and sales become free shared mailboxes, with full access and send-as rights delegated to the right people. Recreate the aliases and distribution groups found in the inventory too. On a tenant created the same day, creation can fail temporarily with a “domain not accepted” message: that is provisioning lag, not a configuration error.

Step 3. Migrate history over IMAP

The Exchange admin center offers an IMAP migration batch: an endpoint pointing at the cPanel server on port 993 with SSL, and a CSV with three columns, target address, source username, password. Microsoft then copies mailboxes server to server and resyncs regularly until you complete the batch.

Three traps we hit:

• The CSV must use commas, with no wrapping quotes. French versions of Excel and Numbers export semicolons.
• The cPanel server may refuse Microsoft’s connections with a misleading “Authentication failed” even though the password is right. That is cPHulk blocking Microsoft’s IP ranges. Dropping to one concurrent connection, or asking the host to whitelist, unblocks it.
• IMAP migration only moves email and folders: no contacts, no calendars, no mail rules. Export them from the old mail client and import them into Outlook.

The CSV holds passwords in clear text: delete it as soon as migration is done, and have the cPanel passwords changed afterwards.

Step 4. Cut over DNS

Once every batch shows “Synced”, five records are enough for email, all unproxied if you use Cloudflare:

Record	Value
MX	yourdomain-com.mail.protection.outlook.com, priority 0
TXT SPF	v=spf1 include:spf.protection.outlook.com -all
CNAME autodiscover	autodiscover.outlook.com
CNAME selector1._domainkey	provided by Microsoft
CNAME selector2._domainkey	provided by Microsoft

Delete cPanel’s old autodiscover records, A and SRV, or the CNAME cannot be created. Watch the DKIM target format too: recent tenants use targets under dkim.mail.microsoft, not the older onmicrosoft.com form. Copy the ones the Defender portal shows, then enable signing.

If the website, a piece of software or a printer sends mail as your domain through another service, add it to SPF: a strict -all SPF will reject those messages. Finish with a DMARC record, first in monitoring mode (p=none) with a reporting address, then tightened once reports are clean. It is one of the best defences against spoofing of your domain, as described in our article on email scams.

Step 5. Complete and reconnect clients

After a delivery test from an external address, complete the migration batches: a final sync collects mail that arrived in between. Mail clients then reconnect with OAuth, with no server or port to type. On phones, remove the old IMAP account before adding the Microsoft 365 one, to avoid duplicates.

Two limits for third-party clients. Exchange shared mailboxes are not supported by most clients other than Outlook: the workaround is forwarding with a copy to the main mailbox, plus an alias to reply as the shared address. And a brand-new tenant may see external sends refused with code 5.7.708 for a transitional period while Microsoft builds its reputation.

A typical schedule

When	Actions
Before cutover	Inventory, lower TTL, tenant created, domain verified, mailboxes and aliases created, admin MFA
During the copy	IMAP batches started and monitored, contacts and calendars exported
Cutover evening	Batches synced, DNS switched, external delivery test
Next day	Batches completed, PCs and phones reconnected, DKIM enabled, printers and website reconfigured
Following week	DMARC in monitoring, reports reviewed, old hosting kept then cancelled

The most common mistakes

1. Switching the MX before every mailbox exists at Microsoft: mail bounces.
2. Forgetting a service address or alias, discovered when a customer complains about a bounce.
3. Forgetting the printer, the website form or the invoicing software, which stop sending.
4. Cancelling the old hosting on the same day, with no way back and no way to recover a forgotten folder.
5. Leaving the migration CSV, with its passwords, in a shared folder.
6. Stopping at the MX without DKIM and DMARC, then finding that mail lands in spam.

Migration checklist

• Every address, alias, forwarder and list inventoried.
• Non-human senders identified: printers, website, business software.
• Copy of the existing DNS zone and lowered TTL.
• Tenant created, domain verified, MFA on admins.
• Mailboxes, shared mailboxes and aliases created at Microsoft.
• IMAP batches synced, contacts and calendars exported.
• MX, SPF, autodiscover and DKIM in place, DMARC in monitoring.
• External send and receive test passed, deliverability checked with a tool such as mail-tester.
• CSV deleted, old hosting kept for a few days.

How we do it

We start with a full inventory and a cutover plan agreed with you, then run the migration outside working hours so business is not interrupted. We handle DNS, reconnect PCs and phones, configure SPF, DKIM and DMARC, and stay reachable the next day for final adjustments. We also offer to put Microsoft 365 backup in place from day one, because Microsoft does not do it for you, along with MFA for every user. As a Microsoft partner, this is one of the most common projects in our managed Microsoft 365 cloud offer; our case studies show others.

The same method applies to a move to Google: see Google Workspace in Morocco: licences and migration.

Want to hand this migration over, with a simple goal: no lost mail, no outage visible to your customers? The initial audit is free: contact us, we reply within 24 business hours.