Google Workspace split-delivery migration

A step-by-step guide for migrating a team off Google Workspace onto Cirrux gradually, without moving the primary MX records up front.

The core idea: the team keeps Google Workspace as the authoritative inbox for domain.com(MX stays on Google), and a copy of each user’s mail is routed into Cirrux via a subdomain whose MX points at Cirrux. Google forwards each mailbox to its counterpart on the subdomain, Cirrux accepts it, and because every Cirrux mailbox owns an address on both the main domain and the subdomain, users can already send and receive as their real domain.com address from within Cirrux. When the team is confident, the main-domain MX cutover is a small, reversible final step.

This de-risks the migration: nothing breaks on day one, both systems run in parallel, and rollback is just “stop forwarding.”

Concepts

The moving parts

Main domain — the team’s real domain, e.g. domain.com. Its MX records stay on Google for now.
Cirrux subdomain — a subdomain added purely to receive forwarded mail, e.g. cirrux.domain.com. Its MX records point at Cirrux. Pick a subdomain that won’t collide with anything the team already uses.
Mailbox address— an email address attached to a Cirrux mailbox. A single mailbox can own multiple addresses across multiple domains. Each mailbox gets an address on both the main domain and the subdomain.
Split delivery— both Google and Cirrux end up with a copy of inbound mail. Cirrux’s spam filter already recognises Google Workspace split-delivery forwarding and skips the envelope-from / domain-mismatch penalty for authenticated forwarders.

How mail flows during the parallel phase

                    ┌─────────────────────────────────────┐
  sender ──MX──▶    │  Google Workspace (domain.com)       │
                    │  user@domain.com  ── forward rule ─┐ │
                    └────────────────────────────────────┼─┘
                                                          │
                                       forwards to        ▼
                              user@cirrux.domain.com  ──MX──▶  Cirrux
                                                                  │
                                              resolves to mailbox via
                                              MailboxAddress (subdomain)
                                                                  ▼
                                                         Cirrux mailbox
                                              (also owns user@domain.com,
                                               so it can send as the real
                                               address, accepted by others)

Inbound: sender → Google (MX) → forward rule → user@cirrux.domain.com(MX → Cirrux) → resolved to the Cirrux mailbox.
Outbound from Cirrux: the user sends as user@domain.com. Because the main domain’s SPF/DKIM are configured for Cirrux (Phase 2), receiving servers accept it.
Google keeps its own copy in the original mailbox, so nothing is lost and the team can fall back at any time.

Prerequisites

Before you begin

You have admin access to the team’s DNS (for both the main domain and the subdomain).
You have Google Workspace super admin access (needed to set forwarding policy).
DNS TTLs on the main domain are reasonably low (helps the eventual cutover; not blocking for the parallel phase).

Migration phases

Create the Cirrux workspace and add both domains

Create the workspace for the team in Cirrux (via /admin/workspaces or the normal onboarding flow).

Add the main domain (domain.com). Do notchange its MX records yet — they stay on Google. The main domain is added so Cirrux can own the sending identity (SPF/DKIM/DMARC) and so mailboxes can hold a @domain.com address.

Add the Cirrux subdomain (cirrux.domain.com, or your chosen subdomain). This is the domain whose MX will point at Cirrux so it can actually receive the forwarded mail. Enable auto-alias members for the subdomain: whenever a new mailbox is created for the main domain, it will automatically add a mailbox address for the subdomain.

Why two domains? You can’t point domain.com’s MX at Cirrux without breaking Google delivery. The subdomain gives Cirrux a real inbound path (MX → Cirrux) while the main domain stays on Google.

Configure DNS

A domain becomes active in Cirrux only when ownership, SPF, DKIM, and DMARC all pass. MX is allowed to stay in a warning state for split delivery.

Subdomain DNS (cirrux.domain.com)

MX → point at Cirrux (smtp.cirrux.co). This is what makes Cirrux receive the forwarded mail.
Ownership TXT → cirrux-verification=<token> from the Cirrux domain page.
SPF → v=spf1 include:_spf.cirrux.co ~all.
DKIM→ publish the CNAME records Cirrux generates for the subdomain.
DMARC → _dmarc.cirrux.domain.com TXT starting with v=DMARC1.
Confirm the subdomain reaches active status in the admin panel.

Main domain DNS (domain.com)

MX → leave on Google.Cirrux will report this domain’s MX as a warning(non-Cirrux MX present) — that’s expected and fine for split delivery.
Ownership TXT → cirrux-verification=<token> from the Cirrux domain page.
SPF → add Cirrux to the existing record so mail sent from Cirrux as @domain.com passes SPF. Keep Google’s include too while both systems send: v=spf1 include:_spf.google.com include:_spf.cirrux.co ~all.
DKIM→ publish Cirrux’s DKIM CNAMEs for the main domain (Cirrux uses its own selectors, so they coexist with Google’s DKIM).
DMARC→ ensure a DMARC record exists; if tightening policy, do it cautiously while two senders are active.
Confirm the main domain reaches active (MX warning is acceptable).

