一名用户想给公司注册Google Workspace账号,填入自己拥有的高价溢价域名后,系统弹出一行陌生提示:“请输入有效域名,而不是邮箱服务商”。他查了域名历史,确认从未被用作邮箱服务,联系客服、多次转接、被要求换浏览器换设备、录视频等产品工程师排查,一周后收到的结论却是:系统可能误判了,建议换个域名。
这不是孤例。乌克兰经济部在官方社区论坛上发过几乎一模一样的求助帖,时间是2025年8月,他们的域名me.gov.ua同样被拒收。社区里所谓的“产品专家”给出的回复,基本等于没说。这起看起来很小的注册bug,实际牵出了一套用了很多年、没人认领、也没人修的过期代码。
客服转了三轮,答案却不在客服手里
这名用户最终自己动手,调试了Google Workspace注册页面的前端JS源码,找到了报错的真正来源:一段本地校验函数,会把用户填的域名去匹配一份写死的正则表达式列表——这份列表原本是想拦截Gmail、Yahoo、Hotmail这类免费邮箱域名,防止有人拿私人邮箱冒充企业域名注册。
问题出在正则写得太粗糙。其中一条web\..把所有web.[顶级域名]形式的域名都当成了邮箱服务商,包括这名用户的web.one域名。另一条me\..把所有以me.开头的域名一并拦下,me.gov.ua就是这么中招的——它只是子域名恰好叫“me”,和邮箱毫无关系。列表里还混着一条alice\..*,来源不明,同样殃及池鱼。
系统拦的不是邮箱服务商,是字符串长得像的无辜域名。
一线支持、高级支持、产品工程师排查了整整一圈,没有一个人碰到这段前端代码,更别说指出问题所在。官方支持文档给出的标准建议——换浏览器、关VPN、走域名恢复流程——全都没有对症下药,因为这些流程根本不涉及前端写死的黑名单逻辑。用户自己逆向工程,反而比整个客服链条更快找到真因。
本该用MX记录判断,却用了脆弱的正则
真正让这件事显得荒诞的,是Google自己在其他文档里早就写明白了更可靠的判断方法:识别一个域名是不是Google或Microsoft托管的邮箱服务商,业界通行做法是查MX记录——也就是邮件实际投递指向的服务器,而不是对域名字符串做正则匹配。
对me.gov.ua做MX记录查询就能看到,它的邮件路由指向mail.me.gov.ua和mail.mfert.gov.ua,是彻头彻尾的自建邮件系统,和Google、Microsoft都不搭边。安全社区OWASP也早就提醒过,用正则枚举邮箱服务商本身就是一种脆弱的做法,子串误判几乎无法避免。Google的注册页面选的却恰恰是这条被验证过有问题的路。
- 风险.一份没人复核的老正则,可能同时误伤所有
web.、me.、alice.开头的合法域名,影响面无法精确统计。
| 项目 | 正则字符串匹配 | MX记录判断 |
|---|---|---|
| 判断依据 | 域名拼写模式 | 实际邮件路由服务器 |
| 误判风险 | 高,容易连坐无关域名 | 低,基于真实基础设施 |
| Google是否已用 | 是(注册页前端) | 是(其他产品文档中推荐) |
谁会被拦下,又该看什么
受影响的不只是这名用户和乌克兰经济部。任何域名匹配到这份黑名单模式的企业和机构——名字里带web.、me.、alice.这类片段的正规域名——理论上都可能在注册Workspace时被无理由拒绝,而客服体系目前给不出比“换个域名”更好的答案。
- 结论.这更像一处没人维护的遗留代码,而不是一次性的偶然故障。
文章更新显示,截至2026年8月,这个问题依然存在。对企业客户而言,如果注册时遇到类似报错,与其反复申诉,不如先确认自己的域名是否落入了web.、me.、alice.这类前缀陷阱——目前唯一被证实有效的办法,是绕开前端校验或联系支持强制放行,而不是等Google主动修复。这段代码修不修、什么时候修,Google至今没有给出说法。