How to migrate your team off Google Workspace email

Google Workspace email is fine until the per-seat bill, the data-residency questions, and the "we can't actually see our own raw mail" problem stack up. Then you want out, and the migration is the scary part.

Google Workspace is a genuinely good product. Gmail's spam filtering is excellent, the uptime is better than most teams can match, and the admin console is mature. None of that is in dispute. The reasons to leave are about ownership and cost, not quality: per-seat billing that scales with headcount whether or not those seats send much mail, subscriber and message data that lives on Google's terms in Google's regions, and a black box where you cannot inspect or replay how your own mail was handled. For a privacy-conscious team or a CTO answering data-residency questions in an audit, those are real. If you are still weighing the destination rather than the mechanics, the ways to move your team off Google Workspace email lay out the routes at a higher level before you commit to the steps below.

This guide walks the migration the honest way: every export, every DNS change, every gotcha that loses mail if you skip it. It is written so you could do the whole thing with open tools and no vendor. At the end, where it makes sense, we show where a self-contained stack like Tinbox removes the standing-up-the-destination half of the work. The migration mechanics are the same regardless of where you land.

What does a Google Workspace email migration actually involve?

A Workspace email migration is three independent jobs that people conflate: moving the historical mail, moving inbound delivery (MX), and moving outbound authentication (SPF/DKIM/DMARC). Each has its own failure mode, and the order matters.

1. Historical mail. Years of existing messages and folders, pulled out of each mailbox before you cut anything over. This is bandwidth-bound and slow, so it runs first and runs long.
2. Inbound delivery. The MX records that decide where new mail lands. Flip these and new mail goes to the new host. Flip them carelessly and mail bounces or vanishes during DNS propagation.
3. Outbound authentication. SPF, DKIM, and DMARC, which decide whether your sent mail is trusted. Move these wrong and your team's outgoing mail starts going to spam, which is worse than a brief inbound hiccup because it is silent.

The thing that loses mail is treating this as one big switch. You do not flip MX and start exporting; you export almost everything first, flip MX, then export the small remainder. That ordering is the single biggest of the email migration mistakes that tank your deliverability, and the rest of that list is worth scanning before you touch a single DNS record. The sections below take each job in turn.

How do I export every mailbox out of Google Workspace?

Export each mailbox over IMAP with imapsync or offlineimap, which preserves folders, read state, and timestamps; use Google Takeout mbox only as a full-archive fallback. IMAP is the right tool because it is incremental: you can run it days ahead, then run it again at cutover to catch just the delta.

First, enable access. For each account, IMAP must be on and the sync tool needs credentials. For a handful of mailboxes, per-user app passwords are simplest. For a larger org, set up a service account with domain-wide delegation so you authenticate to every mailbox with one credential instead of chasing each user.

In Gmail: Settings → Forwarding and POP/IMAP → Enable IMAP. Then create an app password under the Google Account security page (requires 2FA on the account).

Now run the sync. imapsync copies mailbox-to-mailbox if your destination already speaks IMAP:

imapsync \
  --host1 imap.gmail.com --port1 993 --ssl1 \
  --user1 jane@yourdomain.com --password1 "APP_PASSWORD_HERE" \
  --host2 mail.newhost.com --port2 993 --ssl2 \
  --user2 jane@yourdomain.com --password2 "DEST_PASSWORD" \
  --automap --useheader 'Message-Id' --skipcrossduplicates

--automap matches Gmail's labels to destination folders, --useheader 'Message-Id' deduplicates on a stable header so re-runs don't double-import, and --skipcrossduplicates handles Gmail's habit of showing one message under several labels.

If you don't have an IMAP destination yet, pull to local maildir with offlineimap instead, and import later:

# ~/.offlineimaprc
[Repository gmail-jane]
type = Gmail
remoteuser = jane@yourdomain.com
remotepass = APP_PASSWORD_HERE
sslcacertfile = /etc/ssl/cert.pem

offlineimap -a jane