The point of configuring the main domain’s SPF/DKIM in Cirrux is outbound: it lets users send from Cirrux as their real user@domain.com and be accepted by receiving servers, even though inbound MX still points at Google.

Create mailboxes with dual-domain addresses

Do this for one pilot mailbox first, validate the whole loop, then repeat for the rest of the team.

Create the Cirrux mailbox for the user (e.g. via the workspace member flow).
Ensure the mailbox has both user@cirrux.domain.com and user@domain.com addresses linked.

A single mailbox holding addresses on multiple domains is a first-class capability. Mail addressed to either the subdomain or the main domain resolves to the same mailbox.

Configure forwarding in Google Workspace

The goal: mail arriving at user@domain.com in Google is forwarded to user@cirrux.domain.com, so Cirrux receives a copy while Google keeps the original.

Pilot (single mailbox) approach — recommended starting point

Open admin.google.com.
Go to Apps → Google Workspace → Gmail.
Open Default Routing, then Configure.
Type the address of your single mailbox, e.g. user@domain.com.
Select Forward and enter user@cirrux.domain.com.
Send a test mail to user@domain.com and confirm it lands in both Google and the Cirrux mailbox.

Org-wide approach (later, once the pilot is validated)

Use a Google Workspace routing / content-compliance rule(Admin Console → Apps → Google Workspace → Gmail → Routing) to forward mail for a group/OU to the corresponding @cirrux.domain.com address.
Decide scope: a single OU, a group, or the whole domain.

Also relevant: Google’s split-delivery documentation.

Validate the parallel phase

Inbound: external mail to user@domain.com appears in Cirrux (via the subdomain forward) and in Google.
Outbound: a mail sent from Cirrux as user@domain.comis accepted by an external provider (check it doesn’t land in spam — confirm SPF pass and DKIM pass in the received headers).
Cirrux does not flag the forwarded mail as spam (the split-delivery rule should handle the Google forwarder).
Repeat for a few more mailboxes before scaling to the whole team.

Scale-out conveniences

Single Sign-On (Google Workspace as IdP)

Set up OIDC SSO so users sign into Cirrux with their Google Workspace identity. Follow the dedicated SSO setup guide for the Cirrux-side steps (create connection, set default domain, activate, test), including the Google issuer-trailing-slash gotcha.

Workspace-level Google sync (history + ongoing sync)

To transfer all existing mail (and contacts/calendar) from Google and keep it in sync — instead of forwarding only new mail — use Google Sync. Decide whether the pilot needs historical mail now, or whether forward-only is enough for the parallel phase.

Cut over (when the team is ready)

Confirm all mailboxes exist in Cirrux with both addresses, and users are comfortable in Cirrux.
If using workspace-level Google sync, confirm history is imported and current.
Lower the main domain’s MX TTL ahead of time.
Switch domain.com’s MX records to Cirrux (smtp.cirrux.co).
Remove the Google forwarding rules (no longer needed, Cirrux now receives directly).
Tighten SPF: drop Google’s include once Google no longer sends for the domain.
Monitor for bounces / routing issues during DNS propagation.
Keep the Google Workspace accounts around briefly as a safety net before decommissioning.

Rollback before cutover is trivial: disable forwarding and users keep using Google. After cutover, rollback means pointing MX back at Google.

Troubleshooting

Forwarded mail flagged as spam in Cirrux

Confirm the Google forwarder is authenticated; the split-delivery rule should skip the domain-mismatch penalty. Check the received headers for the forwarding hop.

Outbound @domain.com mail rejected or spam-foldered

Verify the main domain shows SPF valid and all DKIM keys valid in the admin panel, and that the receiving server sees dkim=pass.

Main domain stuck not active

MX in warning is expected (it points at Google); the blocker is usually ownership TXT, SPF, DKIM, or DMARC. Check each in the domain settings.

Forwarded mail doesn't arrive in Cirrux

Verify the subdomain’s MX points at Cirrux and the mailbox actually owns the @cirrux.domain.com address (the resolver needs an exact mailbox-address match, or a domain catch-all).

User can't send as their real address

Confirm the mailbox owns the @domain.com address, not just the subdomain one.

In short

Both systems run side by side throughout the migration. Google stays authoritative until you’re confident in Cirrux, every Cirrux mailbox can already send and receive as its real address, and the final MX cutover is a small, reversible step.