Migrate ProtonMail to Office 365: Bridge + Tenant IMAP Guide

Office 365 is the destination that pulls the most ProtonMail users — companies adopting Microsoft 365 for the collaboration suite, individuals consolidating after a job change, MSPs cutting over a client who's tired of running a separate identity for mail. The migration itself isn't dramatic, but it lives at the intersection of two systems that both have opinions: ProtonMail forces you through Bridge, and Office 365 enforces a per-mailbox quota plus throttling rules that can surprise you mid-job. This walkthrough threads that needle.

What makes this pair different from a normal IMAP move#

Every IMAP-to-IMAP migration has the same shape — connect to the source, list folders, read messages, append them to the destination. ProtonMail to Office 365 has two complications layered on top.

The first is on the source side. ProtonMail's API isn't IMAP. The Bridge daemon decrypts your mailbox on your local machine and re-exposes it as IMAP bound to 127.0.0.1. Any migration tool has to run on the same physical machine as Bridge or it can't talk to the source at all. This rules out Microsoft's own IMAP migration assistant, which expects a publicly-reachable source endpoint with credentials it can use from the cloud.

The second is on the destination side. Office 365 mailboxes have a hard per-mailbox storage quota — 50 GB for most plans, 100 GB for Exchange Online Plan 2. Office 365 also rate-limits IMAP APPEND operations: roughly 2–4 messages per second per connection, with a small number of concurrent connections allowed per account. If you push harder than that, you'll start seeing Too many simultaneous connections and forced disconnects.

Before you start#

Five things to have in place before you launch Mailbox Taxi:

• A paid ProtonMail plan (Mail Plus, Proton Unlimited, Proton Business, or Visionary).
• ProtonMail Bridge installed and signed in on the machine you'll run the migration from.
• A licensed Office 365 user with a provisioned mailbox. Microsoft 365 Business Basic, Standard, Premium, or any of the Exchange Online plans all work.
• An app password generated for that Office 365 user. App passwords require security defaults or per-user MFA to be enabled first.
• Per-mailbox quota headroom on the destination at least 1.1x the size of the ProtonMail mailbox you're moving.

If you're doing this for multiple users at once, set up one machine per parallel migration. A single Bridge install can only serve one Proton account at a time, so simultaneous user moves need either multiple workstations or sequential runs on the same workstation.

Step-by-step migration#

1. Install and unlock ProtonMail Bridge

   Download Bridge from proton.me/mail/bridge and install it on the same workstation you'll run Mailbox Taxi on. Sign in with the Proton account credentials and the second-factor code if 2FA is enabled. Bridge will start an initial sync — depending on mailbox size this can run 15 minutes to over an hour. Watch the Bridge status until it reads "Connected" or "Up to date" before proceeding. Don't quit the Bridge process for the rest of the migration.

2. Copy the Bridge IMAP credentials

   In Bridge, click your account and open the Mailbox configuration view. Note four values: username (usually your-address@proton.me), the Bridge-generated random password (a 16-character string — this is not your Proton account password), host (127.0.0.1), and port (1143 for IMAP with STARTTLS). The SMTP credentials in the same panel aren't needed for migration.

3. Provision and check the Office 365 destination

   In the Microsoft 365 admin center, confirm the target user has an Exchange Online license and the mailbox is provisioned. Check the mailbox quota by opening the user's mailbox properties — under Mailbox usage you'll see current size and quota. If quota is tight, you can request a quota increase from Microsoft or bump the user to Exchange Online Plan 2 for 100 GB.

   Confirm IMAP is enabled on the mailbox. In the admin center, open Active users → the target user → Mail → Manage email apps, and confirm IMAP is checked. If your tenant has disabled IMAP at the org level, an admin will need to re-enable it for migration users.

4. Generate an app password for the destination

   Sign in as the destination user at myaccount.microsoft.com, then go to Security → Additional security verification → App passwords. Create a new app password and name it something obvious like "Mailbox Taxi import". Copy the password — Microsoft only shows it once. If you don't see the App passwords option, MFA isn't enabled for the user, or your tenant has disabled app passwords. An admin will need to turn one of those on.

5. Add both endpoints to Mailbox Taxi

   In Mailbox Taxi, create a new migration job. Source: ProtonMail. Host 127.0.0.1, port 1143, STARTTLS. Username and password from Bridge. Test the connection — it should succeed in seconds. If you see AUTHENTICATIONFAILED, you've likely pasted your Proton account password instead of the Bridge-generated one.

   Destination: Office 365. Host outlook.office365.com, port 993, SSL/TLS. Username is the full UPN (user@yourcompany.onmicrosoft.com or user@yourcustomdomain.com). Password is the app password from the previous step. Test that connection too.