Expect this to be slow. Gmail throttles IMAP aggressively: you will see Limit exceeded and Lookup failed errors on big mailboxes, and the connection drops. Both tools retry, but a 30 GB mailbox can take all night. Run exports in parallel across users, not serially, and start days before cutover so the bulk transfer is done before you touch DNS.

The blunt fallback is Google Takeout: select Mail, get a per-account mbox. It's complete and needs no IMAP credentials, but an mbox is a flat file with no live sync, so you cannot use it for the incremental delta at cutover. Treat Takeout as the belt-and-suspenders full archive, not the migration mechanism. If you go this route, see importing a Google Takeout mbox into your own inbox for the parsing details.

What gets lost that IMAP and Takeout don't carry?

IMAP and mbox carry message bodies, attachments, and folder structure, but they do not carry filters, forwarding rules, vacation responders, contacts, calendar, or Drive files. These live in separate Google products and each needs its own export. Skip this and users arrive at a new mailbox with their mail but none of their automation.

Data	Lives in	Export path	Carried by IMAP?
Messages + attachments	Gmail	IMAP / Takeout mbox	Yes
Labels / folders	Gmail	IMAP (--automap)	Mostly
Read/unread, flags	Gmail	IMAP	Yes
Filters / rules	Gmail settings	Export filters to XML	No
Vacation responder	Gmail settings	Manual note	No
Contacts	Google Contacts	CSV / vCard export	No
Calendar	Google Calendar	ICS export	No
Drive / shared files	Google Drive	Download / Takeout	No

For mail specifically, the one that bites is filters. Export them from Gmail (Settings → Filters and Blocked Addresses → Select all → Export) to an XML file per user, so you can re-create the routing logic on the new system instead of rebuilding it from memory. Contacts and calendar are separate jobs; don't let them block the mail cutover, but don't forget them either, because a CTO who migrates mail and orphans the shared calendar has not actually finished.

How do I repoint MX without losing inbound mail?

Lower the MX record TTL to 300 seconds at least a day before cutover, then repoint MX to the new host so the change propagates in minutes instead of hours. The mail-loss risk is entirely in the propagation window, and a low TTL shrinks it.

Walk the sequence precisely:

Day before. Drop the TTL on your MX records to 300. TTL changes themselves are subject to the old TTL, so if your MX TTL was 3600, you must lower it at least an hour ahead for the low value to take effect. A full day of lead time is safe.

# Before (typical Workspace default)
yourdomain.com.  3600  IN  MX  1  aspmx.l.google.com.

# Day before cutover: same target, short TTL
yourdomain.com.  300   IN  MX  1  aspmx.l.google.com.

Cutover. Replace the MX records with the new host's targets:

yourdomain.com.  300  IN  MX  10  mx.newhost.com.

The moment this propagates, new inbound mail flows to the new system. The old Gmail mailbox keeps working: messages sitting there are still reachable over IMAP, which is what you need for the next step. Do not delete anything in Workspace yet.

Final delta sync. Some mail will have landed in Gmail during the minutes of propagation. Run imapsync one more time per mailbox. Because you used --useheader 'Message-Id', it imports only the new messages and skips everything already copied. This is the step people forget, and it is exactly the mail that goes missing if you skip it.

Verify inbound before moving on. Send a test from an outside address (a personal account, a phone on cellular) and confirm it arrives at the new host, not Gmail. Check the received headers to be sure it took the new MX path.

How do I move SPF, DKIM, and DMARC so sent mail isn't flagged?

Update SPF to authorize the new sender, publish the new host's DKIM public key, and confirm DMARC still aligns, all before you send real volume from the new system. Outbound auth is silent when it breaks: mail goes to spam without a bounce, so you find out from angry colleagues, not error logs.

SPF. Your current record authorizes Google. Replace Google's include with the new sender's mechanism, or add the new one and remove Google once cutover is confirmed:

# Before
yourdomain.com.  TXT  "v=spf1 include:_spf.google.com ~all"

# After (example for a new host)
yourdomain.com.  TXT  "v=spf1 include:_spf.newhost.com ~all"

Keep exactly one SPF record. Two v=spf1 records is a permanent error and fails SPF outright.

