Moving From Fastmail to Google Workspace or Microsoft 365

The short answer
Moving from Fastmail to Google Workspace or Microsoft 365 means exporting mail, contacts and calendars over IMAP or a vendor migration tool, re-pointing your domain's MX records, rebuilding aliases and Masked Email addresses as new mailboxes or groups, and keeping Fastmail active in read-only mode until DNS and every connected app have switched over.
How to move from Fastmail to Google Workspace or Microsoft 365: what transfers, what breaks, and how to avoid downtime.
On this page
You are moving from Fastmail to Google Workspace or Microsoft 365 for a reason that has nothing to do with email itself: you hired someone, and Fastmail does not sell shared drives, SSO, or the admin console a growing team eventually needs.
The good news is that mail, contacts and calendars all transfer with the right tools. The bad news is that a handful of Fastmail-specific things do not, and finding that out after you have cancelled the old account is expensive. This guide covers what moves, what breaks, and how to do the cutover without a mail outage.
What actually moves and what doesn't#
Mail, contacts and calendars are standards-based on both ends, so they transfer with the right tool. Fastmail speaks IMAP for mail and CalDAV/CardDAV for calendars and contacts; Google's Data Migration Service and Microsoft's Exchange admin center both know how to pull from a generic IMAP source.
Several things do not move at all, because they are specific to how Fastmail is built rather than to the email standard underneath it.
- Mail — moves. IMAP export/import copies messages and folder structure; nested folders may need review once they land as Gmail labels.
- Contacts and calendars — move, but usually through a separate CardDAV/CalDAV export and CSV or ICS import, not the same tool that migrates mail.
- Your custom domain — moves without changing registrars. You repoint DNS records; the domain itself stays wherever it's registered.
- Sieve rules — do not move. Fastmail's server-side rules have no export format either destination reads; rebuild them as Gmail filters or Exchange mail flow rules.
- Aliases — do not move as a record type, but the addresses can be recreated as Google Groups with "send as" or Microsoft 365 proxy addresses.
- Masked Email addresses — do not move, and nothing on Workspace or 365 replaces them. More on this below.
Pre-migration checklist#
Do this before you touch a single DNS record. Migrations that skip the inventory step are the ones that surprise someone three weeks later when a client email bounces.
- List every address on the domain: primary mailboxes, shared addresses like support@, and every Masked Email address still in active use.
- Export Fastmail mail via IMAP, and contacts/calendars separately via CardDAV/CalDAV export or Fastmail's built-in export tool.
- Write down every Sieve rule in Settings → Filters & Rules — you will be rebuilding each one by hand on the new side.
- Lower your domain's DNS TTL to 300 seconds a few days ahead, so the eventual MX cutover propagates in minutes instead of up to 48 hours.
- Note your Fastmail renewal date and billing term before you start.
- Decide Workspace or Microsoft 365 first — the admin console, the migration tool and the alias mechanism all differ, and switching mid-migration means redoing work.
Check the renewal date before you migrate, not after
Steps#
- 1
Verify your domain in the new admin console
Add a TXT record to prove domain ownership in Google Workspace Admin or the Microsoft 365 admin center. Do not touch MX yet — verification and mail routing are separate steps, and mail should keep flowing to Fastmail while you set up.
- 2
Run the mail migration
On Workspace, use the Data Migration Service with Fastmail's IMAP host and an app password. On 365, use the Exchange admin center's IMAP migration batch, pointed at the same host. Both copy messages without deleting the Fastmail copy, so you can run the batch more than once to catch new mail before cutover.
- 3
Export and reimport contacts and calendars
Export from Fastmail as vCard (contacts) and ICS (calendars), then import into Google Contacts/Calendar or Outlook. Recurring events usually survive; RSVP status on individual invites sometimes doesn't, so recheck anything time-sensitive.
- 4
Rebuild aliases
On Workspace, recreate each Fastmail alias as a Google Group with "send as" enabled for the right people, or as an additional address on a user. On 365, add each one as a proxy address on the relevant mailbox.
- 5
Rebuild your Sieve rules
Recreate each rule as a Gmail filter or an Exchange mail flow rule. This is manual on both sides — there's no automated converter — so budget real time for it if you have more than a handful of rules.
- 6
Cut over DNS
Update MX to the new provider, and update SPF, DKIM and DMARC to authorize the new sending servers. With TTL already lowered, most mail servers pick up the change within minutes; a small share can take a few hours.
- 7
Re-authenticate every connected app
Anything that logged into the Fastmail mailbox directly — a mail client, a calendar sync, an AI tool connected over IMAP — needs new credentials against the new host. Fastmail app passwords stop working the moment you cancel the account, not before, so this step has no hard deadline until then.
- 8
Leave Fastmail running until you've verified everything
Keep the subscription active through at least one full week of normal mail volume on the new provider before you cancel. This is what makes the rollback plan below actually usable.
What breaks#
Concede this one outright: Masked Email is the single feature this migration cannot replace. Neither Google Workspace nor Microsoft 365 ships anything like it — no per-signup disposable address, no one-click disable when a site starts spamming. If Masked Email is why you liked Fastmail, moving to either destination is a real trade-off, not a rounding error.
Everything else below has a workaround. This one doesn't.
| What | What happens | Fix |
|---|---|---|
| Masked Email addresses | Stop working entirely once Fastmail mail delivery is cut over; nothing on Workspace or 365 replaces the mechanism | Before migrating, check which live signups use a masked address and update them to a real one you'll keep |
| Sieve rules | Do not export in any format the new provider reads | Rebuild manually as Gmail filters (Workspace) or mail flow rules (365) |
| Aliases | No direct equivalent record on either destination | Recreate as Google Groups with "send as" (Workspace) or proxy addresses (365) |
| Nested IMAP folders | Fastmail's folder hierarchy doesn't always map cleanly onto Gmail's flat label model | Review label structure after import; flatten or rename where the hierarchy got lost |
| Calendar invite status | CalDAV/ICS export can drop RSVP metadata on individual invites | Re-send invites for upcoming recurring meetings after the calendar import |
| Third-party app passwords | Stop working the moment the Fastmail account is cancelled | Re-authenticate every connected app against the new provider before cancelling |
Don't cancel Fastmail on cutover day
Rollback plan#
A migration that can't be undone is a migration you'll do once and regret. Build the rollback in before you need it, not after mail starts bouncing.
Because you lowered the TTL in advance, reverting MX back to Fastmail's values is fast if something goes wrong in the first few days — most resolvers pick up the reversal within the same short window as the original change.
- Keep Fastmail's subscription active and the mailbox untouched until you've verified a full week of normal mail on the new provider.
- Don't delete Fastmail's copy of anything until the corresponding data has been confirmed present on Workspace or 365 — migration tools copy rather than move, so this check costs nothing but time.
- Keep the old MX, SPF and DKIM values written down somewhere outside your DNS provider's undo history, in case you need to paste them back manually.
- If a rollback becomes necessary, revert DNS first, then re-enable any Fastmail-side routing you'd paused — don't try to fix the new provider's config while mail is actively failing.
Doing it without downtime#
The trick is that mail migration and mail cutover are two different events, and treating them as one is what causes an outage.
Run the IMAP migration into Workspace or 365 while MX still points at Fastmail. Nothing about copying messages requires mail to stop arriving at the old address. Re-run the migration batch once or twice over a few days to pick up anything that landed since the first pass, so the two mailboxes stay in sync right up to cutover.
Only flip MX once the copy is current, aliases are rebuilt, and at least one full mailbox has been spot-checked on the new side. With a low TTL already in place, the switch itself is a DNS propagation window measured in minutes for most senders, not a maintenance window you need to announce.

Where AI Emaily fits after the migration#
Moving to Workspace or 365 fixes the admin layer — shared drives, SSO, a directory. It does nothing about the actual volume in the inbox once the mail lands there, which is a different problem than the one this migration solves.
We build AI Emaily, an AI email client that connects to Gmail and Outlook accounts — including Workspace and Microsoft 365 mailboxes — and triages, drafts and closes loops on top of whichever one you migrate to. Copilot mode means nothing sends without your approval, every agent action has an undo, and drafting voice comes from a Personal Context brain and per-client profiles you set, not from a model reading your sent mail.
We don't do the migration itself, and we're not an admin console — Workspace and 365 own that job. There's a 7-day free trial on Pro and Autopilot, card required, no permanent free tier.

Frequently asked
See it in AI Emaily
Keep reading

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.