Google Workspace signup blocks legitimate domains, mistaking them for email providers

Google's official documentation had nothing on this error, but a search turned up multiple people who'd hit the same wall and posted for help in community forums. One thread on Google's support community came from Ukraine's Ministry of Economy, which ran into the identical error trying to register its domain, me.gov.ua, for Workspace.

Three support agents, and "have you tried a different browser?"

The blogger eventually contacted Google Workspace support. Agent after agent asked the same question — had they tried a different browser? — and it took several rounds of explaining that yes, they had, before getting escalated to a senior support rep named Karen. Karen asked the same thing again, this time suggesting a different device. Next came a request for a screen recording so a product engineer could review it, which the blogger submitted. Days later, trying again, the error was still there. A week after that, the answer came back: Google didn't know the exact cause, and the blogger should just use a different domain.

The regex list hiding in the source code

Ready to give up on Google and consider switching to Microsoft, the blogger took one more look — this time directly at the signup page's source code. That's where they found it: the error came from a local input-validation function that checked the entered domain against a list of regex patterns meant to catch known email providers. Several entries on that list made no sense at all.

Regex pattern	Domains it blocks	Notes
web\..*	Any TLD starting with web.	This rule is what blocked the blogger's .one domain
me\..*	Domains and subdomains starting with me.	This is what caught Ukraine's Ministry of Economy domain, me.gov.ua
alice\..*	Domains starting with alice.	The blogger found no explanation for why this was on the list

The web\..* rule lumped every domain starting with "web." into the email-service category, no questions asked. The me\..* rule did the same for any address with "me" as a subdomain — which is exactly how Ukraine's Ministry of Economy, using me.gov.ua, ended up tripping the same error.

The server never blocked it — only the screen did

The blogger tried disabling the validation function directly in the browser's developer tools. It worked exactly as expected: once the check was turned off, the domain field accepted the input and signup went through without a hitch. In other words, this was purely a frontend check — nothing on the server side was actually blocking these domains. The validation logic itself was simply misclassifying legitimate domains as email providers. The blogger speculated that Ukraine's Ministry of Economy likely ended up switching to Microsoft 365 after hitting this wall, though that's just a guess, not a confirmed fact.

Editor's take

What makes this case interesting isn't the bug itself — it's how the bug came to exist. Somewhere along the line, someone probably wrote a rule meant to catch free-email domains like web.de, gmx, or mail.ru and stop them from being registered as business accounts. Over time, that rule quietly expanded into something far too broad: web.[any TLD], me.[any TLD], and so on. Nobody, not even the blogger who found it, could explain why alice..* was on the list at all — which suggests someone added it once, and no one ever looked at it again.

Anyone who's maintained a SaaS signup form for a while will recognize this pattern. A blacklist that starts as a few reasonable lines of code often survives years of staff turnover completely unaudited. The problem here is that this happened inside the core signup flow of a major platform — a piece of logic broad enough to block government domains, existing as nothing more than a single line of frontend JavaScript, with no server-side validation backing it up. And if validation only lives on the client side, it can be bypassed with browser dev tools — which is a security red flag in its own right.

If you run into a similar error registering a company domain with Workspace or a comparable SaaS product, checking the signup page's script through your browser's developer tools might get you further, faster, than waiting weeks on a support ticket. That's not advice for everyone, and the fact that this kind of workaround is even necessary says something about the state of the service itself. Now that this has made the rounds on Hacker News, Google may well clean up its regex list — but whether it also builds proper server-side validation to back it up remains to be seen.