DKIM. The new host generates a key pair and gives you a public key to publish at a selector subdomain. Google's DKIM key stays valid for already-sent mail but is irrelevant going forward:

selector._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G...new-public-key..."

DMARC. If you already have a DMARC record, it carries over unchanged, but verify alignment: the new system's From domain, SPF domain, and DKIM d= must all align with yourdomain.com or DMARC fails even when SPF and DKIM individually pass. If you're new to these records, the full SPF, DKIM, and DMARC setup walkthrough covers the syntax and the alignment rules in detail.

Then prove it. Send a test message to a Gmail or Outlook address you control, open it, and check the authentication results in the raw headers: you want spf=pass, dkim=pass, and dmarc=pass. A new sending domain also carries no reputation, so don't blast your full list on day one; ramp gradually. The mechanics of that ramp are covered in the email deliverability guide.

When can I cancel Google Workspace?

Cancel seats only after inbound delivery is verified at the new host, the final delta sync is complete, and a test send passes SPF, DKIM, and DMARC. Keep the subscription active through that verification window so you retain IMAP access for the final sync and a rollback path if delivery breaks.

A concrete checklist before you pull the plug:

• New inbound mail confirmed arriving at the destination (checked via received headers, not just "looks fine").
• Final per-mailbox delta sync run after MX moved, with zero new messages on a repeat run.
• Filters, contacts, and calendar exported and re-created or archived.
• Test send to an external mailbox shows spf=pass, dkim=pass, dmarc=pass.
• DMARC aggregate reports (if enabled) show the new source passing, not a flood of failures.

Give it a week of real traffic before downgrading or canceling. The cost of one extra month of Workspace is trivial against the cost of discovering, after cancellation, that a mailbox didn't fully sync.

Where does Tinbox fit in this migration?

Tinbox replaces the "stand up the destination" half of this migration with one command, then runs as your own self-contained mail stack on your own Cloudflare account. Everything above about exporting, MX, and DNS still applies, because that's how email works regardless of vendor. What changes is that you're not also evaluating, provisioning, and configuring a separate mailbox host to receive the export.

Tinbox is a tenant-deployed email stack: a transactional sender, a newsletter tool, and a human webmail inbox, all running on D1, R2, Queues, and Workers in your Cloudflare account. The data lives in your D1 database, in the region you choose, with no third party holding the mailbox. For the privacy-CTO reasons that drive a Workspace exit in the first place, that's the point: the data-residency answer becomes "it's in our own account," and the audit subprocessor list gets shorter.

Standing up the destination:

npx tinbox init yourdomain.com

✔ Provisioned D1 database (tinbox-yourdomain-db)
✔ Provisioned R2 bucket (tinbox-yourdomain-mail)
✔ Wrote wrangler.jsonc (assets + queue consumer + cron + email handler)

Next: add the printed DNS records (MX, SPF, DKIM, DMARC), then `npx tinbox deploy`.

The bootstrapper prints the exact MX, SPF, DKIM, and DMARC records to publish, which collapses the most error-prone part of this guide into copy-paste. And the historical-mail import isn't a separate vendor tool: Tinbox ships local-fetch importers for Gmail, IMAP, and mbox that pull mail to your machine and bulk-insert it into your own database, so the export and the load are one flow.

Two honest caveats so you plan correctly. First, a Tinbox deploy is scoped to one brand and one domain today. You run many tenants per Cloudflare account by doing separate deploys, one per domain; multi-domain-per-instance is designed but not yet built. If you have several domains, that's several init runs, not one. Second, Tinbox is not a Gmail clone feature-for-feature: it gives you a sender, a newsletter tool, and a webmail inbox over searchable, owned data, not the entire Workspace suite. Calendar, Docs, and Drive are out of scope and you'll keep handling those separately.

If you want the wider context on whether owning the stack is worth the operational tradeoff, the Tinbox overview lays out the whole model. The migration steps in this guide are the durable part; the destination is the part Tinbox makes cheap.

Deploy this yourself: npx tinbox init yourdomain.com. The generated DNS records and the importer docs are the two things to read next.