Daniel's been living in Google's ecosystem since it was called Google Apps, and he's got a question about something that's been quietly bothering him for years. He writes — and I'm going to read this nearly in full because the details matter here — "I've been using Google Workspace for so long that I can barely remember when it was called Google Apps. I've stayed with it through Google Apps, G Suite, Workspace, and all the other branding changes, so maybe some of my habits are just inertia at this point. One of those habits is relying heavily on Google Groups, not because I actually want mailing lists, but because they're the closest thing Google offers to flexible mail routing. I know a lot of other Workspace users do the same, but it has always felt like a workaround rather than the feature it was actually designed for."
He's not wrong.
"For incoming mail, I use Groups as shared receiving addresses. For example, I might create family at my domain dot com and have it deliver to both me and my wife. If we sign up for something like Netflix, that's the address we use, and it's the one we store in our shared password manager. The arrangement works well, but we ignore almost everything Google Groups was originally built for — discussion archives, topics, web UI, all the mailing-list functionality. The interface is clearly designed around those ideas, not around being a lightweight mail-routing tool." He goes on — "On the business side, I use Groups in a similar way for outbound communication. I'll create addresses like billing at, accounts at, or even a group for a specific client, add everyone involved, and then send to a single address that fans out to all the right people. Again, the Group is really just standing in for a mail-routing feature." Then he mentions his catch-all setup — on domains he owns but doesn't actively use for email, he configures Cloudflare Email Routing instead of Google, and he says the experience feels much cleaner and more modern. And here's the actual question.
Let's hear it.
"I've been in the Google ecosystem for so long that I wonder whether I'm staying because it's genuinely the best fit or simply because I've been using it forever. So I'm curious how you both think about this. Am I overlooking better ways to accomplish these workflows within Google Workspace? Has Google quietly added features that make Google Groups unnecessary for this kind of mail routing? Or has the rest of the email hosting world moved on while Google has largely stood still? If you think the latter is true, what services would you look at today? Are there modern email platforms that handle shared addresses, distribution lists, aliases, catch-all routing, and general mail administration in a cleaner, more elegant way than Google Workspace? And what trade-offs would someone with a long history in the Google ecosystem have to consider before making the jump?"
That's a well-framed question. And the fact that he's already using Cloudflare for catch-all on some domains tells me he knows the answer in his gut — he's just looking for permission to examine it properly.
So today we're asking — is Google Groups the right tool, or is it just the tool you've always had?
The core tension here is almost philosophical. Google Groups was born as a discussion and archive product. It has topics, a web UI, moderation tools, post histories. And yet the most common power-user deployment I see is exactly what Daniel describes — create a group, turn off every single feature, and use it as a dumb pipe that forwards mail to two or three people. That's not using a product. That's defeating a product.
It's like buying a restaurant and using it exclusively as a hallway to get to the parking lot.
That's... actually a perfect description of what's happening here. You've got this whole establishment with tables and menus and a kitchen, and you're just walking through it to get somewhere else. The question is whether Google has built you an actual hallway yet, or whether the restaurant is still the only route.
So let's map this out. Three pieces. First, what does Google Workspace actually offer today for mail routing — the real toolkit, not the Groups workaround. Second, has the rest of the email world actually moved on, and what does that look like? Third, what would it cost someone like Daniel to switch, and is a full switch even the right answer?
And underneath all of that, there's the emotional question. The one about inertia. I've been in the Google ecosystem since Apps for Your Domain launched in two thousand six. That's two decades of muscle memory. You don't walk away from that lightly, even when you know the tool is wrong for the job.
Alright. Let's start with what's actually in the toolbox. Walk me through it. If I'm a Google Workspace admin and I want to route mail without touching Groups, what are my options?
Three things, and none of them fully solve the problem. Option one — email aliases. Every user in Workspace can have up to thirty aliases. So if your primary address is herman at my domain dot com, you can add herman dot billing as an alias, and mail to that address lands in your inbox. Dead simple. But here's the catch — an alias belongs to exactly one user. It cannot fan out to multiple people. So for Daniel's family at address that goes to both him and his wife, aliases are useless.
So aliases solve the "I want multiple addresses for one person" case, not the "I want one address for multiple people" case.
Option two — the catch-all. This is buried in the admin console under Apps, Google Workspace, Gmail, Advanced settings. Not in the main Gmail settings where any reasonable person would look. The catch-all takes any mail sent to a non-existent address at your domain and routes it somewhere. But — and this is the critical limitation — it can only route to a single destination. One mailbox, or one group.
Wait. So the catch-all routes to... a group?
Yes. Google's own documentation for catch-all routing literally instructs you to create a group and add members to it. The documentation itself is codifying the workaround. You want a catch-all that goes to three people? Create a group, add three members, point the catch-all at the group. You're back in the restaurant.
That's almost poetic. The official escape hatch from Groups is... another Group.
And option three is Groups itself. Which we've established is a mailing list product wearing a mail-routing trench coat. The way Daniel uses it — create a group, set it to deliver to members, disable the web UI, disable the archive, disable topic replies — is effectively turning off ninety percent of the product to get at the ten percent he actually needs.
Has Google added anything in the last, say, five years that changes this?
And this is the part that surprises me. The routing toolkit — aliases, catch-all, groups — has been essentially static for years. The admin console has actually gotten more complex, not simpler. They've redesigned it multiple times, moved settings around, but the underlying capabilities haven't changed. There's no "distribution list" object. No "shared mailbox" concept. No routing rules engine. You get aliases, you get a catch-all with a single destination, and you get Groups. That's the menu.
So when Daniel asks whether he's overlooking better ways within Workspace — the answer is basically no. He's found the least-bad way to do what he needs, and the least-bad way is still bad.
And it's not just that the tool is wrong. There are actual risks. Every Group has a web UI by default. If you forget to disable it, your family at address has a public-facing discussion archive. The admin console shows it as a discussion group, not a routing rule. Someone else with admin access could look at it and think, oh, this is a mailing list, I'll enable topic posting. The whole thing is a category error waiting to happen.
The category error is the phrase. You're using a discussion product as infrastructure, and the product keeps trying to be a discussion product.
Contrast this with what Daniel's already doing on the side — Cloudflare Email Routing. He sets up a catch-all, and it takes under a minute. There's no admin console labyrinth. There's no concept of groups. You create a rule — if mail arrives for this address, forward it to that address. If you want it to go to two people, you add two forwarding rules. The mental model matches the actual task.
That's the thing that jumps out at me. Cloudflare's routing model is just... rules. You don't have to first create an entity called a Group, then configure its delivery settings, then disable its web interface, then hope nobody re-enables it. You just say "mail to billing at goes here and here." Done.
And that brings us to the broader question. Has the rest of the email world moved on?
Let's do the survey. Who's doing this well?
Cloudflare Email Routing is the obvious starting point, and it's free. Catch-all in under a minute, simple forwarding rules, no mailbox to manage — it's purely a routing layer. You can point your MX records at Cloudflare, set up all your routing logic there, and then forward everything to whatever actual mailboxes you use. Including Google.
So you don't even have to leave Google to benefit from this.
That's the hybrid approach, and we should come back to it. But let's look at the others. Zoho Mail — they offer shared mailboxes as a first-class feature. Not a workaround, not a repurposed discussion tool. You create a shared mailbox for billing at, add the people who need access, and they can all read and send from that address. It's designed for exactly the use case Daniel describes.
What's the difference between a shared mailbox and a Group with the web UI disabled?
A shared mailbox doesn't have a discussion archive to disable. It doesn't have topics. It doesn't have moderation settings. It's a mailbox that multiple people access. The interface reflects the thing it actually is. When you look at your admin panel, you see "shared mailboxes," not "discussion groups being used for something else." The category matches the object.
So the cognitive load drops. You're not constantly translating between what the tool thinks it is and what you're using it for.
Microsoft 365 does the same thing. Shared mailboxes are built into Exchange Online. Multiple users can access them, send from them, and there's no group semantics anywhere. ProtonMail takes a different approach — they build aliases into the privacy model itself. Fastmail has masked email addresses and per-domain routing that's elegant. The common thread across all of these is that routing is treated as a core feature with a dedicated UI.
Whereas Google treats routing as an emergent property of a discussion product.
That's the philosophical difference. And Daniel's instinct that this feels like a workaround — he's right. It is a workaround. Google never designed Groups to be a mail router. They designed it to be a mailing list platform with archives and topics and web interfaces. The fact that you can disable all of those things and use it as a router is a happy accident, not an intentional design.
The question is whether Google knows this and doesn't care, or whether they're just... stuck. Groups is so entrenched that building a proper routing feature would mean migrating millions of groups that are being used this way.
I suspect it's the latter. Google Groups has been around since two thousand one. There are organizations with thousands of groups configured exactly like Daniel's — web UI off, archive off, just routing. Google can't deprecate Groups without breaking all of those setups, and building a migration path from Groups-as-router to a hypothetical Routing product is a massive engineering effort with no revenue upside. So they don't touch it.
The classic innovator's dilemma, but in reverse. They're not being disrupted by someone simpler — they're being held back by their own installed base.
Alright, so let's get practical. If Daniel wants to keep Google Workspace but fix the routing pain, what does the hybrid approach actually look like?
Walk me through it. I've got Workspace, I've got a domain, I hate Groups. What do I do?
Step one — you keep Google for the actual mailboxes. Gmail's interface, search, labels, filters — all of that stays. Step two — you change your MX records to point at Cloudflare Email Routing instead of Google. Step three — you configure all your routing logic in Cloudflare. Family at forwards to both you and your wife. Billing at forwards to the five people on the finance team. Catch-all forwards to your primary inbox. Step four — Cloudflare delivers the mail to your Google mailboxes.
So Cloudflare becomes the mail routing layer, and Google becomes the mail storage and interface layer.
And they coexist perfectly. Cloudflare doesn't store mail — it just routes and forwards. Google receives the forwarded mail and treats it like any other incoming message. The sender has no idea this is happening. Your users don't see any difference. The only thing that changes is where you go to add a new forwarding rule — Cloudflare's dashboard instead of Google's admin console and Groups.
That's almost too clean. What's the catch?
Two things. First, outbound mail still comes from Google's servers. If you want billing at to be a send-from address in Gmail, you still need to configure that in Google — either as an alias or as a group. Cloudflare only handles inbound routing. Second, you're now managing DNS, routing, and mailboxes across two different providers. If something breaks, you have to check both dashboards.
But that's already true for Daniel. He's already using Cloudflare for catch-all on some domains. He's already in two dashboards.
Right. So for him, the hybrid approach isn't adding complexity — it's consolidating. Move all routing to Cloudflare, keep Google for the inbox, and stop using Groups entirely. The Groups that currently exist become pure historical artifacts.
What about the people who want to leave Google entirely? What does a full migration look like?
The routing part is easy. Any modern provider — Zoho, Fastmail, Proton, Microsoft 365 — handles shared addresses and distribution lists more cleanly than Google. The hard part isn't the routing. It's the integration.
Calendar, Drive, Meet, Docs.
All of it. Google Workspace isn't just email. It's a suite where everything is linked. You share a Doc from Drive, it sends an email notification. You schedule a Meet, it creates a Calendar event that sends an invitation. You forward an invoice to billing at, someone opens it in Google Sheets. The routing hack is tolerable precisely because the rest of the ecosystem is so integrated.
So leaving Google means you fix the routing problem but create fifteen new integration problems.
That's the trade-off. And for someone like Daniel who's been in the ecosystem since the Google Apps days, those integrations aren't just features — they're habits. Muscle memory. The cost of switching isn't the monthly subscription fee. It's the cognitive overhead of rebuilding every workflow.
Which brings us back to the inertia question. How do you tell the difference between staying because it's the best fit and staying because it's familiar?
I'd suggest a framework. List your top five email workflows. Not features — workflows. The things you actually do. "My wife and I both need to see the Netflix emails." "The finance team needs to receive invoices at billing at." "I need a catch-all for my side project domains." Score each workflow on how well Workspace handles it today.
And if routing scores low across the board?
That's your signal. If three of your five workflows are routing problems that Google solves badly, you're not staying because it's the best fit. You're staying because you haven't evaluated the alternatives. And the hybrid approach — Cloudflare for routing, Google for the inbox — solves those routing problems without touching the rest of the suite.
What if the score is mixed? Routing is annoying but the integration is valuable?
Then you stay, but you clean house. Go through every Group you've created for routing purposes. Disable the web UI. Turn off the discussion archive. Remove any members who don't need to be there. Treat each Group as a routing primitive and nothing else. The cognitive dissonance drops when you stop pretending these are mailing lists and start treating them as what they actually are in your setup — dumb pipes.
That's a surprisingly therapeutic approach to admin work.
It is. And there's a practical benefit too. A Group with the web UI disabled and no archive is less likely to be accidentally exposed. Google's default settings for new Groups include a public web interface. If you create a Group and forget to change the defaults, your family at address has a public page. Cleaning up your existing Groups reduces that risk.
Let's talk about the outbound side for a minute. Daniel mentioned using Groups for outbound fan-out — create a group for a client project, add the team, send to one address. That's actually the use case where Groups is least bad, because it's closest to what Groups was designed for.
Agreed. A mailing list that delivers to members is... a mailing list. That's the one scenario where you're using the product as intended. The friction is that the admin interface still assumes you want discussion features. But functionally, outbound fan-out is the least-wrong use of Groups.
Whereas the inbound shared address — family at, billing at — that's where the mismatch is worst. You're using a discussion archive as a shared inbox, and the product keeps trying to be a discussion archive.
And that's where the alternatives shine. Zoho's shared mailboxes handle exactly this. Multiple people can access the mailbox, read messages, mark them as read, reply from the shared address. The interface shows you a mailbox, not a discussion thread. There's no web archive to disable because there was never a web archive.
What about the smaller players? You mentioned Fastmail and Proton.
Fastmail's approach is interesting because they treat masked email as a privacy feature. You can generate unique addresses for every service you sign up for, and they all route to your inbox. It's a different philosophy — instead of one shared address that multiple people access, you get many unique addresses that all converge on one person. For Daniel's Netflix use case, he and his wife could each have their own masked address that both deliver to the shared password manager's email.
That's solving a slightly different problem, though. The shared address isn't just about delivery — it's about having a single address that both people know and can use when signing up for things.
Right. The shared address has coordination value. "Use the family at address" is simpler than "use your masked address, and I'll use mine, and we'll both check the password manager." The shared address is a coordination primitive, not just a routing primitive.
So Fastmail's masked emails are elegant but they don't replace the shared-address pattern. They replace the "I don't want to give Netflix my real address" pattern.
Different tool, different job. Which is really the thesis of this whole episode — use the tool whose design matches your actual use case. Daniel's use case is shared addresses and simple routing. Google Groups is a mailing list platform. The mismatch isn't a failure of imagination on his part. It's a genuine gap in Google's product lineup.
Do we think Google will ever fill that gap?
I'm skeptical. The Groups workaround is so deeply entrenched that building a proper routing feature would be a political problem as much as a technical one. You'd have to convince millions of admins to migrate from Groups to the new thing, and the new thing would have to be strictly better in every way, and if anything broke during migration you'd have a support nightmare. Google's incentive is to leave it alone.
The cost of doing nothing is zero. The cost of fixing it is enormous and the upside is... what, exactly? A cleaner admin console that most users never see?
The upside is retaining the power users who notice the gap. Daniel's already using Cloudflare for some domains. He's already peeking over the fence. The risk for Google isn't that he'll leave tomorrow — it's that over time, more of his workflow will migrate to tools that handle routing properly, and one day he'll realize he's only keeping Workspace for Calendar and Drive.
By then, Calendar and Drive have competitors too.
They do. But that's a different episode.
Alright, let's land this. Three things someone like Daniel can do this week.
First, if you're staying in Workspace, clean up your Groups. Disable the web UI on every Group you use for routing. Turn off the discussion archive. Audit the member lists. Treat them purely as routing primitives. This doesn't fix the underlying mismatch, but it reduces the risk of accidental exposure and makes your setup more legible.
Second, evaluate the hybrid approach. Cloudflare Email Routing is free. You can set it up in an afternoon, point your MX records at it, and handle all your catch-all and forwarding logic there while keeping Google for the actual mailboxes. You don't have to migrate your entire email history or retrain anyone. The routing layer just gets cleaner.
Third, run the five-workflow audit. Write down the five email workflows you actually use, score how well Workspace handles each one, and if routing scores low across the board, that's your answer. You're not staying because it's the best fit. You're staying because you haven't carved out the time to look at alternatives.
The meta-takeaway here is that the best tool isn't the one with the most features. It's the one whose design matches your actual use case. Google Groups is a great mailing list tool. Daniel isn't running mailing lists.
He's running a mail router. And he's running it on a platform that doesn't know what a mail router is.
The question Daniel ended with was about inertia — is he staying because it's the best fit or because it's familiar? The answer isn't "switch" or "stay." It's "know why you're staying." If you've done the audit, looked at the alternatives, and decided the integration value of Workspace outweighs the routing friction — fine. That's a decision. But if you've never done the audit because the admin console is familiar and the workaround works well enough... that's not a decision. That's drift.
Drift is how you end up using a discussion archive as a family inbox for ten years without ever asking whether there's a better way.
Which brings us to the open question. Will Google ever build a proper routing feature? Or is the Groups workaround so deeply baked into the ecosystem that they'll never touch it?
My bet is they won't. The installed base is too large, the migration cost is too high, and the revenue impact is zero. But the risk for Google isn't that someone builds a better Groups. It's that the power users who tolerate the hack today gradually discover that Cloudflare and Zoho and Fastmail have been solving this problem cleanly for years, and one day they look up and realize they're only still in Workspace out of habit.
Habits have a way of breaking all at once, not gradually.
They do. Thanks to Hilbert Flumingtop for producing, as always.
This has been My Weird Prompts. If you've got a workflow you've been hacking around for years — something that works but feels wrong, something where you're not sure if you're using the tool or defeating it — send it in. That's what this show is for. Email the show at show at my weird prompts dot com.
We'll be back soon.