6. Map ProtonMail labels to Office 365 folders

   Mailbox Taxi will read both sides and propose a folder map. ProtonMail's system folders (Inbox, Sent, Drafts, Archive, Spam, Trash) map to the Office 365 equivalents. Custom labels in ProtonMail become custom folders in Office 365 under the root.

   Office 365 doesn't have Gmail-style label multiplicity, so messages tagged with multiple ProtonMail labels will land in the first label's folder. If you want the rest preserved, either use Mailbox Taxi's "duplicate per label" option (which copies the message into every mapped folder) or accept that you'll lose the secondary tags. Most teams accept the loss.

7. Run a dry-run on a single folder

   Pick a small folder — Drafts, or a small project label — and migrate just that. Once it completes, open Outlook on the web or the Outlook desktop client and verify the messages arrived, dates and senders match, attachments open, and HTML renders. Catch any character-encoding or attachment-corruption issues here, before the full run.

8. Run the full migration and monitor throttling

   Kick off the full job. Mailbox Taxi will run multiple connections in parallel up to the safe limit — Office 365 tolerates 4 concurrent IMAP connections per account before throttling kicks in. You should expect 60–120 minutes per gigabyte. Bridge is usually the limiting factor, not Office 365. Leave the machine awake and Bridge running.

   If you start seeing Too many simultaneous connections errors, Mailbox Taxi will automatically back off. If you see them constantly, lower the concurrency setting to 2 connections.

9. Verify and switch over

   When the job completes, compare folder counts on both sides. Spot-check 20–50 random messages — confirm subject, date, From/To/Cc, attachments, and inline images. If you're migrating a domain, plan the MX cutover separately: the migration only handles existing mail, not new incoming mail.

Gotchas specific to ProtonMail → Office 365#

A handful of issues come up reliably on this exact pair.

Defender for Office 365 quarantine#

If your tenant has Defender for Office 365, expect a portion of migrated Spam messages to land in the Defender quarantine rather than the user's Junk folder. This is correct behavior, but it surprises users. Either exclude Spam from the migration entirely or warn the user that some of their old spam will be quarantined rather than restored to Junk.

Calendar invites get re-rendered#

Migrated calendar invites (.ics parts in old emails) sometimes get re-interpreted by Outlook and shown as live calendar items. This is harmless but startling — users see a "new" meeting invite for a meeting from 2019. Tell them in advance.

MAPI properties don't exist on the migrated messages#

Outlook's rich MAPI properties (categories, flags, follow-up reminders) don't exist in IMAP and can't be migrated. The messages migrate, but any Outlook-side categorization a user might have applied in a previous life doesn't come along. Since the source is ProtonMail, this rarely matters — there was no Outlook history to preserve.

Send-as for ProtonMail custom domains#

If users were sending from custom domains in ProtonMail, those custom-domain send-as settings don't transfer. Add the domains as accepted domains in the M365 tenant, add the addresses as proxy addresses on the user object, and they'll be sendable from Outlook.

Real errors you'll see and what they mean#

• AUTHENTICATIONFAILED on source — you used the Proton account password instead of the Bridge-generated one. Copy the right one from Bridge.
• AUTHENTICATIONFAILED on destination — app password wrong, or app passwords disabled in your tenant. Re-generate or have an admin enable them.
• Too many simultaneous connections — Office 365 throttle. Mailbox Taxi will back off automatically; if persistent, lower concurrency.
• Message too large for destination — a single message exceeds Office 365's 150 MB message size limit. Rare, but it happens with old emails containing huge attachments. Skip these and migrate them manually if needed.
• Quota exceeded — you ran out of mailbox quota partway through. Increase the quota, then resume the job.
• STARTTLS handshake failed on the source — you've configured the source for SSL/TLS on port 993 instead of STARTTLS on 1143.

If the connection to Bridge keeps dropping, the fix ProtonMail Bridge connection guide covers the most common Bridge-side failures. For wider context on the Office 365 receiving side, see the Office 365 migration guide.

Communicating the change to users#

For a ProtonMail → Office 365 cutover, users need to know three things: when to stop sending from ProtonMail, when their Office 365 mailbox is ready, and what happens to incoming mail during the gap.

A clean playbook:

• A week out, announce the date and time of the cutover window.
• 24 hours out, send the new sign-in instructions for Outlook on the web and the mobile Outlook app.
• During the window, forward incoming mail from ProtonMail to the Office 365 address so nothing is missed.
• After the window, keep ProtonMail active for 30 days as a fallback.

If you're an MSP, factor those comms into your project plan and have the client review the user-facing language before you send it.

Post-migration checklist#

After the job completes:

• Folder counts match on both sides for every label you care about.
• Spot-check messages render correctly in Outlook on the web.
• Add ProtonMail custom domains as accepted domains in the M365 tenant.
• Add ProtonMail aliases as proxy addresses on the user object.
• Export ProtonMail contacts and calendars and import them into Exchange.
• Set up forwarding from ProtonMail to Office 365 for the transition period.
• Document the migration in your ticketing system with dates, mailbox sizes, and any anomalies.