"Migrate off Gmail" usually means moving mail history and ongoing mail flow for a domain to a server you run — Hexamail Server, Exchange, or another self-hosted platform. It does not automatically include Google Docs/Sheets/Drive collaboration, Google Meet, or the Workspace admin console, which are separate products with their own migration paths if you rely on them; be honest with your team about what you are and are not replacing before you start.
The migration itself has to move: mail history (everything currently in Gmail), ongoing mail flow (new mail arriving after the move), and the DNS records that tell the world where your domain's mail lives now.
Install and configure the new mail server completely before touching DNS — create the domain, mailboxes matching your current Gmail addresses, spam filtering, and TLS certificates. Send and receive a few test messages using a temporary hostname or internal test domain so you know the server itself works before it becomes responsible for real mail.
Copy existing mail from Gmail to the new server over IMAP with OAuth2 while Gmail is still the live system — this can safely run in the background because it reads Gmail's folders/labels without changing MX or removing anything, so nothing breaks if the copy takes a few hours for a large account. IMAP preserves Gmail's label structure as folders on the destination.
Do this per mailbox, and keep a rough count of messages copied so you can sanity-check completeness after the DNS cutover, rather than discovering a gap weeks later.
Once mail history is copied and verified, switch the domain's DNS to point at the new server:
- Update the MX record to point at your new server instead of Google's.
- Update SPF to list your new server instead of (or alongside, during transition) Google's sending infrastructure.
- Set up DKIM signing on the new server and publish its DKIM record — this is a new key, not something you can carry over from Google.
- Review your DMARC record once SPF/DKIM are confirmed working on the new setup.
DNS changes take time to propagate everywhere (commonly minutes to a day depending on record TTLs), during which some senders will still reach Google and others will reach your new server. Plan the cutover for a low-traffic period and expect a short overlap window, not an instant switch.
After the DNS change, keep the Gmail/Workspace account active (read-only is fine) rather than cancelling it immediately:
- Confirm new mail is arriving at the new server by sending test messages from an external account.
- Watch for any mail still arriving at the old Gmail account during the DNS propagation window and reconcile it into the new server manually if needed.
- Only cancel or downgrade the Google Workspace subscription once you have confirmed a period of mail — a week is a reasonable minimum — has flowed correctly through the new server with nothing unexpectedly still landing in Gmail.
Being honest about the gap avoids a bad surprise after the move. A self-hosted mail server replaces mail (SMTP/IMAP), and often webmail and basic calendaring, but it is not automatically a replacement for Google's collaboration suite, spam/security research team, or infrastructure-scale uptime engineering. If your organisation genuinely depends on Docs collaboration, Meet, or the specific abuse-detection scale Google runs at, factor that into the decision separately from the mail-server question — some organisations end up keeping Workspace for collaboration while moving only mail, which is a legitimate outcome, not a failed migration.
Hexamail POP3 Downloader collects mail history from Gmail over IMAP using OAuth2 (not a stored password) and delivers it into Hexamail Server or any SMTP server, making the history-copy step in this guide straightforward. Hexamail Server then becomes the destination mail server, with DKIM signing, spam filtering, and webmail built in. See also the Gmail app password guide if you are on an older setup still using password-based access.