O que fazer quando os e-mails de teste do Google Workspace SMTP Relay são rejeitados em 2026?

O envio de teste recebe uma recusa do relay, ou a aplicação informa sucesso, mas nada aparece na caixa destinatária.

Comece pela resposta SMTP: se houve rejeição, confira IP de saída, remetente permitido, autenticação e identidade HELO/EHLO; se o relay aceitou a mensagem, investigue a entrega e a classificação na caixa. A aceitação do relay não comprova recebimento real: feche o teste com um endereço controlado e evidências da mensagem.

Este guia é para quem envia notificações ou mensagens de verificação do próprio produto pelo Google Workspace SMTP Relay.
Também atende QA que precisa comprovar o recebimento em pré-produção e engenharia que mantém regras, hosts e rotas de saída.

Google Workspace SMTP Relay: diagnostique a rejeição pelo sintoma

Uma falha de envio pode ocorrer em pontos diferentes. A aplicação pode não conseguir abrir a conexão; o servidor pode recusar a autenticação ou a política de relay; ou a mensagem pode ser aceita para processamento e não ficar visível na caixa esperada. Tratar tudo como “e-mail não enviado” mistura causas e incentiva tentativas repetidas sem diagnóstico.

Comece pelo registro da mesma execução, não pela mensagem genérica mostrada na interface do produto. Guarde o horário, o ambiente, o destinatário de teste, o identificador da execução e a resposta SMTP completa. Remova credenciais e dados pessoais antes de compartilhar os registros. Sem esses elementos, fica difícil ligar uma recusa a uma regra específica ou distinguir uma mensagem atrasada de um endereço incorreto.

Os códigos SMTP ajudam a separar estados. Conforme o RFC 5321, que define as classes de respostas SMTP, respostas 2xx indicam conclusão positiva da etapa, 4xx sinalizam falha temporária e 5xx indicam falha permanente naquela tentativa. Isso não identifica, por si só, a causa da política: leia o texto completo da resposta e confronte-o com o registro do serviço. A documentação do Google também relaciona códigos e mensagens comuns às falhas de SMTP no Gmail.

Uma resposta 250 ao fim da transmissão da mensagem tem um significado importante: o servidor aceitou a mensagem e assume a responsabilidade pelo processamento posterior ou por informar uma falha, conforme o RFC. Ela não prova que a mensagem chegou à caixa principal, ficou visível para o usuário ou completou a ação da aplicação. Por isso, registre separadamente “relay aceitou”, “serviço destinatário recebeu” e “fluxo da aplicação concluiu”.

Para uma resposta como “relay denied”, use primeiro o código e a descrição que seu cliente SMTP recebeu. Em seguida, confira as opções da regra em vigor e os requisitos que o Google documenta para o roteamento de mensagens pelo SMTP Relay. Evite deduzir que uma recusa específica sempre significa IP incorreto: o texto e o contexto da sessão são a evidência principal.

A mensagem foi recusada antes de ser aceita

O IP registrado não corresponde à saída real

O endereço cadastrado na regra precisa corresponder ao IP público que efetivamente se conecta ao relay, quando a configuração usa essa forma de identificação. Não use como substituto o endereço de uma máquina local, um IP interno ou o valor de outro ambiente. O caminho de saída pode variar entre desenvolvimento, pré-produção e CI, mesmo quando o código da aplicação é idêntico.

Registre de qual ambiente veio a tentativa e obtenha o IP público observado para aquela conexão. Depois compare-o com a regra ativa do Google Workspace. Se a tentativa passa por NAT, proxy ou infraestrutura compartilhada, confirme a saída no ponto de rede que estabelece a conexão SMTP, não apenas na configuração do host da aplicação.

A documentação oficial descreve os métodos de autenticação e as condições de configuração do relay. Consulte a configuração atual do Google Workspace SMTP Relay junto à regra da sua conta. Não generalize uma confirmação feita em desenvolvimento para o ambiente de CI: cada rota precisa de evidência própria.

Remetente e identidade SMTP não combinam com a regra

Compare o endereço visível em From com o remetente de envelope enviado em MAIL FROM. Eles representam partes diferentes da transação e podem ser tratados de maneira distinta pelas regras. Verifique também o nome apresentado em HELO ou EHLO: use a identidade configurada para o seu domínio e confirme se o serviço reconhece esse valor no contexto da regra ativa.

