How to Move Microsoft 365 Email to a Self-Hosted Mail Server

To move Microsoft 365 email to a self-hosted server, first confirm how that server can import existing mailbox data. The two documented routes to investigate are exporting mailbox items to PST and importing them with a destination-compatible tool, or using Exchange Online offboarding to a remote mailbox server configured for MRS Proxy. Neither route works with every self-hosted mail platform. Plan the transfer of existing mail separately from the DNS change that sends new inbound messages to the new server.

Choose a transfer route your destination supports

The right method depends on the mail server, tenant permissions, and what data you need to preserve. Microsoft documents PST export through eDiscovery and Exchange Online offboarding to a remote mailbox server using MRS Proxy. Its IMAP migration guidance, by contrast, describes bringing mail from an IMAP server into Microsoft 365; it is not a general method for moving mail out of Microsoft 365.

#	Preview	Product	Price
1		Synology Mail Server (MailPlus 5 Licenses)	$250.00	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Microsoft’s eDiscovery export workflow is described for eligible Microsoft 365 Enterprise E3 or E5 licensing. Check the current Microsoft requirements and your tenant’s permissions before building a plan around it. Microsoft’s export documentation also specifies service limits for results and PST packaging; check those current limits against your expected volume rather than assuming one export will cover every mailbox.

If you are considering PST, test the full export-and-import process with a representative mailbox before exporting everyone. Depending on the destination, importing may involve an email client, an intermediate Exchange environment, or a conversion tool. No single direct PST-to-self-hosted-IMAP procedure is established for all platforms. Local storage, such as an encrypted external drive, is optional; an access-controlled network location may be more appropriate. Choose storage capacity only after estimating export size, and protect exported files because they contain mailbox data.

#1 Best Overall

Synology Mail Server (MailPlus 5 Licenses)

• A secure, private, and cost effective email solution
• High-availability architecture maximizes the service uptime
• Specially designed algorithm for high speed full-text search
• Beautifully designed and intuitive mail client allows efficient email management
• Cross-platform support on web client and dedicated mobile apps on Android/iOS

$250.00

Buy on Amazon

MRS Proxy may suit a compatible Exchange destination, but it requires that the remote server and tenant be configured for the migration. Confirm those prerequisites with the destination platform’s documentation and administrator before scheduling the move.

Define what “email” includes before migrating

Inventory the content and services people rely on, not just the primary inbox. Microsoft states that its documented IMAP migration process copies email in the Inbox and other mail folders, but not contacts, calendar items, or tasks. That is a limit of that Microsoft workflow, not proof that every PST or MRS-based route has the same scope. Make a separate transfer and verification plan for each data type.

• Mailboxes, approximate sizes, folders, and unusual message types or attachments.
• Online archives, shared mailboxes, aliases, distribution lists, and any mailbox access delegations users depend on.
• Contacts, calendars, and tasks, including which tool or export method will handle them.
• Retention policies, archive policies, legal holds, and other obligations that affect what is preserved or visible.
• Every system that sends mail using the domain, such as website forms, ticketing tools, transactional services, and any Microsoft 365 services that will remain in use.

Microsoft’s IMAP migration documentation gives a maximum of 500,000 items per user mailbox and a maximum message size of 35 MB for that specific migration tool. Those are not universal limits for PST export, conversion software, or the destination server. Microsoft also warns that migration may not account for messaging records management or archival policies, which can make messages appear to be missing during verification. Check how policies, holds, and archives apply to your tenant and chosen route before comparing mailbox contents.

Prepare the self-hosted mail platform

Before moving production data, configure the destination and establish how it will be operated. These are destination-side checks, not requirements specific to Microsoft’s export tools:

• Verify the supported import method, mailbox quotas, and handling of message formats and attachments.
• Set up secure client access, TLS, authentication, and the intended outbound relay or sending path.
• Plan backups and a tested restore process, and identify who owns server administration and monitoring.
• Check that the server can send reliably to external providers, including its sending IP reputation and any relay restrictions.
• Document how aliases, shared addresses, and lists will work after the move.

Do not select a migration route until the destination can accept a pilot mailbox through the exact process you intend to use. A server that accepts IMAP connections, for example, does not thereby gain the ability to ingest PST files or participate in an Exchange MRS Proxy migration.

Run a pilot and compare the result

Start with a small group that includes ordinary users and representative edge cases: large mailboxes, nested folders, archives, shared mailboxes, attachments, or unusual message content. Keep an original export or backup until the migration is signed off.

1. Export or migrate the selected pilot mailboxes using the planned route.
2. Check message counts and folder mapping, then inspect dates, attachments, and message rendering across representative folders.
3. Test the separate process for calendars, contacts, and tasks if those are in scope.
4. Record gaps or conversion issues, fix the process, and repeat the pilot before scaling up.

For a larger export, estimate how many PST files and import batches the destination can handle, taking Microsoft’s current export limits and your tenant’s actual data into account. Do not assume an export or import can be repeated without planning for duplicates or changed content; confirm how the chosen tool handles a second pass.

Plan DNS and mail flow as a separate cutover

Transferring historical content does not route new messages. MX records tell other mail systems where to deliver incoming mail; changing the MX record does not copy old mail. Coordinate the final data pass and DNS cutover so new messages are not stranded at the old service while users have begun working on the new one.

1. Prepare the records. Obtain the exact hostnames and values from the self-hosted mail platform’s official instructions and your DNS provider. Microsoft’s domain-setup examples are for connecting a domain to Microsoft 365, not values to reuse for a self-hosted server.
2. Reduce the existing MX TTL ahead of cutover. Microsoft recommends a TTL of 3,600 seconds or less before the cutover described in its migration instructions. This can reduce some caching delay, but does not guarantee immediate DNS propagation.
3. Complete the final data pass. Run the final export/import or synchronization procedure supported by your chosen route, and keep the old service available while mail flow is being checked.
4. Change MX at the planned time. Point inbound mail to the new host, using the destination’s exact DNS values. Monitor both systems for messages still arriving at the old service.
5. Configure sending authentication. Update SPF to authorize every legitimate sender for the domain. Microsoft says a domain should have only one SPF record; multiple SPF records invalidate SPF. Enable DKIM signing on the new system if supported and publish its selector records. Set up DMARC reporting and validate SPF/DKIM alignment before moving to a stricter enforcement policy.

Do not keep Microsoft 365 in SPF unless it will still send legitimate mail for the domain. Conversely, include any website, ticketing, transactional, or other services that continue sending. Microsoft Learn recommends using SPF, DKIM, and DMARC together for mail-flow protection; configure them around the actual sending architecture, not an old example record.

Verify delivery before retiring Microsoft 365

During the transition, test both directions with external mail providers and inspect authentication results, server logs, and queues. Confirm that users can access imported historical mail and that aliases, shared addresses, and lists behave as intended. Check for messages delivered to the old service after the MX change and handle them according to the cutover plan.

Microsoft’s IMAP migration instructions recommend waiting at least 72 hours after an MX change before stopping synchronization in that particular workflow. That is workflow-specific guidance, not a guarantee that DNS has fully propagated everywhere or a substitute for monitoring. Do not stop a synchronization process unless it applies to the route you are using and the final mail-flow checks are complete.

Keep the previous service available until the organization has confirmed the migration and addressed retention obligations. Only then should administrators decide whether to stop the old service or remove its configuration.

Quick Recap

Bestseller No. 1

Synology Mail Server (MailPlus 5 Licenses)

A secure, private, and cost effective email solution; High-availability architecture maximizes the service uptime

$250.00

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.