Microsoft 365 split-delivery migration

A step-by-step guide for migrating a team off Microsoft 365 / Exchange Online onto Cirrux gradually, without moving the primary MX records up front.

The core idea is identical to the Google Workspace guide: the team keeps Microsoft 365 as the authoritative inbox for domain.com (MX stays on M365), and a copy of each user’s mail is routed into Cirrux via a subdomain whose MX points at Cirrux. M365 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.”

The big difference from Google: Cirrux has no Microsoft 365 sync, for a whole tenant or for a single user. History migration is manual and per-user using Cirrux’s built-in IMAP, VCF and ICS importers (Phase 6). Mail comes over IMAP; contacts and calendar are exported from M365 and uploaded.

Concepts

The moving parts

Main domain: the team’s real domain, e.g. domain.com. Its MX records stay on Microsoft 365 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 M365 and Cirrux end up with a copy of inbound mail. Cirrux’s spam filter trusts Microsoft’s ARC seal on forwarded mail, so a message forwarded by M365 keeps the authentication results it had when Microsoft received it and isn’t treated as forged.

How mail flows during the parallel phase

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

Inbound: sender → M365 (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.
M365 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 Microsoft 365 Global admin (or Exchange admin) access (needed to set forwarding and, later, SSO).
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 by signing up at account.cirrux.co, or ask your Cirrux contact to set it up for you.

Add the main domain (domain.com) under Domains in the admin app at admin.cirrux.co. Do not change its MX records yet: they stay on M365. 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. Ask Cirrux support to turn on auto-alias members for the subdomain (it is not a setting in the admin app). With it on, every new member you add on the main domain automatically gets an address on the subdomain as well.

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

Configure DNS

A domain becomes active in Cirrux only when ownership, SPF, DKIM and DMARC all pass and its MX includes Cirrux. For the subdomain that is the goal. The main domain stays pending until the cutover, because its MX still points only at M365. That is expected and does not stop you from sending as @domain.com from Cirrux.

A new domain starts as a draft and is not checked. Once the records are in, click Check this domain at the bottom of the domain page, for both domains. Until then every record shows as not checked, however correct it is.

Copy each record from the domain page. For the subdomain, every host name includes the subdomain (e.g. cirrux.domain.com. for the ownership TXT), not the bare main domain. Most DNS providers want the trailing dot, and MX needs a priority; the domain page explains both.

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 on its domain page.

Main domain DNS (domain.com)

MX → leave on Microsoft 365 (<tenant>.mail.protection.outlook.com). Cirrux will report this domain’s MX as not pointing at Cirrux. That’s expected 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 Microsoft’s include too while both systems send: v=spf1 include:spf.protection.outlook.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 Microsoft’s DKIM (selector1 / selector2._domainkey).
DMARC → ensure a DMARC record exists; if tightening policy, do it cautiously while two senders are active.
Confirm ownership, SPF, DKIM and DMARC show as valid for the main domain. The domain itself stays pending because of the MX.

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 M365.

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.

Add the user as a member in the admin app (Users → Add member), which creates their Cirrux mailbox.
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 Microsoft 365

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

Pilot (single mailbox) approach, the recommended starting point

Open the Exchange admin center.
Go to Recipients → Mailboxes.
Select the pilot user’s mailbox, e.g. user@domain.com.
Open the Mailbox tab → Manage email forwarding.
Enable Forward all emails sent to this mailbox and enter user@cirrux.domain.com.
Tick Keep a copy of forwarded messages so M365 retains the original as fallback.
Send a test mail to user@domain.com and confirm it lands in both M365 and the Cirrux mailbox.

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

Use an Exchange mail flow rule (Exchange admin center → Mail flow → Rules) to Bcc / redirect mail for a group to the corresponding @cirrux.domain.com address.
Decide scope: a single distribution group, a security group, or the whole domain.

Microsoft 365 blocks automatic external forwarding by default (Defender outbound anti-spam policy). If forwarded mail never reaches Cirrux, you likely need to allow it (see Troubleshooting). Mail flow rules are not subject to the same block.

Also relevant: Microsoft’s mail-flow documentation.

Validate the parallel phase

Inbound: external mail to user@domain.com appears in Cirrux (via the subdomain forward) and in M365.
Outbound: a mail sent from Cirrux as user@domain.com is accepted by an external provider (check it doesn’t land in spam, and confirm SPF pass and DKIM pass in the received headers).
Cirrux does not flag the forwarded mail as spam (Microsoft’s ARC seal on the forward should cover it).
Repeat for a few more mailboxes before scaling to the whole team.

Known limitation: mail sent from Cirrux does not show up in Sent Items in Outlook. Cirrux only receives a copy from M365 via the forward; it never writes back into the M365 mailbox. Tell users up front that during the parallel phase their sent mail lives in Cirrux.

History migration: manual IMAP + VCF + ICS import

There is no M365 sync. Migrate existing data per-user with Cirrux’s built-in importers in Settings → Sync & Import. Do this for the pilot user first, validate, then repeat.

Mail: IMAP importer

Generate an app password for the M365 mailbox (the IMAP importer is username/password only and does not do OAuth, so a normal password won’t work when MFA is on). Ensure IMAP is enabled for the mailbox in M365.
Click Connect IMAP account in Settings → Sync & Import with host outlook.office365.com, port 993 with SSL on, username user@domain.com and the app password. Pick the user’s Cirrux mailbox as the destination.
Cirrux discovers the folders. Enable the folders to import. The folder structure becomes labels, and Inbox, Sent Items, Deleted Items, Junk Email and the like map to the built-in Cirrux folders.
Click Start import and follow progress on the import page. Failed messages are retried when you run the import again, and Import new emails fetches mail that arrived after the first run.

See the IMAP import guide for full details.

Contacts: VCF importer

Export contacts from Outlook on the web (it exports .csv) and convert them to a .vcf (vCard) file, since Cirrux imports contacts from vCard only.
Upload it with Upload VCF file, choosing the destination address book. A card that can’t be read is skipped rather than aborting the whole import.

Calendar: ICS importer

Export the calendar from Outlook on the web as an .ics file.
Upload it via the Cirrux ICS import flow, choosing the destination calendar.

These importers copy what is there when you run them; nothing syncs continuously. Run them close to cutover (or use Import new emails on the IMAP import) so the gap between the last import and cutover is small. New mail in that gap still arrives via the Phase 4 forwarding.

Scale-out: Single Sign-On

Set up OIDC SSO so users sign into Cirrux with their Microsoft Entra ID (Azure AD) identity. Follow the dedicated SSO setup guide for the Cirrux-side steps (create connection, set default domain, activate, test).

On the IdP side, register an app in Entra ID, use issuer https://login.microsoftonline.com/<tenant-id>/v2.0, and add the Cirrux callback URL as a redirect URI.

Cut over (when the team is ready)

Confirm all mailboxes exist in Cirrux with both addresses, and users are comfortable in Cirrux.
Run Import new emails one last time (and upload fresh VCF/ICS exports) so recent history is captured.
Lower the main domain’s MX TTL ahead of time.
Switch domain.com’s MX records to Cirrux (smtp.cirrux.co).
Remove the M365 forwarding rules (no longer needed, Cirrux now receives directly).
Tighten SPF: drop Microsoft’s include once M365 no longer sends for the domain.
Monitor for bounces / routing issues during DNS propagation.
Keep the Microsoft 365 mailboxes around briefly as a safety net before decommissioning.

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

Troubleshooting

Forwarded mail never reaches Cirrux

M365 blocks automatic external forwarding by default. In the Microsoft 365 Defender portal, check the outbound spam filter policy (Email & collaboration → Policies → Anti-spam → Outbound) and allow automatic forwarding for the relevant users, or use a mail flow rule (which is not subject to the same block) instead of mailbox forwarding.

IMAP import fails to authenticate

Confirm IMAP is enabled for the mailbox, that you’re using an app password (not the account password) when MFA is on, and host/port outlook.office365.com:993 with SSL.

Forwarded mail flagged as spam in Cirrux

Check the received headers for the forwarding hop and confirm Microsoft added an ARC seal whose results say dmarc=pass. Without that, the forward is judged on its own authentication.

Outbound @domain.com mail rejected or spam-foldered

Verify the main domain shows SPF valid and all DKIM keys valid on its domain page, and that the receiving server sees dkim=pass.

Records are in DNS but nothing gets verified

The domain is probably still a draft. Click Check this domain at the bottom of the domain page.

Main domain stuck on pending

That is expected until the cutover, because its MX points at M365. Check that ownership TXT, SPF, DKIM and DMARC are each valid on the domain page. Those are the records that matter for sending.

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 (mail is only accepted for an address a mailbox owns, or by 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. M365 stays authoritative until you’re confident in Cirrux, every Cirrux mailbox can already send and receive as its real address, history comes across with the IMAP/VCF/ICS importers, and the final MX cutover is a small, reversible step.