How to Migrate cPanel Email to Microsoft 365 Without Losing Mail

Microsoft states that IMAP migration moves items from a user's Inbox and other mail folders, but does not migrate contacts, calendar items, or tasks. Microsoft also currently documents a maximum of 500,000 items per mailbox and a maximum migrated message size of 35 MB. If users keep contacts or calendars in their old webmail environment, or have unusually large messages, plan a separate migration path instead of treating an IMAP batch as a complete backup.

Run a small but representative pilot: include a large mailbox, one with many folders, an account using aliases or forwarding, and a user on Outlook or mobile. Validate sending and receiving, folders, timestamps, attachments, and sign-in. A pilot surfaces mapping, credentials, and client issues while the blast radius is still small and before the domain-wide mail route changes.

In the Exchange admin center, create an IMAP migration endpoint that connects to the cPanel IMAP server, preferably using SSL/TLS. For multiple mailboxes, prepare the CSV mapping Microsoft 365 mailboxes to source usernames and passwords in the format Microsoft specifies. Migration credentials are sensitive: store the file in a controlled location, restrict access, and securely remove it when it is no longer required.

Create the migration batch and start it before the MX change. Users can continue receiving mail on cPanel while Microsoft 365 copies data to the destination. Monitor each mailbox rather than relying only on the batch-level status, and resolve authentication, endpoint, folder, or item errors before cutover.

After the initial pass, sample-check each mailbox: folder structure, messages from multiple time ranges, attachments, sent mail, and critical business folders. A single total count is not sufficient evidence because items outside migration limits can be skipped and one mailbox can fail while others succeed.

Microsoft recommends creating all users and mailboxes before updating the MX record. Once the domain's MX points to Microsoft 365, new messages begin going to Microsoft 365; existing mail remains at the previous provider unless it has been migrated. Because DNS is cached across many systems, do not assume every sender will follow the new MX at the same instant.

At cutover, apply the exact DNS values shown in the Microsoft 365 Admin Center for your domain. The primary email-related records include MX, Autodiscover, and SPF; do not copy tenant-specific values from another organization. If other legitimate systems still send mail for the domain, design SPF around all authorized senders rather than blindly replacing the old policy. Configure DKIM for the custom domain and introduce a suitable DMARC policy for the real sending ecosystem. Microsoft recommends SPF, DKIM, and DMARC working together for effective email authentication.

During the cutover window, test inbound and outbound mail with multiple external providers, review message tracing, and validate critical SMTP applications. Keep cPanel online as a safety net for messages still reaching the old MX during DNS transition and for incremental synchronization.

Microsoft notes that it can take up to 72 hours for partners' email systems to recognize an MX change, and its IMAP migration guidance says to wait at least 72 hours before deleting the migration batch. Before removing the batch, Microsoft also says to confirm that Microsoft 365 mailboxes have synchronized at least once after mail began routing directly to them.

A safe migration therefore does not define “MX changed” as “project finished.” Monitor whether new messages still arrive on cPanel, review the batch's Last Synced Time, inspect Microsoft 365 message tracing, and run a final reconciliation. Only after the acceptance gates pass should you remove the migration batch, retire the cPanel mail service, and dispose of migration credentials. If cPanel still hosts the website, scope the retirement to mail services rather than changing unrelated web hosting or DNS.

Before cutover, preserve the current DNS records and back up mail using the capabilities available from your cPanel provider. Define stop conditions, who can authorize rollback, and how long the source remains available. If you must roll MX back, DNS caching can still cause mail to arrive at both platforms for a period, so preserve data on both cPanel and Microsoft 365 and continue reconciliation.

Do not make source-mailbox deletion part of the cutover. Do not configure equal-priority MX records and expect them to behave like replication; MX is SMTP routing, not mailbox synchronization. Avoid publishing multiple independent SPF TXT policies for the same domain. Before enforcing a strict DMARC policy, make sure legitimate senders are inventoried and SPF/DKIM alignment has been addressed.

For security, require MFA for Microsoft 365 administrators, minimize migration permissions, never distribute CSV files containing passwords through email or chat, and rotate source credentials if they were exposed to the migration process. For important mailboxes, preserve DNS change logs, cutover timestamps, batch status, and acceptance records so post-migration reports of missing mail can be investigated with an audit trail.

Should I change MX before migrating email?

No. To reduce downtime and mail-loss risk, provision Microsoft 365 mailboxes and run the initial IMAP sync first. Change MX only after the destination data and mail flow are validated.

Does IMAP migrate cPanel contacts and calendars?

No. Microsoft explicitly states that IMAP migration does not move contacts, calendar items, or tasks. Use an appropriate export/import or migration method for that data.

Can I shut down cPanel immediately after changing MX?

You should not. Microsoft says to wait at least 72 hours before deleting the IMAP migration batch and to confirm the batch synchronized after mail began routing to Microsoft 365. Keeping the source available helps capture mail sent according to cached DNS information.

Is every cPanel message guaranteed to migrate over IMAP?

Do not make that guarantee. Microsoft currently documents IMAP limits including 500,000 items per mailbox and a 35 MB maximum message size for migrated messages. Review errors and reconcile actual data.

Do I still need SPF, DKIM, and DMARC after changing MX?

Yes. MX governs inbound routing; sender authentication is separate. Microsoft recommends SPF, DKIM, and DMARC together, and your policy must represent every system that legitimately sends mail for the domain.