Moving from a free Gmail address to a real you@yourcompany.com on Google Workspace is a well-defined process with a handful of steps that, done in the right order, involve almost no downtime.

Step 1: Domain Verification

Google requires proof you control the domain before creating any mailboxes on it — typically by adding a specific TXT record to your domain's DNS, which Google's setup wizard generates for you. This step alone doesn't affect existing email; it's purely a domain-ownership check.

Step 2: Create Your User Accounts

Add each staff member as a Workspace user with their intended address (name@yourcompany.com) before touching MX records — this way, accounts exist and are ready to receive mail the moment the cutover happens, rather than scrambling to create them after mail starts arriving with nowhere to land.

Step 3: Add the MX Records

This is the actual cutover moment: replacing your domain's current MX records with Google's specified set (typically a single record pointing to Google's mail servers) tells the internet to start routing your domain's mail to Workspace instead of wherever it was going before. DNS changes propagate gradually, typically within a few hours, occasionally up to 24-48 hours depending on your domain's DNS TTL settings.

Step 4: Migrate Historical Mail (If Needed)

If you're moving from an existing mailbox (cPanel webmail, another provider), Google's Data Migration tool can pull historical mail via IMAP into the new Workspace mailbox, so past correspondence isn't lost in the switch. This step can run in parallel with the MX cutover rather than blocking it.

Step 5: Add SPF, DKIM and DMARC

Beyond MX records, Google provides specific SPF and DKIM values to add to your DNS — skipping this step is the most common reason a freshly set-up Workspace domain has deliverability problems immediately after launch, since outgoing mail won't be properly authenticated without it.

What This Actually Costs

Google Workspace bills per user per month at international rates; Nepal-based resellers can typically provide the subscription with local invoicing, and the domain itself (if you don't already own one) is a separate, usually small annual cost. Budget for the subscription as an ongoing monthly line item, not a one-time setup fee — the setup itself is a few hours of configuration work, not a recurring cost.

What Commonly Goes Wrong

  • MX records added correctly but SPF/DKIM skipped, causing outgoing mail to land in recipients' spam.
  • Old email forwarding rules on the previous mail system left active, silently duplicating or misdirecting mail during the transition.
  • Staff not told the cutover date, continuing to check an old webmail interface that no longer receives new mail.

Communicating the cutover date internally and confirming SPF/DKIM alongside MX records avoids the two most common self-inflicted problems in this process.

Handling the Transition Period Gracefully

During DNS propagation (the few hours after MX cutover), some senders' mail servers may still be routing to the old destination briefly — this is normal and usually resolves itself within the propagation window. If your previous email system remains accessible during this window, checking it once for any mail that arrived there during the transition, rather than assuming the cutover was instantaneous, catches the rare message that landed in the wrong place during the switch.