Não confunda autenticação por IP com SMTP AUTH. São caminhos de identificação diferentes, e os requisitos de um não substituem os do outro. Confira qual método foi habilitado na conta e se o cliente está realmente usando esse método. Um nome de usuário ou segredo aplicado a uma regra baseada em IP não corrige uma saída não autorizada; da mesma forma, o cadastro de IP não prova que uma sessão configurada para autenticação por credenciais está válida.

Para tornar a investigação reproduzível, mude uma condição por tentativa. Se alterar IP, remetente e autenticação ao mesmo tempo, uma eventual aceitação não mostrará qual ajuste resolveu o problema. Anote a regra correspondente, o método usado e o resultado SMTP de cada execução.

Evidência observada	O que verificar	Próxima ação
Resposta de recusa antes da aceitação	IP de saída, regra ativa, método de autenticação	Comparar o ambiente que enviou com as condições da regra
Recusa associada ao remetente	From, MAIL FROM e remetentes permitidos	Conferir a política aplicada à conta e repetir com uma alteração controlada
Sessão termina antes de enviar o conteúdo	Host, porta, TLS ou STARTTLS e resposta do servidor	Separar falha de conexão de rejeição de política
Aceitação SMTP, sem mensagem visível	Endereço destinatário, registros posteriores e pastas	Procurar evidência de entrega e verificar a caixa controlada

A conexão ou o TLS falha antes do envio

Uma conexão TCP aberta só mostra que houve comunicação de rede com um destino. Ela não confirma que o servidor aceitou a sessão SMTP, que houve negociação de TLS, que a autenticação funcionou ou que os dados da mensagem foram transmitidos. Examine a sequência registrada pelo cliente: conexão, saudação do servidor, negociação de segurança, autenticação quando aplicável, comandos SMTP e resposta final.

Confirme o nome do host, a porta e as opções de TLS ou STARTTLS usadas pelo aplicativo com a documentação oficial vigente. Não reutilize automaticamente a configuração de outra biblioteca, serviço ou ambiente: clientes podem ter padrões diferentes, e uma configuração que conecta não necessariamente corresponde ao método autorizado pela regra. A página oficial de configuração do SMTP Relay é a referência para os parâmetros aceitos.

Registre timeout de rede, falha de negociação TLS e recusa de política como resultados separados. Reenviar sem essa distinção pode criar duplicatas e esconder um problema intermitente de conexão. Para cada tentativa, preserve a resposta do servidor e o identificador da execução; nunca inclua senhas, tokens ou conteúdo pessoal nos registros compartilhados.

O relay aceitou, mas a caixa continua vazia

A partir de uma resposta de aceitação, a investigação muda de etapa. Confirme se o endereço destinatário foi montado corretamente e se a aplicação enviou a mensagem para a caixa de teste prevista. Procure evidências posteriores de processamento e entrega; quando houver acesso administrativo, use a pesquisa de registros de e-mail do Google, seguindo o guia oficial do Email Log Search.

Também verifique spam e outras categorias, não apenas a caixa principal. A ausência na tela inicial não prova que o relay recusou a mensagem. A análise de registros pode apontar se houve entrega, atraso ou outro resultado posterior. Para problemas relacionados a spam ou uso do relay, consulte a orientação do Google sobre políticas de spam e abuso do SMTP Relay.

Use um identificador exclusivo no assunto ou em um cabeçalho de teste para associar a mensagem à execução correta. Evite incluir dados reais de clientes: no ambiente de teste, use conteúdo sintético e destinatários controlados. Se precisar compartilhar um registro, oculte endereços pessoais, tokens, identificadores de usuário e conteúdo que não seja necessário para diagnosticar a falha. A política de privacidade da RelayTmp pode ajudar a avaliar informações relacionadas ao uso do serviço, mas não substitui as regras de privacidade da sua própria aplicação.

Etapa do fluxo	Evidência suficiente para avançar	O que essa evidência não prova
Conexão SMTP	O servidor respondeu e a sessão seguiu adiante	Que a mensagem foi aceita
Submissão ao relay	Resposta final de aceitação após transmissão	Que a caixa destinatária a exibiu
Processamento posterior	Registro de entrega ou resultado nos logs disponíveis	Que o usuário concluiu a ação da aplicação
Recebimento controlado	Mensagem localizada e identificada na caixa de teste	Que todas as caixas externas terão o mesmo resultado

Como fechar um teste de recebimento real

Para testar o seu próprio produto ou um ambiente autorizado, conduza uma execução que possa ser reconstruída depois:

