Migrating email from cPanel to Microsoft 365: a step-by-step guide for SMBs
Domain, IMAP migration, MX cutover, DKIM, shared mailboxes: the real sequence of a cPanel to Microsoft 365 email migration without losing a single message.
21 September 2026 · 4 min read · ALLSAFE SOLUTIONS

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. We just ran this migration for a Casablanca SMB with six mailboxes, in one evening, without losing a message. Here is the exact sequence, including the traps.
Why move email off cPanel
Shared hosting puts dozens of 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.
Microsoft 365 brings what is missing: modern authentication with MFA, free shared mailboxes, 50 GB per user, and deliverability to Gmail and Outlook that no longer depends on a shared server’s reputation. For email alone, the Business Basic licence is enough. We compare plans in Business Basic, Standard and Premium explained.
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.
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. On a tenant created the same day, creation can fail for an hour or two 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 daily until you complete the batch.
Two 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.
An 800 MB mailbox copies in about thirty minutes.
Step 4. Cut over DNS
Once every batch shows “Synced”, five records are enough, 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.
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.
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 few hours while Microsoft builds its reputation.
What to remember
- Never touch the MX before every mailbox exists at Microsoft and the migration is synced.
- Keep the old hosting for a few days after cutover, long enough to verify.
- Test deliverability with a tool such as mail-tester once DKIM is on: the target is 10/10.
Want to hand this migration over? It is one of the most common projects in our managed Microsoft 365 cloud offer, with a simple commitment: no lost mail, no outage visible to your customers.
Let’s talk about your project.
Free initial audit, reply within one business day.





























