You can leave Google Workspace mail without a panic weekend: inventory every address, lower MX TTL, stand up ArawaMail on Cloudflare in parallel, take MX only when mailboxes exist, and keep the transactional API on the same domain. Calendar and Contacts can stay on Google. History does not auto-import. Dual delivery, if you need it, happens in Google Admin before ArawaMail replaces MX.
This is a mail-only exit, not a Google replacement
Most teams that want to migrate from Google Workspace are not looking for a Docs, Drive, or Meet substitute. They are paying for a suite because they needed custom-domain inboxes and product email. The rest of the bundle became expensive ballast.
Keep that distinction. ArawaMail is business email plus a transactional API on one domain. It is not a calendar suite. Shared Google Calendar and Contacts can stay on personal or leftover Google accounts after mail leaves Workspace. Heavy calendar teams should not be told to abandon Calendar as part of this cutover.
If the question is brand positioning rather than MX steps, read custom-domain business email vs Gmail first. This article is the operational cutover.
What you are actually switching
Google Workspace inbound mail is defined by MX. As of Google Help in late August 2026, the current official record is a single MX: smtp.google.com at priority 1. Recognition of MX changes can take up to 72 hours. Older domains may still carry the legacy five-record ASPMX set (ASPMX.L.GOOGLE.COM and friends). Use one set or the other on Google’s side. Never mix both, and never leave Google MX next to the new provider after cutover.
ArawaMail inbound mail is also defined by MX. Activate receiving publishes ArawaMail’s MX and, if records already exist, shows a confirmation warning before it replaces them. There is no documented dual-MX mode on ArawaMail. If you need a dual-delivery window, configure it in Google Admin before you confirm Activate receiving, or archive another way.
Outbound product mail is a different plane. Sending uses DKIM CNAMEs, a custom MAIL FROM, and SPF. Those records can stay in place while you flip MX. Do not delete sending DNS during the inbound cutover. Do not fall back to Gmail SMTP for the app “just in case.”
Fit check before you start
ArawaMail requires an active Cloudflare zone whose name matches the domain exactly. If the domain is not on Cloudflare, move DNS first. That walkthrough is a separate piece; do not improvise Cloudflare Email Routing and ArawaMail MX on the same day.
If Cloudflare Email Routing currently owns MX, disable or unlock Routing before Activate receiving. Leaving Workspace does not by itself require leaving Routing — only the party that currently holds MX matters.
Seat and domain caps on live pricing: Free is 1 member / 1 domain, Pro is 10 / 10, Business is 50 / 50. A 60-person Workspace shop does not fit Business. Say that in the kickoff meeting, not after MX has moved.
Forwarding destinations, if you use them instead of extra mailboxes: Free 1, Pro 5, Business 10 verified destinations per mailbox. Forwarded copies count toward the monthly transactional allowance. Destinations must verify within 24 hours.
Cutover checklist
- Inventory every address that must keep receiving. Users, aliases, Google Groups, plus-addresses, role inboxes (
billing@,support@), and anything that currently lands in a catch-all. Mark which ones need a real mailbox versus a forward. - Lower MX TTL 24–48 hours before the window. You cannot speed a 72-hour cache that was already published. A short TTL only helps the flip itself.
- Stand up ArawaMail in parallel. Add the domain, confirm the Cloudflare zone matches, and stop before Activate receiving. Receiving replaces MX. Do not click it until the quiet window.
- Decide the archive strategy now. Options: leave Workspace licensed and read-only for one more billing cycle, IMAP-copy what you need, or take a Google export. ArawaMail has no documented Google Takeout importer. Do not promise lossless history sync.
- Optional dual delivery on the Google side only. In Admin, Gmail → Routing, you can keep Gmail as primary and also deliver to another route while MX still points at Google. Use this if you need a short overlap. It does not survive the moment ArawaMail takes MX.
- Quiet window: Activate receiving, then sending, then accounts. Documented order is receiving → sending → create accounts. Accounts cannot be created until receiving is active. Mailbox SMTP and HTTP API sending fail if sending is inactive. Create every required mailbox and send a test before you tell the team the domain has moved.
- Watch the first hour of inbound. Confirm a known external sender reaches each critical address. If Cloudflare Routing or leftover Google MX is still published anywhere, fix that immediately.
- Clean SPF, DKIM, and DMARC after Workspace stops sending. Remove Google from SPF once it is no longer an authorized sender. Watch the SPF 10-lookup cap — stacking Workspace includes with a new provider is how PermError appears the same weekend. Keep ArawaMail sending records intact. Related: SPF, DKIM, and DMARC explained.
- Reconnect clients and revoke Workspace credentials. ArawaMail clients use IMAP 993 and SMTP 465 over TLS. Docs use placeholders such as
imap.example.com/smtp.example.com— take the live hostnames from the Connect a Device screen after the domain is active. Revoke Workspace app passwords. Prefer IMAP over POP3 so the server stays the source of truth; see IMAP vs POP3 and SMTP ports 25, 465, and 587. - Keep product mail on the same domain throughout. Receipts, password resets, and webhooks should not move to a Gmail SMTP fallback. That is how you split reputation and confuse DMARC. See one domain for inboxes and product email.
What happens to Groups, catch-all, and plus-addresses
Google Groups are not mailboxes. If a group address must keep receiving after cutover, create an ArawaMail mailbox (or a verified forward) for that address. There is no automatic Group import.
ArawaMail catch-all is one active mailbox per domain. Mail to an unknown or disabled address goes to that mailbox when it is configured; otherwise it is discarded. Disabling the catch-all mailbox disables the domain catch-all. Do not use catch-all as a substitute for inventorying aliases.
Plus-addressing is a local-part convention, not a Google feature you “migrate.” If billing+stripe@ must keep working, the base mailbox has to exist on the new host. Plan aliases as their own follow-up; this cutover only needs the addresses that must receive on day one.
Will you lose old mail?
New mail follows MX. Old mail stays where it already lives: Workspace, Takeout exports, or local IMAP/POP copies. Moving MX does not copy history. Leaving one Workspace seat read-only for a quarter is often cheaper than a heroic import that nobody will finish.
Disabling an ArawaMail mailbox after cutover blocks SMTP, mobile, and connected AI-assistant access and revokes sessions. Stored mail remains. Use that for leftover accounts; do not treat disable as delete.
Can the Laravel or Next.js app keep sending during the cutover?
Yes, if sending DNS stays published and sending is active on ArawaMail. Receiving and sending are separate activations. MX controls inbound. DKIM, custom MAIL FROM, and SPF control outbound identity. Flip MX without touching the sending records. If sending is still inactive, HTTP API and mailbox sends from that domain fail — enable sending before the app needs those From addresses.
Do not point the app at Gmail SMTP as a temporary relay. That path fights DMARC alignment and trains the team to treat product mail as a side project. Existing implementation notes: send email in Laravel, send transactional email from Next.js, and From, Reply-To, and Return-Path.
How long DNS actually takes
Two clocks run. Resolver cache follows the previous TTL — that is why you lower TTL a day or two early. Google’s own help still says recognition can take up to 72 hours. In practice a short-TTL flip is often visible in minutes, but you plan the first-hour watch and a next-morning check, not a five-minute victory lap.
STARTTLS versus implicit TLS does not change the MX cutover. Client submission on ArawaMail is implicit TLS on 465. Background: STARTTLS vs implicit TLS.
How we analyzed this cutover
The sequence is taken from ArawaMail’s documented domain order (Cloudflare zone → Activate receiving → Activate sending → accounts), Google’s current MX help (smtp.google.com priority 1, up to 72 hours), Google Admin dual-delivery routing with Gmail as primary, and live ArawaMail pricing seats. Constraints that shaped the checklist: no dual-MX on ArawaMail, no Takeout importer, Business cap of 50 members and 50 domains, placeholders only for IMAP/SMTP hostnames, and sending DNS independent of MX. Claims about Calendar staying on Google follow product scope — mailbox docs describe folders and IMAP, not a Calendar replacement.
FAQ
Can we keep Google Calendar and drop Workspace mail?
Yes. This cutover moves MX and mailboxes. Calendar and Contacts can remain on Google accounts. Do not treat ArawaMail as a Meet or Drive replacement.
What if we are not on Cloudflare?
ArawaMail requires an active Cloudflare zone with an exact name match. Move DNS first. Do not click Activate receiving on a domain Cloudflare does not own.
Do we delete Google MX and add ArawaMail MX by hand?
No. Activate receiving writes the MX after a confirmation warning if records already exist. Mixing Google’s smtp.google.com (or the legacy ASPMX set) with ArawaMail MX is how mail splits or vanishes.
How do we keep receipts arriving from a real domain during the flip?
Leave sending records and the API configuration alone. MX is inbound only. Product mail should keep using the same From domain. Related positioning: stop sending from noreply@.
What about a team larger than 50?
Business is 50 members and 50 domains. A 60-person Workspace tenant does not fit. Split workspaces, keep some seats on Google, or wait for a plan that matches headcount. Do not cut MX first and discover the cap second.
Where do we get help mid-cutover?
Contact ArawaMail if receiving activation or Cloudflare authorization fails. Do not improvise a second MX provider while the first is half-live.
Leave Workspace mail on a weekday morning with a lowered TTL, mailboxes already created, and the app still sending from the same domain. The suite can stay for Calendar. The inbox does not have to.