As formas de acesso à conta do Gmail (login via web, IMAP e API) têm as seguintes diferenças:

Um script precisa ler automaticamente um e-mail de verificação. Você pega o login e a senha, coloca em um cliente IMAP e recebe um erro de falha no login — o problema não são as credenciais, e sim ter escolhido o método de acesso errado. Uma conta do Gmail pode ser "usada" de mais de uma forma: login pela web, IMAP/SMTP e API do Gmail. Cada um desses três caminhos tem requisitos diferentes para a conta e faz coisas distintas. Escolher o errado não significa que a conta está quebrada, mas que o método de acesso não é compatível.

Quais são os três métodos de acesso

Método	Essência	O que a conta precisa ter
Login pela web	Abrir o gmail.com no navegador e seguir o fluxo normal de login humano	Senha + 2FA (se ativado), pode disparar captcha/detecção de login suspeito
IMAP/SMTP	Clientes de e-mail (Outlook, Thunderbird, bibliotecas de script) usam protocolos de e-mail para enviar e receber mensagens diretamente	É obrigatório ativar a 2FA primeiro e depois gerar uma "Senha de app" específica. Use essa senha de app, não a senha da conta em si, para fazer login
API do Gmail	Interface de programação oficial do Google, que usa OAuth2 para obter um token de acesso. O programa usa esse token para chamar as APIs e ler/escrever e-mails	É preciso registrar um projeto no Google Cloud, configurar um cliente OAuth e passar pelo fluxo de autorização uma vez para obter o token

Login pela web: o mais intuitivo, mas não serve para automação

Para uso manual, funciona bem. Mas tentar simular um login pela web com um script vai esbarrar em captchas, alertas de login suspeito e até pedidos de verificação por celular — o Google tem um sistema de segurança próprio para comportamentos que "parecem automatizados". O problema não é a conta, é a incompatibilidade entre o método de login e o uso pretendido.

IMAP/SMTP: ideal para clientes de e-mail e scripts leves

Essa é a forma mais próxima do "envio e recebimento tradicional de e-mails". A maioria dos clientes de e-mail e bibliotecas Python/Node para e-mail oferecem suporte. O ponto chave é: a conta precisa ter a 2FA ativada. Use a "Senha de app" gerada pela 2FA para fazer login no IMAP. Não use a senha normal da conta — atualmente, o Google exige esse passo para a maioria das contas de consumidor. Tentar conectar no IMAP diretamente com o login e a senha da conta provavelmente será rejeitado.

Se você vir o campo "Senha de app" na listagem da conta, significa que a conta já tem uma senha de app pronta para uso. Você pode usar essa senha diretamente para conectar via IMAP, sem precisar ativar a 2FA e gerar uma nova.

API do Gmail: ideal para integrações programáticas sérias

A API do Gmail usa autorização OAuth2. O programa recebe um token de acesso com um escopo (scope) de permissões definido, não a senha da conta em si. A vantagem é que as permissões podem ser controladas com precisão (por exemplo, só leitura, sem alteração) e o token pode ser revogado individualmente sem afetar a senha da conta. É a melhor escolha para cenários que exigem operação estável a longo prazo e gerenciamento de permissões. O custo é uma configuração inicial mais trabalhosa: é preciso registrar um aplicativo no Google Cloud e configurar as credenciais. Não é algo que se faça só com a conta em mãos.

Qual escolher

• Uso manual ocasional para dar uma olhada: O login pela web é suficiente. Não precisa se preocupar com outros métodos.
• Script para ler códigos de verificação/enviar e-mails regularmente, buscando simplicidade: IMAP/SMTP + Senha de app. Se a listagem da conta tiver esse campo, já pode usar.
• Integração em um produto formal, operação de longo prazo, necessidade de controle refinado de permissões: API do Gmail. A configuração inicial dá mais trabalho, mas a operação é mais estável no futuro.

Armadilhas comuns

• Tentar conectar no IMAP com login e senha normais e receber erro. Provavelmente a conta não tem 2FA ativada ou não gerou uma Senha de app. Faça login pela web uma vez, ative a 2FA, gere a Senha de app e tente novamente.
• Script simulando login pela web é barrado por verificação suspeita. Mude para IMAP ou API do Gmail. Não tente forçar o fluxo de login pela web com um script.
• Token da API do Gmail expirou ou não tem permissão suficiente. Verifique se o escopo (scope) selecionado na hora da solicitação inclui a interface que você precisa usar. Se o token expirar, use o refresh token para obter um novo access token. O problema não é a conta em si.

Limitações que você precisa saber antes de comprar

• O funcionamento tranquilo dos três métodos de acesso depende não só dos campos disponíveis na conta, mas também das políticas do Google, que podem mudar. Não há garantia de que funcionarão para sempre.
• Senhas de app e tokens OAuth podem ser invalidados por alteração de senha ou verificações de segurança na conta. Se isso acontecer, será necessário gerar novos.
• O método de acesso suportado por uma conta específica deve ser verificado na descrição do produto.

Perguntas frequentes

Uma conta que não tem o campo "Senha de app" pode ter esse recurso ativado por conta própria? Sim, desde que a conta permita o login normal pela web e a ativação da 2FA. Depois de ativar a 2FA, você pode gerar uma Senha de app nas configurações de segurança da conta. É o mesmo mecanismo de formato 2FA mencionado no artigo sobre a relação entre Conta Google e Gmail.

Posso usar IMAP e a API do Gmail ao mesmo tempo na mesma conta? Sim, um não interfere no outro. Eles usam credenciais de login diferentes (Senha de app vs. token OAuth) e não se afetam mutuamente.

Por que as permissões obtidas pela API do Gmail precisam ser reautorizadas depois de um tempo? Os tokens OAuth têm um prazo de validade. O fluxo normal é usar o refresh token correspondente para obter um novo access token de forma silenciosa. Se o refresh token também expirar (por exemplo, devido a uma alteração de senha da conta), aí sim o usuário precisará passar pelo fluxo de autorização novamente.