Gmail Registration Now Demands You Text Google First

What happened

Google has quietly changed the registration flow for new Gmail and Google accounts. Previously, you entered a phone number during signup, and Google sent you an SMS with a verification code — a standard inbound-SMS flow used by nearly every service on the internet. The new process flips this entirely.

Now, Google displays a QR code during registration. You scan it with your phone's camera, which opens a pre-composed SMS message. You hit send, texting a verification payload from your device to a Google-owned number. Only after Google receives your outbound SMS does account creation proceed.

The change was first documented on the Privacy Guides forum and quickly drew attention on Hacker News, where it scored 582 points — a strong signal that this resonated with the developer and privacy-conscious community. Google has not published a blog post or changelog entry explaining the shift.

Why it matters

On the surface, this looks like a minor UX tweak — scan instead of type, send instead of receive. But the technical and privacy implications are substantial, and they all point in one direction.

It kills the VoIP workaround. For years, privacy-minded users and developers have used VoIP numbers, Google Voice, TextNow, and similar services to verify accounts without exposing their real carrier number. These services can receive SMS but typically cannot send SMS through the carrier network in the way Google's new flow requires. By demanding an outbound SMS, Google has effectively mandated a physical SIM card — or at minimum, a carrier-authenticated eSIM — as the price of entry to its ecosystem.

It's identity binding, not security. The security value of SMS verification was always about proving you control a phone number. Whether you receive a code or send a message, the security proof is equivalent. What changes is the data Google collects. When Google sends you an SMS, they know the number you claimed. When you send Google an SMS, they have carrier-level proof of your number — it comes through the telecom network with your real MSISDN attached. There's no spoofing an outbound SMS the way you might intercept an inbound one via SS7 attacks. This is a verification method that also happens to be a de-anonymization method.

It raises the bar for the developing world. In many countries, prepaid SIM cards are cheap but SMS is not free. Requiring users to send an outbound text — even a single message — introduces a cost barrier that receiving a text does not. For developers in regions where data-only plans are common, or where carrier SMS infrastructure is unreliable for outbound messages, this change could genuinely block account creation.

The community reaction on Hacker News was sharply divided but leaned critical. Several commenters noted the irony: Google has spent years pushing passkeys and FIDO2 as the future of authentication, positioning itself as a post-password, post-SMS company. Yet for the very first interaction with a new user, it now requires the most carrier-dependent verification method possible. Others pointed out that this likely targets the bot and spam account epidemic — Google reportedly fights millions of fraudulent account creation attempts daily, and outbound SMS is significantly harder to automate at scale than harvesting inbound verification codes.

What this means for your stack

If you're a developer, this change has practical downstream effects worth thinking through now.

Testing and CI accounts. If your team creates Google accounts for integration testing, QA environments, or service-level access, the new flow breaks any automated or semi-automated account provisioning. Google Workspace accounts created through the Admin Console are unaffected, but personal Gmail accounts — often used as throwaway test accounts — now require a human with a phone. Audit your test infrastructure and consider consolidating on Workspace-managed service accounts.

OAuth and sign-in dependencies. If your application offers "Sign in with Google" as a primary authentication path, this change doesn't affect existing users. But it does affect the funnel: any potential user who cannot or will not complete the outbound-SMS flow is now locked out of both Google and every service that depends on Google as an identity provider. If Google login is your only auth option, you've inherited Google's identity requirements as your own.

The broader pattern. This is not a Google-only trend. Apple requires an Apple device to create an Apple ID. Microsoft has been tightening Outlook.com registration with similar phone-based gates. The era of creating a free email account with nothing but a browser and a made-up name is functionally over at every major provider. For developers building identity-sensitive applications — whistleblower platforms, privacy tools, services for at-risk populations — the assumption that users can easily create a pseudonymous email account no longer holds.

If you maintain documentation or onboarding flows that say "create a Gmail account," verify that your users can actually do that. If your threat model assumes users can operate pseudonymously through mainstream email providers, revisit that assumption.

Looking ahead

Google's move is a rational response to a real problem — automated account creation at scale fuels spam, phishing, and abuse. But the solution they've chosen trades user anonymity for platform integrity, and does so without announcement, documentation, or opt-out. For a company that controls the identity layer for a significant fraction of the internet, that's a policy decision masquerading as a product change. Expect this to draw regulatory attention in the EU, where pseudonymous access to digital services is an explicit policy goal under the Digital Services Act. And expect more developers to start treating email-as-identity as a liability rather than a convenience.