Migrate Google Workspace to Gmail forwarding when you already live in one Gmail and were paying seats so the domain would resolve. Export what you must keep. Create named aliases. Publish one MailerZ MX set. Delete leftover Google MX. Probe from another mailbox. Cancel the tenant only after the hop is honest. Gmail send as is a later paid hop. MailerZ is not Workspace and will not host Calendar.
Quick answer for migrate google workspace to gmail forwarding
Create the domain on MailerZ. Verify TXT. Recreate printed Workspace users and groups as named aliases into the Gmail you will keep. Publish MailerZ MX. Delete leftover Google MX. Probe each name from an unrelated mailbox. That is migrate Google Workspace to Gmail forwarding as receive.
Custom domain Gmail after a suite is still not Google hosting the domain. Email forwarding to Gmail is the hop. Historical Workspace mail stays in Workspace until you export it. MailerZ will not pull the archive.
Gmail send as replaces native suite From. Free cannot finish that hop. Solo is $40 per year when hello@ must travel. Creating the inbound alias does not approve outbound.
If you still need Calendar, Vault, or admin devices, stay on Workspace. Compare products after you admit you still need a suite.
MailerZ Free is one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.
Google’s own Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a product is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol.
custom domain gmail: the real decision
Teams cancel Workspace on Friday and edit MX on Monday. Mail written over the weekend hits a tenant that no longer accepts it and a forwarder that does not own it yet.
They recreate hello@ and forget the groups customers still use. Those names sit in hold or bounce.
They expect Drive and Calendar to follow the MX change. Those are other products.
Criteria: export list, printed-name list, one MX operator, cancel only after two public views agree and probes pass.
| Need | Stay on Workspace | Gmail + MailerZ |
|---|---|---|
| Hosted mailbox on the domain | Yes | No — destination is Gmail |
| Printed hello@ | Native user | Named alias |
| Calendar / Drive | Included | Keep or export separately |
| Branded send after leave | Native | Paid SMTP + Send mail as |
Prove inbound from another mailbox before you print hello@ on a homepage.
Start free — one domainTechnical mail flow for migrate google workspace to gmail forwarding
Before cutover, Google MX accepts RCPT TO for Workspace users. After cutover, MailerZ accepts named aliases and forwards to Gmail. Header From stays the original author. SRS may rewrite the envelope.
Messages already in Workspace do not move. New messages after TTL follow the new MX.
Outbound from Gmail as the domain is a second hop. Workspace no longer signs that From once you leave.
Split TTL means some senders still hit Google. Save the old set. Do not add a backup leftover host.
MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP, not webmail, not an open relay. Unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Not SOC 2, not ISO 27001, not HIPAA.
gmail send as
Export, map, cut, probe, cancel — in that order.
- Export or retain Workspace mail you legally need.
- Print users and groups still in public use.
- Add and verify the domain on MailerZ.
- Create those names as aliases into the keep Gmail.
- Publish MailerZ MX. Delete leftover Google MX.
- Probe each name from another mailbox.
- Attach paid send-as only for Froms that must travel.
- Cancel Workspace only if nothing else in the tenant needs Google as MX.
Failure modes and proof
Canceled first. MX later. Weekend hole.
Left Google MX as backup. Production never moved.
Self-send certified the cutover.
Forgot groups. Customers still write team@.
Expected Takeout to run through MailerZ.
Leftover MX is the usual ghost. Check a public lookup before you blame Gmail.
Open leftover MX troubleshootingMailerZ workflow and product boundary
MailerZ is inbound MX plus authenticated SMTP around the Gmail you keep. Not a suite. Not IMAP. Not an inbox SLA. Related: email forwarding, send and reply, compare Google Workspace, docs.
14-day Free store and 90-day paid store are for hops after cutover, not the old tenant.
Related pages: email forwarding, send and reply, compare Google Workspace, and docs.
email forwarding to gmail
Three leftover Workspace seats often cost more than Solo or Starter for a year. If you still need Vault, the suite is cheaper than a lawsuit. Confirm pricing.
Time on a hole between cancel and MX is the expensive line.
MailerZ Free is one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.
Field notes you can reuse
Keep Workspace read-only if counsel has not signed the export.
Recreate only public names. Hold harvests.
Shared Workspace mailboxes need a chosen Gmail owner before cut.
CMS that sent as the domain needs SMTP after you leave the suite.
Agencies: per-client cutovers. Do not share one Google MX leftover across clients.
Outlook can be the keep store. Document it.
Review MX after any nameserver move.
This page is not a Drive migration guide.
Deeper field notes for migrate google workspace to gmail forwarding
What you are actually leaving
Google Workspace is a hosted mailbox, Calendar, Drive, and admin. Migrating to Gmail plus email forwarding means you keep a free Gmail (or a personal Google account) as the store and you move the domain’s MX to a forwarding operator. You are not moving “email” as a vague blob. You are moving inbound receipt, optional branded send, and whatever files still live in Drive. Calendar is a separate export if anyone still uses it. Confusing those layers is how a cutover deletes the wrong thing.
MailerZ is inbound MX plus authenticated SMTP. It is not Workspace. It will not host Calendar. It will not keep Drive. If the company still needs those, stay on Workspace or pick another suite. This page is for teams who already live in one Gmail and were paying seats so hello@ would resolve.
Order of operations that does not strand mail
Export what you must keep from Workspace first if you will cancel the subscription. Then create the domain on MailerZ. Verify TXT on the nameservers that actually answer. Create the named aliases you still print. Map them to the Gmail you will read tomorrow. Publish MailerZ MX. Delete leftover Google MX. Wait for TTL. Probe from an unrelated mailbox. Only then cancel Workspace, and only if nothing else in that tenant still needs Google as MX.
Reversing that order — cancel first, MX later — drops mail into a hole Google no longer accepts and MailerZ does not yet own. Save the old MX set before you delete anything. A screenshot of the Workspace admin DNS hints is not a public lookup. Check more than one resolver.
What happens to historical mail
Forwarding does not pull the old Workspace store into Gmail. Messages that already arrived stay where they arrived unless you export them. IMAP export, Google Takeout, or a one-time download are product decisions Google documents. MailerZ will not migrate the archive. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw after cutover. They are not eDiscovery and not a Workspace replacement archive.
If counsel wants the old tenant retained, do not cancel Workspace on cutover day. Keep the tenant read-only until legal says the export is enough. That cost is a legal cost, not a forwarding cost.
Send-as after you leave the suite
In Workspace, send-as the domain is native. After you leave, branded replies need paid MailerZ send-as plus Gmail Send mail as with the dashboard host, port, and TLS pair. Free cannot finish that hop. Solo is $40 per year when the domain From must travel. Creating the inbound alias does not approve outbound. Catch-all does not mint a From.
Copy SMTP credentials once. Do not paste a Gmail password into a CMS because “we left Workspace.” The CMS still needs authenticated SMTP if it sends as the domain. Unauthorized send is 550 / 550 5.7.1.
Users, aliases, and groups you will forget
Workspace groups like team@ and plus aliases people invented in the admin console will not appear on MailerZ until you create them. Print the Workspace user list and the group list before cutover. Recreate only the names the public still uses. Hold unknowns. A harvest of old group names should not land in Primary on day one.
Shared mailboxes in Workspace are not aliases. They are stores. If two people used a shared support box, decide the Gmail destination and the reply owner before you cut MX. Do not assume forwarding recreates sharing.
When not to leave
If you need Vault, admin-controlled devices, or Calendar as the company system of record, forwarding is the wrong buy. Compare the products on the Workspace comparison page after you admit you still need a suite. MailerZ will not become that suite.
A complete worked story
A consultancy that canceled on Friday
Four consultants shared Workspace so clients could write hello@ and partners@. They already forwarded everything into one Gmail with a filter. The invoice annoyed them. Someone canceled Workspace Friday afternoon and planned to “set up forwarding over the weekend.” Saturday invoices hit Google, which no longer accepted the domain. Monday they created MailerZ aliases and published MX. The weekend copy was gone. They restored Workspace long enough to grab what Google still had, exported, then cut cleanly. The lesson was order, not product.
The second attempt listed hello@ and partners@, verified TXT, published MailerZ MX, deleted Google MX, and probed from a Hotmail account. Both names landed. They paid Solo so replies could leave as hello@. They kept the Workspace tenant one more month for Drive. Calendar was already dead. That is a migration.
Operator brief
A longer operator brief for migrate google workspace to gmail forwarding
Teams that bookmark How to Move From Google Workspace to Gmail + Email Forwarding usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about migrate google workspace to gmail forwarding as a send-as, catch-all, or comparison problem.
MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is not a hosted mailbox, not IMAP, not webmail, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.
If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening migrate google workspace to gmail forwarding. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.
Catch-all forward is not a safety feature for how to move from google workspace to gmail email forwarding. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.
Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.
Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear migrate google workspace to gmail forwarding works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.
Agencies should keep migrate google workspace to gmail forwarding per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.
Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.
Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.
When How to Move From Google Workspace to Gmail + Email Forwarding is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how migrate google workspace to gmail forwarding stays a runbook instead of an incident.
A second worked pass for migrate google workspace to gmail forwarding: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a migrate google workspace to gmail forwarding mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.
A third worked pass: print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.
More working detail
What “keep Gmail” actually means on cutover day
People say they will keep Gmail and then discover the only login they have is the Workspace user that is about to die. A personal @gmail.com is a different account from you@yourdomain on Workspace. If the team only ever signed into the Workspace user, they do not yet have a keep store. Create or confirm the destination Gmail before you publish MailerZ MX. Map aliases to that address. Probe it. Do not map aliases to the Workspace address you are about to cancel — that destination will vanish with the tenant.
If two consultants share one keep Gmail, write who holds 2FA. Shared Workspace felt official because Google showed two logins. One Gmail with two humans is a password-and-label problem, not an MX problem. Do not solve it by leaving a leftover Google MX “so the old logins still work.” Those logins are the suite you are leaving.
Mobile apps that were signed into Workspace mail will stop receiving domain mail after MX moves, even if Calendar still opens. Tell people to open the keep Gmail. That sentence prevents a week of “forwarding is down” tickets that are actually the wrong app.
FAQ
- What is the safest way to handle migrate google workspace to gmail forwarding?
- Export what you must keep, recreate printed names as aliases into the Gmail you will read, publish one MailerZ MX set, delete leftover Google MX, probe from another mailbox, then cancel the tenant if nothing else needs it.
- Does this require a new mailbox?
- No. MailerZ is not IMAP and not webmail. Gmail or Outlook remains the store unless you separately buy a hosted mailbox product.
- Will it work with Gmail or Outlook?
- Yes for inbound when the destination is a verified mailbox. Branded replies need paid send-as plus Gmail Send mail as or a manual Outlook SMTP identity. Free has no send-as.
- What DNS records are involved?
- A verification TXT, one MailerZ MX set on the authoritative nameservers, leftover host MX removed, and SPF, DKIM, and DMARC if you also send as the domain.
- What should I test before production?
- Send a uniquely titled message from an unrelated provider into each named alias. Confirm Header From and delivery history. Do not email yourself from the same Gmail account.
Key takeaways
- Cancel last.
- Export first.
- Recreate public names.
- One MX set.
- Probe externally.
- Send-as is paid.
- Archive is not forwarding.
- Stay if you need the suite.
Conclusion and next action
Leave Workspace when you only needed the domain to resolve into Gmail you already search. Cut leftover Google MX after aliases and a probe plan. Pay for the Froms that must travel.
Start free on a domain you can break. Sign in if Google still answers a zone you thought you left.
Leave the suite, keep the inbox
Start free, map the names, cut leftover Google MX after a probe plan.
Do not cancel Workspace before public MX agrees.
Review quarterly, or sooner if Gmail, Workspace, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.