Answer first: Changing MX routes new inbound mail only. It does not move historical mailboxes. Lower MX TTL (commonly to 3,600 seconds or less), wait for the previous TTL to expire, copy history while the old provider is still live, then cut over. Keep the old mailbox online through the cache window. Rollback is the same process in reverse—and it is also cached.
The problem a generic “export then import” article misses
The dangerous window is not the export. It is the hours when some senders still have cached MX while you are changing identities, aliases, SPF, DKIM, DMARC, and outbound SMTP. Mail arrives in two places. SPF lookup counts climb. A role address exists on one side only. Someone turns off the old provider too early and the tail of mail disappears.
This is a cutover runbook, not a file-copy tutorial. Provider-specific export quirks belong in source articles such as moving off Google Workspace.
Before cutover: inventory and destination readiness
- List every mailbox, alias, shared address, catch-all, forwarder, autoresponder, and plus-address pattern. See aliases and shared inboxes and catch-all behavior.
- List application senders: SMTP hosts, API keys, WordPress/WooCommerce plugins, cron jobs, and “forgot password” From addresses.
- Note calendars, contacts, and shared drives that live outside IMAP. IMAP copies folders and messages; it does not migrate every collaboration object.
- Decide retention: what must exist on day one versus what can stay archived on the old provider.
- Stand up the destination first: users, role addresses, domain verification, and authentication records ready but not yet conflicting.
DNS timing: TTL is not a global countdown
Resolvers cache MX independently. Lower the current MX TTL to 3,600 seconds or less, then wait at least as long as the previous TTL before the final change. If MX was cached for 24 hours yesterday, waiting one hour today is not enough.
- Snapshot the old zone (MX, SPF/TXT, DKIM, DMARC, autodiscover/autoconfig if present).
- Do not claim a fixed “propagation time” for every resolver.
- Keep mail hostnames DNS-only when a proxy would break SMTP or MX.
Exact ArawaMail record shapes live on the DNS records reference. Connecting the zone is covered in Connect a Cloudflare domain.
SPF during overlap: do not stack two vendors blindly
Two include: mechanisms plus lookups inside those includes can exceed the SPF 10-DNS-lookup limit and produce PermError. Prefer one outbound path per From domain during cutover, or split human mail and app mail the way two vendors, one From address describes. Confirm DMARC alignment on both SPF and DKIM after the change—not just an SPF pass.
Copy history before you flip MX
Use IMAP or a provider export while the old system still receives mail. Document what will not migrate. Prefer IMAP over POP3 if you need folders and server-side state; see IMAP vs POP3.
ArawaMail does not document an IMAP migration wizard, automatic historical import, or a one-click DNS rollback product. Plan the copy with your own tools.
During cutover
- Change MX at the destination. On ArawaMail, receiving must be active before mailbox accounts can be created. Activate receiving publishes MX and asks for confirmation before replacing existing MX. Unlock or disable Cloudflare Email Routing first if Routing owns
route1/2/3.mx.cloudflare.net. - Verify MX from more than one resolver.
- Send test mail to exact mailboxes, aliases, and role addresses. Watch the old provider for the cached tail.
- Activate sending only after receiving is live. ArawaMail sending adds DKIM CNAMEs and custom MAIL FROM MX/SPF in Cloudflare. Sending requires receiving first.
- Test outbound from humans and from apps independently. Confirm Reply-To and Return-Path still make sense.
Catch-all on ArawaMail is one active mailbox per domain. Delivery order is exact mailbox, then catch-all, then discard. Forwarding keeps a local copy and sends a copy to a verified destination; destination limits follow the plan (Free 1 / Pro 5 / Business 10) and forwarded copies count toward the transactional allowance.
Rollback triggers (write these down before you cut)
- Inbound mail missing on the new MX after you have waited a full prior-TTL window and confirmed resolvers see the new records.
- SPF PermError or DMARC fail on production From addresses.
- Application SMTP/API send failures that you cannot fix without restoring the old path.
Rollback means publishing the snapshotted MX (and matching SPF/DKIM if you changed them) and waiting out cache again. Keep the old provider billed and accepting mail until the tail is quiet.
After the tail is quiet
- Restore normal TTLs.
- Decommission the old provider only when new mail has stopped arriving there.
- Rotate any SMTP passwords or API keys that still pointed at the old host.
- Point devices at the new IMAP/SMTP values from the provider’s connect-device screen. Do not invent hostnames.
How we analyzed this
The runbook is built from DNS cache behavior, Microsoft-style TTL guidance for MX cutover, SPF lookup arithmetic, and ArawaMail’s published onboarding order: Cloudflare zone match, unlock Email Routing, activate receiving (MX), create accounts, activate sending (DKIM and custom MAIL FROM). Claims about ArawaMail stop at those docs. No import wizard was assumed.
FAQ
Will changing MX move my old emails?
No. MX only steers new inbound mail. Copy history separately.
How far ahead should I lower TTL?
Lower it, then wait at least the previous TTL before cutover. If the old TTL was 24 hours, wait 24 hours after publishing 3,600 seconds.
How do I avoid SPF PermError during overlap?
Do not stack two full vendor includes if the combined lookup graph exceeds 10. Flatten, split subdomains, or send from one vendor until cutover completes.
What does an ArawaMail cutover change?
Confirmed MX replacement for receiving, then sending records. It does not automatically copy mailbox history.
Can I roll back instantly?
You can republish old MX immediately. Resolvers that still cache the new MX will lag. That is why the old provider must stay live.