You can move existing Microsoft 365 mailbox content to a self-hosted mail server by exporting it to PST and importing it with a destination-compatible tool, or—if your destination supports the required Exchange migration protocol—by using an Exchange Online offboarding migration through MRS Proxy. Neither route works universally: confirm the destination’s import capabilities and your tenant’s licensing, permissions, and retention requirements before choosing one. Plan the content transfer separately from the DNS change that routes new mail to the new server.
First decide what “email” must include
A mailbox migration can mean more than copying messages. Before selecting a method, establish which data and services your organization needs to preserve. A message-only plan may leave important calendar, contact, archive, or compliance data behind.
- Mailbox content: Inventory users, mailbox sizes, folders, large messages, shared mailboxes, aliases, and any archives.
- Other personal data: Identify contacts, calendar items, and tasks. Microsoft’s IMAP migration documentation explicitly excludes these data types from that workflow.
- Retention and compliance: Record retention policies, holds, archive policies, and messaging records management behavior. These can affect what appears in an export or migration and what must be retained separately.
- Mail-flow services: List distribution groups, shared addresses, website forms, ticketing systems, transactional senders, and any Microsoft services that will continue sending mail for the domain.
Microsoft’s IMAP migration guide describes moving mail from source IMAP mailboxes into Microsoft 365—not a general-purpose way to move mail out of Microsoft 365. It says the workflow moves messages in the Inbox and other mail folders, but not contacts, calendar items, or tasks. The page documents a maximum of 500,000 items per mailbox and a largest message size of 35 MB for that specific migration tool; those are not universal limits for PST export, conversion tools, or your destination server. Microsoft also warns that migration may not account for messaging records management or archival policies, which can make messages appear missing during verification.
Choose a transfer route your destination supports
The destination server determines which route is practical. A self-hosted IMAP server should not be assumed to accept PST files or Exchange migrations. Ask the platform maintainer or consult its official documentation for a supported import method before exporting every mailbox.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors#1 Best Overall
| Route | Destination requirement | What to verify |
|---|---|---|
| PST export and destination-compatible import | A supported way to ingest PST contents, directly or through an email client, intermediate Exchange environment, or conversion/import tool. | Folder mapping, message and attachment fidelity, mailbox quotas, import limits, and how to handle archives and retention data. Microsoft eDiscovery export access and licensing must also be confirmed. |
| Exchange Online offboarding through MRS Proxy | A remote mailbox server configured to support the relevant Exchange migration mechanism and MRS Proxy. | Destination configuration, connectivity, tenant permissions, synchronization behavior, and whether the required Exchange features are available on the chosen server. |
Option 1: Export mailbox content to PST
Microsoft Purview eDiscovery documentation describes exporting Exchange mailbox search results as PST files. The export can retain mailbox folder organization when the relevant option is selected. Microsoft’s described eDiscovery export workflow requires an eligible Microsoft 365 Enterprise E3 or E5 license; verify that your tenant, users, and assigned roles qualify before relying on it. Microsoft also publishes export-result and PST-packaging limits, so check its current documentation and your tenant’s licensing before planning a large export.
A PST is a file format, not a guarantee that a self-hosted server can import it. Test the exact import route on the destination you have selected. Do not assume there is a universal direct PST-to-IMAP procedure. If you stage PST files locally, an encrypted, access-controlled network location may be appropriate; removable storage is another possible staging choice, not a Microsoft requirement. Size any storage only after estimating the actual export volume, and protect exported files as sensitive mailbox data.
Rank #2
Option 2: Exchange Online offboarding with MRS Proxy
Microsoft Exchange Admin Center guidance describes an offboarding migration from Exchange Online to a remote mailbox server using MRS Proxy. This may suit a compatible Exchange destination, but it is not a generic migration feature for every self-hosted mail stack. The destination must be configured for the protocol, and connectivity and tenant permissions must be validated. Confirm with the destination administrator that the server supports this route before treating it as an option.
Prepare the destination before moving data
Destination requirements depend on the mail platform, not on a universal Microsoft migration recipe. Before the pilot, verify the following with the platform’s documentation and administrator:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- How it imports PST or receives an Exchange offboarding migration, and which mailbox content types the import preserves.
- Mailbox quotas, message-size limits, folder behavior, and any import-rate or item-count restrictions.
- TLS, user authentication, account provisioning, aliases, shared addresses, and administrative access.
- How outbound mail will be sent, including relay configuration, sender authentication, and IP reputation considerations.
- How the server is backed up and restored, and who owns monitoring and recovery after cutover.
- How archives, retention obligations, and any content that is not part of the mailbox import will be handled.
Run a pilot and compare results
Use a small set of representative mailboxes to validate the chosen route before scaling up. Include ordinary users as well as mailboxes with large folders, attachments, unusual encodings, archives, or other content likely to expose mapping problems. Retain an original export or backup until the organization has verified the migration and approved its retention plan.
- Export or migrate a test mailbox using the exact process intended for production.
- Compare the source and destination: Check folder structure and message counts, then inspect message dates, attachments, and representative content. Investigate differences rather than treating matching totals as proof of a complete migration.
- Test account access and mail flow on the destination without changing production MX records. Verify users can open imported mail and that aliases and shared addresses behave as intended.
- Record known exceptions such as excluded data types, unimported archives, or items affected by retention policies, and assign a separate plan where needed.
- Confirm the procedure is repeatable for the remaining mailboxes and that the team knows how it will perform the final pass at cutover.
Plan the DNS cutover separately from the data transfer
Exporting or synchronizing historical content does not route new inbound messages. MX records tell sending systems where to deliver new mail, so changing MX is a separate mail-flow cutover. Obtain the exact hostnames and record values from the self-hosted platform’s official instructions and enter them in your DNS provider’s current interface. Microsoft’s instructions for connecting a domain to Microsoft 365 contain Microsoft-specific example values; do not reuse those as destination values for a self-hosted server.
Rank #4
Before cutover, review the existing MX record’s TTL and plan the timing with your DNS administrator. Microsoft recommends an MX TTL of 3,600 seconds or less before the cutover described in its migration instructions. A shorter TTL can reduce some caching delay, but it cannot guarantee that every sender will see the change immediately.
Configure authentication for every legitimate sender
Changing MX handles inbound routing; it does not authorize the new server to send mail for your domain. Review SPF, DKIM, and DMARC against the actual outbound setup, including any services that will continue sending on the domain’s behalf. Microsoft Learn’s mail-flow guidance says to use SPF, DKIM, and DMARC together for the best experience.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- SPF: Publish one SPF TXT record for the domain that authorizes all legitimate outbound senders. Microsoft warns that multiple SPF records invalidate SPF. Remove or revise Microsoft 365 authorization only if Microsoft 365 will no longer send mail for the domain.
- DKIM: Enable signing on the new mail system if it supports DKIM, then publish the selector records specified by that system.
- DMARC: Publish a policy and review reporting. Validate SPF/DKIM alignment and message handling before gradually moving to stricter enforcement.
Use a controlled cutover and verify delivery
Schedule the DNS change for a period when administrators can monitor both systems. Complete the planned final export or synchronization pass, change the MX record to the new inbound mail host, and keep Microsoft 365 available while traffic transitions. Some senders may continue delivering to the old service during DNS caching, so monitor both systems and make a plan to reconcile any messages that arrive there.
- Complete the final content pass using the tested procedure and confirm that imported historical mail is accessible.
- Change the MX record to the destination values supplied by the self-hosted platform.
- Send inbound tests from external providers to user mailboxes, aliases, and shared addresses. Confirm delivery at the new server and check for messages still reaching Microsoft 365.
- Send outbound tests to external providers. Inspect delivery logs and queues, and review the recipients’ authentication results for SPF, DKIM, and DMARC.
- Resolve failures before retiring the old service. Check DNS values, authentication records, destination logs, connectivity, and any remaining senders or aliases.
Microsoft’s IMAP migration instructions recommend waiting at least 72 hours after an MX change before stopping synchronization in that documented workflow. That is guidance for the Microsoft IMAP workflow, not a universal DNS propagation guarantee or a substitute for monitoring during a move to a self-hosted destination.
Retire Microsoft 365 only after sign-off
Decommissioning should follow confirmation that users can access the required historical mail, new inbound and outbound messages work, exceptions have been addressed, and retention obligations are satisfied. Keep the old service available for the transition and any remaining message reconciliation. Close it only when the organization’s administrators and compliance owners have approved the move.
Quick Recap
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.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