1. Escolha um único ambiente. Identifique se a tentativa vem de desenvolvimento, pré-produção ou CI. Anote qual regra de relay deveria atender esse ambiente e confirme que o teste não usa dados de pessoas reais.

2. Defina um destinatário sob controle da equipe. Confira o endereço completo antes do envio. Use uma caixa de teste acessível a quem executa a validação e que não seja uma conta de cliente ou de colega usada para trabalho cotidiano.

3. Crie um marcador exclusivo. Inclua no assunto ou em um cabeçalho um identificador que permita localizar a execução. Não coloque senhas, códigos de acesso reais ou informações pessoais no marcador.

4. Capture a transação SMTP. Guarde o host, o método de autenticação sem registrar segredo, o resultado da negociação TLS, a resposta final do relay e o horário. Se houver recusa, interrompa a análise no ponto indicado e compare-o com a regra, em vez de repetir o envio sem mudanças.

5. Confirme o resultado após a aceitação. Pesquise os registros disponíveis e abra a caixa controlada. Verifique a pasta principal, spam e outras categorias. Se a mensagem não aparecer, registre o resultado como “aceita pelo relay, recebimento não confirmado”; não o classifique como envio concluído.

6. Valide o fluxo da aplicação. Confira se o conteúdo está correto e se o link de verificação ou a notificação produz o resultado esperado no próprio produto. A mensagem visível na caixa e a conclusão da operação são verificações diferentes.

7. Guarde evidências redigidas. Preserve o resultado SMTP, o marcador, o status posterior de entrega e a confirmação da aplicação. Remova credenciais, dados pessoais e conteúdo privado antes de anexar registros a um chamado ou relatório de QA.

Esse procedimento permite dizer exatamente o que o teste comprovou: conectividade, aceitação pelo relay, recebimento na caixa controlada ou conclusão do fluxo do produto. Não transforme um desses resultados em garantia dos demais. O Google também explica como buscar mensagens nos registros administrativos; consulte o Email Log Search quando precisar acompanhar a etapa posterior ao envio.

Perguntas frequentes sobre rejeição e recebimento

O que conferir primeiro quando aparece “relay denied”?
Associe a resposta SMTP ao registro da mesma tentativa e confirme se a sessão chegou ao serviço. Depois compare o IP público de saída, o remetente permitido e o método de autenticação com a regra ativa. Faça uma alteração por execução. Assim, você consegue atribuir a correção a uma condição concreta, em vez de combinar mudanças e perder a causa da rejeição.

Por que o IP cadastrado ainda pode resultar em recusa?
O endereço usado por desenvolvimento pode ser diferente do IP público de saída em pré-produção ou CI. Uma regra também pode exigir condições de remetente ou autenticação que o cadastro do IP não satisfaz. Verifique a rota real da conexão e compare From, MAIL FROM e HELO/EHLO com a regra aplicável. A mensagem SMTP recebida deve orientar a investigação.

Como saber se o SMTP Relay realmente entregou a mensagem de teste?
A aceitação SMTP confirma apenas a submissão aceita naquele ponto do fluxo. Use um marcador exclusivo, procure evidências nos registros posteriores e confirme a mensagem na caixa controlada, incluindo spam e outras categorias. Documente separadamente a resposta do relay, o resultado de entrega disponível e a conclusão do fluxo da aplicação, sem tratar um como prova automática dos outros.

Como diferenciar uma regra incorreta de uma mensagem que caiu no spam?
Uma recusa ocorre durante a sessão SMTP e aparece na resposta do servidor. Se houve aceitação, investigue a entrega posterior, confira o destinatário e procure a mensagem em spam ou outras categorias. Os registros de e-mail podem ajudar a localizar o estágio do fluxo. A caixa principal vazia, sozinha, não prova falha na regra do relay.

Quando a mensagem é apenas um teste de cadastro ou notificação do seu próprio produto, uma caixa controlada ajuda a conferir o conteúdo sem envolver endereços pessoais. A RelayTmp pode ser considerada como uma opção para esse tipo de validação; consulte a página do serviço e confirme os recursos disponíveis para o seu caso antes de depender dela. Para contas importantes, que exigem recuperação duradoura, respostas ou histórico contínuo, prefira um endereço corporativo ou uma caixa de teste permanente.

Perguntas frequentes

Comece um teste limpo

Abrir caixa de entrada descartável

Abra a caixa de entrada descartável, copie o endereço e atualize a página para ler e-mails reais de teste no mesmo lugar.

Abrir a caixa de entrada