KoltrixMigrating Away From Fastmail or Proton Mail: A Practical Checklist
A checklist for moving a custom domain off Fastmail or Proton Mail: exporting mail, recreating aliases, switching DNS, and the extra steps encryption adds.
On this page(8 sections)
- First, decide whether you need to move everything
- Step 1: Inventory what you have
- Step 2: Get your mail out
- From Fastmail
- From Proton Mail
- Wherever the mail is going
- Step 3: Deal with aliases and masked addresses
- Step 4: Switch DNS in the right order
- Step 5: Keep the old account for an overlap period
- A quick checklist
- Key takeaways
Fastmail and Proton Mail are both well-liked, and teams rarely leave them because something broke. More often the company changed: there's now an app that needs to send email, a shared support address that needs a team, or a second product on a second domain. Whatever the reason, the move itself is mostly the same work, with a few extra steps on the Proton side because of encryption.
This checklist covers both. Vendor-specific details reflect each provider's public documentation at the time of writing, so check their help pages for the current steps before you start.
First, decide whether you need to move everything
Before planning a full migration, be honest about what's driving it. A few common cases don't need one:
- Your app needs to send transactional email. You can add a sending service on the same domain and keep your mailboxes where they are. Add its SPF include and DKIM record alongside your existing ones.
- One teammate wants a different client. Fastmail supports standard protocols, and Proton offers Bridge for desktop clients on paid plans, so client preference alone rarely justifies a move.
- You want stronger privacy. If that's the goal, moving away from Proton is probably a step in the wrong direction. Its end-to-end encryption is the reason many people chose it.
If you're consolidating mailboxes, app sending and team workflow into one place, or the current provider no longer fits how the company works, read on.
Step 1: Inventory what you have
List everything attached to the domain before you change anything:
| Item | Where to find it | Notes |
|---|---|---|
| Mailboxes (one per person) | Admin or account settings | Who still uses each one? |
| Aliases on your custom domain | Domain or alias settings | Easy to forget; often used for signups |
| Masked or generated addresses | Privacy or alias features | Tied to the old provider; see Step 3 |
| Forwarding rules and filters | Each user's settings | Recreate the ones that matter |
| Catch-all setting | Domain settings | Decide whether you still want one |
| Other services sending as your domain | SPF record, DMARC reports | Billing, CRM, helpdesk, forms |
| Calendars and contacts | Each user's account | Mail migration doesn't move these |
The last row catches people out. Fastmail and Proton both include calendars and contacts, and those need their own export and import. If your new email provider doesn't offer a calendar, decide where it goes before you cancel anything.
Step 2: Get your mail out
From Fastmail
Fastmail supports IMAP, so the most universal way to get a complete copy of your mail is to connect an IMAP client, such as Thunderbird or Apple Mail, let it download everything, and store that local copy safely. Fastmail also documents its own export options in its help center. For a team, do this per mailbox and check that the folder structure came across.
From Proton Mail
Proton encrypts your mail at rest with keys only you hold, so the server can't simply hand over readable copies the way a conventional provider can. Proton provides its own export tooling for this, and on paid plans, Bridge lets a desktop IMAP client read decrypted mail locally, which you can then save. Check Proton's current documentation for the recommended method, and allow more time than you would for a conventional mailbox.
Two encryption-specific points:
- Exported mail is decrypted. Once it leaves Proton, it's ordinary mail on your disk. Store the archive somewhere encrypted and access-controlled, because you've just removed the protection you were paying for.
- Back up your keys if you might need them. If people have sent you mail encrypted to your Proton keys outside Proton's own system, think about whether you'll ever need to read that again before you close the account.
Wherever the mail is going
Plan for the possibility that your new provider can't import an archive. Koltrix, for example, has no mailbox importer in its first release; pulling old mail across over IMAP is planned for a later release. Until then, the old archive lives in your local export or in the old account kept open read-only. Our post on what to do with the old mailbox after you migrate covers the options.
Step 3: Deal with aliases and masked addresses
Aliases on your own domain are easy: recreate each one at the new provider before you switch MX, then test each.
Masked or generated addresses are harder. Fastmail's masked email and Proton's alias features generate addresses that are tied to the provider rather than to your domain. They won't move with your domain, so mail to them keeps flowing to the old account only as long as it exists. Go through the accounts that use them (often shopping sites, newsletters and SaaS signups), and update the important ones to a real address on your domain before you close anything.
Step 4: Switch DNS in the right order
The DNS work is the same as any provider move, and order matters:
- Lower the TTL on your MX records to 300 seconds a day or more ahead.
- Add the new provider's SPF include to your existing SPF record. Don't publish a second SPF record; merge into the one you have.
- Publish the new provider's DKIM record. It uses its own selector, so it sits alongside the old provider's DKIM records without conflict.
- Create every address at the new provider and send a test message in each direction.
- Switch MX on a quiet morning. Check propagation with an MX lookup.
- Leave the old DKIM records and SPF include in place for a week or two, so mail still in flight from the old provider keeps passing.
- Clean up the old provider's records once nothing is sending through them, and confirm your DMARC policy is still what you want with a DMARC check.
Our Google Workspace cut-over checklist walks through the same sequence in more detail, and almost all of it applies here.
Step 5: Keep the old account for an overlap period
Don't cancel on cut-over day. Keep the old account alive, at least on its cheapest paid tier, for a few weeks:
- Mail sent before the MX change can still arrive there for a short while.
- Masked addresses you haven't updated keep working.
- People can still look things up in their old mailbox while they get used to the new one.
Set a calendar reminder for the cancellation date, and do a final check of the old inbox before you close it.
A quick checklist
- Inventory mailboxes, aliases, masked addresses, filters and calendars
- Export mail for every mailbox and store it encrypted
- Export calendars and contacts separately
- Update important accounts that use masked or provider-only addresses
- Recreate aliases at the new provider
- Lower MX TTL, merge SPF, publish new DKIM
- Switch MX and test every address
- Keep the old account for a few weeks, then cancel
Key takeaways
- Fastmail exports are straightforward over IMAP; Proton exports take Proton's own tooling or Bridge, plus extra care because the result is decrypted.
- Masked and generated addresses don't move with your domain. Update important accounts before you close the old one.
- Calendars and contacts need their own export.
- Merge SPF, add DKIM alongside the old records, switch MX last, and keep the old account through an overlap period.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
