O Google liberou no Brasil a troca do endereço do Gmail. Isso significa mudar a parte antes do “@gmail.com”. A novidade já valia nos Estados Unidos desde abril. Agora ela chega aos usuários brasileiros. Para quem desenvolve software, o impacto é direto.

Afinal, muitos sistemas tratam o email como identidade fixa. Quando esse endereço deixa de ser imutável, várias suposições do código caem. Portanto, vale entender o que muda. Assim, você evita bugs silenciosos na sua base de usuários.

Gmail e a mudança que afeta a autenticação por email

Primeiro, vamos ao essencial. O usuário define um novo nome antes do “@gmail.com”. Além disso, o Google mantém o endereço antigo ativo. Ou seja, a conta responde pelos dois endereços ao mesmo tempo.

Esse detalhe parece pequeno, porém pesa muito. Caso o seu login use email como chave única, dois endereços passam a representar a mesma pessoa. Consequentemente, contas duplicadas podem surgir sem aviso. Então o risco mora justamente nessa duplicidade.

Gmail mantém o endereço antigo e isso atinge seu banco de dados

Depois da troca, o Google entrega os emails enviados aos dois endereços. Por isso, o endereço anterior continua válido como alternativo. Para o seu backend, isso muda o modelo mental. O email deixa de ser um valor único e estável.

Imagine um cadastro feito com o endereço antigo. Mais tarde, o mesmo usuário retorna com o novo endereço. Se o sistema compara apenas a string do email, ele cria um segundo registro. Dessa forma, o histórico da pessoa fica partido em dois.

Gmail e a janela de 12 meses antes de nova troca

O Google também impõe um limite temporal. Após a mudança, o usuário fica 12 meses sem criar outro endereço “@gmail.com” para a conta. Logo, a troca não acontece toda hora. Ainda assim, ela acontece, e seu sistema precisa prever isso.

Essa janela ajuda no planejamento. Enquanto o endereço antigo segue ativo, você ganha tempo para reconciliar dados. Portanto, trate esse período como uma migração controlada. Em resumo, prepare o terreno antes que o usuário troque.

Gmail como identidade: por que o email não deveria ser sua chave primária

Aqui mora a lição central para devs. O email é um atributo mutável, não um identificador permanente. Quando você usa “login com Google”, confie no campo “sub” do OpenID Connect. Esse campo é estável e não muda com a troca de endereço.

De fato, o “sub” representa a conta de forma única. Já o email pode mudar a qualquer momento. Por isso, guarde o “sub” como chave e o email apenas como dado de contato. Assim, a troca de endereço deixa de quebrar o seu login.

Caso você não use OAuth, normalize o email antes de salvar. O Gmail ignora pontos no nome de usuário, por exemplo. Além disso, ele aceita o sufixo com “+” para apelidos. Então “ana.silva” e “anasilva” chegam na mesma caixa.

Checklist do seu time de desenvolvimento

Comece auditando onde o email vira chave primária. Depois, migre essas chaves para um identificador interno. Em seguida, adote o “sub” do Google nos fluxos sociais. Por fim, crie uma rotina de reconciliação de contas.

Vale também avisar o time de suporte. Afinal, usuários vão relatar duas contas ou logins estranhos. Com um plano claro, esses chamados diminuem bastante. E a sua base de usuários permanece consistente.

Conclusão

A troca de endereço no Gmail parece um detalhe de produto. Contudo, ela expõe uma fragilidade comum em muitos sistemas. Tratar email como identidade sempre foi arriscado. Agora esse risco fica visível para todos.

Portanto, use identificadores estáveis e normalize seus dados. Dessa forma, a novidade do Google vira uma melhoria, não um problema. No fim, quem cuida da arquitetura de identidade sai na frente. E seus usuários nem percebem a complexidade por trás disso.

Acompanhe nosso perfil no Instagram!