O cliente conecta ao SMTP do Gmail, tenta autenticar e retorna 535 5.7.80.
Nesta semana, comece verificando o mecanismo e as credenciais que o cliente realmente envia; depois valide, em separado, autenticação, submissão da mensagem e recebimento. O erro indica que o Gmail recusou a autenticação atual, mas não prova que a senha foi digitada incorretamente. Corrigir o login também não confirma que o e-mail de teste chegou.
Este guia é para quem depura a autenticação SMTP de um produto próprio, para QA que precisa comprovar cada etapa do envio e para pessoas que mantêm ambientes de teste sem expor tokens ou links de validação nos registros.
A recusa de autenticação não é uma falha de entrega
A documentação do Google relaciona o código 535 5.7.80 a nome de usuário ou senha não aceitos pelo servidor. Isso localiza a resposta no processo de autenticação. Não permite concluir, sem verificar a configuração efetiva, que a causa seja uma senha incorreta. A descrição oficial do erro SMTP serve para reconhecer a resposta, não para diagnosticar sozinha todos os motivos possíveis.
Essa distinção evita duas investigações no lugar errado:
- Se o cliente recebeu 535 durante
AUTH, investigar primeiro o mecanismo, a identidade da conta e as credenciais ou o token enviados. - Se o cliente ainda não conseguiu estabelecer a conexão segura, investigar a conexão e o acordo de TLS. Isso não é a mesma etapa que uma autenticação SMTP recusada.
- Se o servidor aceitou a autenticação, mas não houve confirmação de recebimento, passar a investigar a submissão e a entrega. Não atribuir automaticamente essa falha ao 535 anterior.
O SMTP AUTH tem respostas próprias para indicar sucesso ou falha de autenticação. O RFC 4954 descreve essas respostas no protocolo, mas não identifica a causa específica da recusa de uma conta Gmail. Para isso, compare o erro completo com o comportamento do seu cliente.
Primeiro compare o mecanismo configurado com o que foi enviado
O Gmail SMTP oferece autenticação com OAuth 2.0 e o mecanismo SASL XOAUTH2. A documentação do Google explica como o Gmail oferece SMTP e os requisitos de conexão e descreve o formato do protocolo XOAUTH2.
Na prática, a configuração declarada no arquivo do ambiente não basta. Um valor pode estar ausente, ser substituído por uma variável diferente ou não ser usado pelo cliente SMTP que está executando o teste. Inspecione a configuração carregada pelo processo e, se o registro do cliente permitir, confirme o mecanismo enviado durante a autenticação.
Para XOAUTH2, o cliente apresenta a identidade do usuário e um token Bearer na resposta SASL. O formato documentado usa separadores de controle entre os campos. Não trate isso como uma senha comum nem copie a resposta completa de autenticação para um registro compartilhado: ela pode conter credencial reutilizável.
Se a aplicação foi configurada para OAuth 2.0, mas os registros mostram outro mecanismo, corrija a divergência antes de trocar senhas ou renovar tokens. Se o mecanismo é XOAUTH2, prossiga para conferir se o token pertence à identidade esperada e se foi obtido com a autorização adequada. A documentação de OAuth 2.0 para aplicações de servidor do Google ajuda a conferir o fluxo e o tratamento das credenciais.
Um token que parece válido no armazenamento não prova que o cliente o enviou, que ele representa a conta certa ou que a conexão atual usa XOAUTH2. Registre o mecanismo e a identidade de teste; não registre o valor do token.
Confirme identidade, token e autorização sem misturar causas
Um caso frequente em ambiente de teste é ter mais de uma conta configurada: uma conta gera o token, enquanto outra aparece como usuário SMTP. Compare a identidade usada na autenticação com a conta para a qual a aplicação obteve autorização. Se não forem a mesma, ajuste a configuração e execute um teste controlado.
Depois confira o ciclo do token:
- Confirme que o processo recebeu o token esperado para aquela tentativa, em vez de reutilizar um valor antigo ou vazio.
- Verifique se a autorização concedida ao aplicativo é compatível com a operação SMTP planejada.
- Confira se o token ainda pode ser usado e se não foi revogado ou substituído antes da conexão.
- Compare a resposta completa do servidor, sem reduzir o diagnóstico a uma mensagem próxima ou a um código diferente.
Uma mensagem de autenticação parecida não significa necessariamente a mesma causa. A resposta oficial 535 5.7.80 deve ser avaliada como tal; não se deve transferir para ela a interpretação de outro erro do Gmail apenas porque os textos parecem semelhantes. O código é evidência da recusa, não um relatório completo do estado do fluxo OAuth.
O segredo também faz parte do diagnóstico. Não cole tokens, senhas, cabeçalhos de autorização ou links completos de redefinição em chamados, capturas de tela ou registros de CI/CD. Para correlacionar tentativas, use um identificador de execução sem dados pessoais. Se um segredo foi exposto, trate a exposição como incidente de credencial, não como simples problema de formatação.
Conexão, TLS e AUTH precisam ser verificados em ordem
O servidor, o modo de início da conexão segura e o mecanismo de autenticação precisam corresponder ao que a aplicação realmente executa. Consulte a documentação do Gmail para conferir as opções de conexão suportadas; evite copiar configurações de um exemplo destinado a outra biblioteca ou outro serviço.
| Evidência observada | O que ela permite concluir | Próxima verificação |
|---|---|---|
A conexão segura não se estabelece e não há resposta de AUTH |
A tentativa ainda não chegou à autenticação SMTP | Confira o servidor configurado e a forma de negociação TLS |
O cliente envia AUTH e recebe 535 5.7.80 |
O Gmail recusou a autenticação apresentada | Confira o mecanismo efetivo, a conta e as credenciais ou o token |
| A autenticação passa, mas a mensagem não é aceita para submissão | A falha ocorre depois da autenticação e antes da confirmação de submissão | Analise a resposta SMTP da tentativa de envio e o conteúdo transmitido |
| O servidor aceita a mensagem, mas o endereço controlado não a mostra | Há aceitação para processamento, não prova de recebimento na caixa de entrada | Verifique o resultado no endereço de teste e a situação da mensagem |
Essa separação também evita um erro de interpretação comum: uma conexão estabelecida não quer dizer que houve autenticação bem-sucedida; autenticação bem-sucedida não quer dizer que a mensagem foi aceita; e aceitação não equivale à confirmação de chegada na caixa de entrada. O RFC 5321 explica a responsabilidade do servidor após aceitar uma mensagem. Essa regra não transforma a resposta de aceitação em prova de que o destinatário a visualizou.
Decida o próximo passo pela evidência disponível
Use estas condições em vez de repetir o teste com alterações aleatórias:
- Se não há resposta de
AUTH, corrija primeiro a conexão e o TLS. Repetir a troca de token não resolve uma falha que acontece antes da autenticação. - Se o cliente envia um mecanismo diferente de XOAUTH2 quando a configuração deveria usar OAuth 2.0, ajuste a configuração efetiva ou o cliente antes de renovar credenciais.
- Se o cliente usa XOAUTH2, mas a conta ou a autorização não corresponde à conexão, gere ou obtenha a autorização correta para o cenário e repita o teste em ambiente controlado.
- Se o mecanismo, a identidade e a autorização parecem corretos, mas persiste o 535, preserve a resposta original e investigue a implementação específica do cliente e a resposta de autenticação. Não declare a causa como “senha errada” sem evidência.
- Se a autenticação passou, pare de tratar a tentativa como falha 535 e avance para medir submissão e recebimento.
A vantagem desse fluxo é que cada mudança responde a uma hipótese verificável. A desvantagem é que pode exigir registros mais cuidadosos do que simplesmente trocar a senha e tentar de novo. Ainda assim, evita alterar vários fatores ao mesmo tempo e perder a pista que explicaria a recusa.
Execute uma validação reproduzível do seu próprio produto
Siga esta sequência apenas no produto e no ambiente que você tem autorização para testar.
- Registre a falha sem revelar segredos. Guarde o texto SMTP completo, o horário da execução e a etapa em que ocorreu. Remova tokens, senhas, dados pessoais e links de validação antes de compartilhar os registros.
- Identifique o processo que abriu a conexão. Confira qual configuração foi carregada pela aplicação em execução, incluindo o servidor SMTP, o modo TLS e o mecanismo AUTH. Não confie apenas no arquivo de configuração salvo.
- Compare mecanismo e identidade. Se a intenção é usar OAuth 2.0, confirme que o cliente efetivamente envia SASL XOAUTH2 e que a identidade apresentada corresponde à conta autorizada para aquela tentativa.
- Revise a autorização do token. Verifique origem, escopo aplicável e estado do token. Faça isso por metadados ou pelo fluxo seguro da aplicação; não imprima o token no terminal nem o inclua em um chamado.
- Repita uma tentativa controlada. Mude uma hipótese por vez e preserve o resultado SMTP. Se o 535 continuar, anote o mecanismo e a identidade em forma protegida para comparar execuções.
- Separe a confirmação de autenticação da submissão. Quando AUTH passar, envie uma mensagem de teste identificável para um endereço controlado. Registre a resposta que o servidor deu à tentativa de submissão.
- Confirme o recebimento fora do processo de envio. Consulte a caixa do destinatário e as pastas disponíveis. Associe a mensagem à execução pelo assunto ou por um identificador não sensível, sem incluir dados reais de usuário.
- Escreva a conclusão com limites claros. Informe se a autenticação passou, se a mensagem foi aceita para processamento e se apareceu no endereço controlado. Declare que o resultado vale para aquela configuração, ambiente e tentativa; não o estenda automaticamente a produção.
Para escolher um destinatário de teste, use um endereço controlado e separado dos dados reais de clientes. Um endereço temporário pode ser uma opção quando o objetivo é receber uma mensagem de verificação sem expor a caixa principal. Consulte as informações do SendTmp e do acesso a uma caixa temporária antes de decidir se esse tipo de endereço atende ao teste. A política de privacidade do serviço também é relevante quando o conteúdo da mensagem inclui dados de teste.
Registre três resultados, não um veredito genérico
No relatório de QA ou no chamado, separe as evidências em três linhas:
- Autenticação: mecanismo efetivo e resposta recebida do servidor, sem qualquer credencial.
- Submissão: se a aplicação enviou a mensagem e qual resposta SMTP recebeu nessa etapa.
- Recebimento: se a mensagem foi observada no endereço controlado e como foi correlacionada com a execução.
Essa estrutura evita registrar “SMTP funcionando” quando apenas a autenticação passou, ou “e-mail enviado” quando o servidor ainda não aceitou a mensagem. Também limita a conclusão: um teste bem-sucedido não prova que toda conta, ambiente, destinatário ou caminho de envio terá o mesmo resultado.
Se o cenário exigir resposta do destinatário, histórico duradouro ou recuperação de uma conta importante, um endereço temporário não é a escolha adequada. Para um teste pontual de cadastro ou verificação em seu próprio produto, ele pode evitar expor a caixa de trabalho. Quando a execução precisa de encaminhamento para outro endereço, avalie também as condições de encaminhamento de e-mails do SendTmp, sem presumir que isso substitui a confirmação no destino.
Perguntas frequentes sobre a recusa SMTP
O que significa o código 535 5.7.80 no Gmail SMTP?
O Google associa essa resposta a nome de usuário ou senha não aceitos. O ponto decisivo é a etapa: se ela aparece depois de AUTH, o Gmail recusou os dados de autenticação apresentados pelo cliente. Isso não identifica, por si só, se a causa foi senha, mecanismo, identidade ou token. Compare a resposta original com a configuração realmente carregada.
Como confirmar que o cliente usa OAuth 2.0?
Verifique a configuração ativa e o mecanismo SASL que o cliente envia na conexão, em vez de se apoiar apenas no arquivo de configuração ou no código-fonte. Para Gmail SMTP com OAuth 2.0, procure o uso de XOAUTH2 e confirme que o token Bearer representa a conta esperada. Faça essa inspeção sem registrar nem compartilhar o valor do token.
O que fazer se o token parece válido, mas a autenticação continua recusada?
Compare a conta representada pelo token com a identidade usada na autenticação SMTP e confira se o aplicativo recebeu a autorização necessária para essa operação. Confirme também se a execução atual usa o token esperado. Um token aparentemente válido não demonstra que seja o token correto para aquela conta ou conexão. Preserve a resposta completa, mas remova qualquer credencial dos registros.
Como verificar o recebimento depois que a autenticação passa?
Envie uma mensagem controlada pelo próprio produto para um endereço de teste que você possa consultar. Registre a resposta SMTP à submissão e, separadamente, procure a mensagem na caixa do destinatário e nas outras pastas disponíveis. A aceitação pelo servidor não prova que a mensagem chegou à caixa de entrada; só a observação no endereço controlado fornece essa evidência para o teste.
Depois de corrigir o 535, um endereço de teste separado pode ajudar a confirmar se a mensagem do seu produto realmente chegou, sem misturar a validação com a caixa principal. Para um teste pontual de cadastro ou verificação, o SendTmp é uma opção de recebimento temporário: use-o como destinatário controlado e registre o resultado observado, sem presumir entrega garantida.
Perguntas frequentes
O que indica o erro 535 5.7.80 no Gmail SMTP?
Ele indica que o Gmail recusou a autenticação SMTP apresentada pelo cliente. A documentação do Google associa essa resposta a nome de usuário ou senha não aceitos, mas isso não prova que a senha digitada seja a única causa. O cliente pode estar usando um mecanismo diferente do esperado ou enviando credenciais que não correspondem à conta autorizada.
Como saber se meu cliente está usando OAuth 2.0 no Gmail SMTP?
Confira a configuração efetiva do cliente e os registros de inicialização da conexão, não apenas a configuração pretendida no código. O mecanismo deve aparecer como SASL XOAUTH2 e a resposta de autenticação deve usar um token Bearer associado à conta correta. O Google documenta esse formato; proteja os registros para que não revelem o token.
Por que o Gmail pode recusar um token OAuth aparentemente válido?
Um token ainda utilizável não garante que ele seja apropriado para aquela tentativa SMTP. Confirme a conta representada, a autorização concedida ao aplicativo, o escopo necessário e se o token enviado é realmente o obtido para aquela conexão. Compare esses dados com o mecanismo configurado e a resposta SMTP original, sem deduzir a causa apenas por mensagens parecidas.
Como comprovar que o e-mail chegou depois que a autenticação passou?
Registre separadamente o resultado da autenticação, a resposta do servidor à submissão da mensagem e a observação de recebimento em um endereço controlado. Depois, procure a mensagem na caixa de entrada e em outras pastas disponíveis, correlacionando-a com o teste. Uma resposta de aceitação do servidor não comprova, sozinha, que a mensagem apareceu na caixa de entrada.