landing · serviço de relay SMTP do Google

O que uma equipe de produto deve avaliar ao escolher o serviço de relay SMTP do Google?

Escolha o relay SMTP do Google Workspace somente quando o seu modelo administrativo, de identidade e de cotas se encaixar na carga de trabalho. Confirme quem é o dono do domínio do Workspace e da configuração no Admin console, se a aplicação pode usar um IP público estável em lista de permissões ou autenticação SMTP protegida por TLS, quais remetentes de envelope são permitidos e como o TLS é aplicado. Modele os limites atuais do Google por usuário, por cliente e por transação antes da implantação. Teste erros temporários e permanentes, preserve as respostas SMTP, autentique o remetente visível com SPF, DKIM e DMARC e mantenha a aceitação, a entrega ao servidor do destinatário e a chegada à caixa de entrada como resultados separados.

Comece pela adequação à carga de trabalho e à administração

O serviço de relay SMTP do Google é uma rota administrativa do Google Workspace para aplicações, dispositivos e servidores de e-mail que enviam por smtp-relay.gmail.com. Avalie-o como parte da fronteira do Workspace e de segurança de e-mail da organização, não como um endpoint SMTP genérico e anônimo. Identifique o superadministrador responsável pelo Workspace, os domínios da conta, os sistemas de origem, os IPs públicos de saída, os endereços de remetente, as classes de mensagem, o volume de destinatários de pico e diário, o perfil de anexos e o contato para incidentes. Decida se a carga de trabalho é transacional, operacional interna, composta por usuários, em massa para assinantes ou gerada por dispositivos. Mantenha essas classes separadas, porque as necessidades de autorização, consentimento, supressão, auditoria e reputação são diferentes. Confirme que os ambientes inferiores não conseguem usar as rotas de produção nem endereços de clientes. Um relay pode transportar uma mensagem autorizada; ele não decide se o evento de negócio é legítimo, se um destinatário consentiu ou se o estado posterior da aplicação deve avançar.

Compare a autorização por IP com a autenticação SMTP

A configuração atual do Google permite que os administradores restrinjam a entrada do relay a endereços IP públicos especificados, exijam autenticação SMTP sobre TLS ou combinem opções de política conforme a configuração documentada. A autorização por IP estável pode servir para data centers controlados ou gateways de saída fixos, mas fica frágil atrás de NAT em nuvem que muda, várias regiões, serviços de failover ou redes de terceiros. A autenticação SMTP identifica uma conta do Workspace e um domínio de envio, mas introduz o ciclo de vida das credenciais, o status do usuário, interações com autenticação multifator e políticas e uma exigência rígida de TLS. Nunca use uma única credencial ampla entre tenants ou aplicações não relacionadas. Para cada opção, documente quem pode adicionar um IP ou uma conta, como as mudanças são revisadas, como um comprometimento é detectado, como o acesso é revogado e o que o failover faz. Mantenha as faixas de IP permitidas tão pequenas quanto possível e verifique o endereço público de saída a partir do runtime real, em vez de copiar um endereço interno.

Defina os remetentes permitidos e a identidade do domínio

A configuração de relay no Admin console controla quais remetentes são permitidos. O Google documenta opções ligadas a usuários registrados do Apps e a endereços em domínios próprios, além de uma opção mais ampla de qualquer endereço, que aumenta a exposição a abusos. Escolha a opção mais restrita que a carga de trabalho consiga atender. Faça o inventário do remetente do envelope SMTP independentemente dos campos From e Reply-To visíveis. O Google observa que, quando um remetente está fora dos domínios da conta, o SMTP AUTH ou um domínio apresentado no HELO ou EHLO pode afetar como o remetente do envelope é identificado ou reescrito. Não dependa da reescrita como substituta de um modelo de remetentes próprio. Exija um mapeamento aprovado entre aplicação, tenant, classe de mensagem, remetente do envelope, domínio From visível e return path. Bloqueie cabeçalhos arbitrários fornecidos pelo usuário, injeção de quebras de linha e endereços From de outros tenants antes de se conectar ao Google. Teste o roteamento de bounces e as mensagens de ausência, incluindo um remetente de envelope vazio, sem enfraquecer a configuração inteira.

Exija a segurança de transporte de forma deliberada

O guia de relay atual do Google direciona sistemas locais com TLS para smtp-relay.gmail.com na porta 587 e explica que a autenticação SMTP exige TLS. A configuração no Admin também pode exigir TLS nas conexões do servidor de envio. Ative o TLS obrigatório em produção, a menos que uma restrição legada documentada tenha uma exceção com prazo definido. Valide o nome do servidor, a cadeia de certificados, a política de protocolos e cifras suportados, a negociação STARTTLS e o comportamento em caso de falha. O cliente precisa falhar de forma segura se o TLS exigido não puder ser estabelecido; voltar silenciosamente para texto puro anula a política. Proteja as credenciais SMTP em um cofre de segredos gerenciado e mantenha-as fora de linhas de comando, URLs, código-fonte, logs, analytics, relatórios de falhas e tickets. O TLS de transporte protege o salto até o Google, não todo o ciclo de vida da mensagem nem a caixa postal. Conteúdos sensíveis podem precisar de controles no nível da aplicação, minimização de dados, retenção e decisões separadas sobre criptografia de ponta a ponta.

Modele as cotas atuais antes de escolher o relay

A documentação atual de configuração do relay SMTP do Google afirma que cada usuário pode enviar até 10.000 mensagens e para no máximo 10.000 destinatários únicos em um período de 24 horas, com limites possivelmente menores em contas de teste. Ela também documenta um limite de 100 destinatários por transação SMTP e controles adicionais por cliente, de pico e diários. Trate esses valores como tetos documentados atuais, não como meta de capacidade nem contrato permanente. Consulte novamente a página oficial para a conta e a carga de trabalho antes do lançamento. Calcule destinatários, não apenas mensagens, considerando To, Cc, Bcc, novas tentativas e fan-out. Coloque controles de taxa, concorrência, idade da fila e justiça entre tenants no nível da aplicação abaixo dos limites do Google. Gere alertas sobre aceleração e sobre a folga restante. Não responda a um limite distribuindo o tráfego entre contas não autorizadas, alternando remetentes de envelope ou abrindo conexões sem controle. Uma carga de trabalho que se aproxima regularmente de uma fronteira compartilhada do Workspace pode precisar da avaliação de um transporte construído para esse fim.

Construa um fluxo de submissão durável

Coloque o cliente SMTP atrás de um worker de servidor autorizado ou de uma fila. Persista um job de saída com uma chave estável do evento de negócio, tenant, classe de mensagem, revisão do template, remetente e destinatários aprovados, base de consentimento ou necessidade, decisão de supressão e histórico de tentativas. Reivindique esse job uma única vez, renderize e valide o conteúdo e depois conecte-se ao endpoint do Google configurado. Limite os destinatários por transação e o tamanho da mensagem de acordo com os limites atuais e a política do produto. Registre a resposta SMTP completa, o código de status estendido, o host remoto, o timestamp e o identificador da tentativa, sem registrar credenciais ou conteúdo desnecessário. Se o relay aceitar a transação DATA, marque apenas a etapa de aceitação pelo provedor ou relay. Se o cliente atingir o timeout depois de enviar os dados, mas antes de observar a resposta final, mantenha a tentativa como desconhecida e reconcilie-a antes de reenviar. O SMTP não oferece uma chave de idempotência da aplicação; por isso, o controle de duplicatas cabe à fila e ao modelo de eventos do produto.

Classifique os erros do relay em vez de tentar tudo de novo

A página de erros do relay SMTP do Google documenta condições distintas, incluindo relay de e-mail negado, credenciais de relay ou identificação de domínio inválidas, limite diário excedido, adiamento temporário por limite de pico e excesso de destinatários em uma transação. Capture a resposta exata e mapeie-a para uma classe interna restrita. Corrija erros de configuração, domínio do remetente, credenciais, IP e destinatários por transação antes de reenviar. Pause ou reagende o trabalho após o esgotamento do limite diário. Tente novamente erros temporários elegíveis de pico ou de transporte com backoff exponencial, jitter, limite de tentativas e limite de idade da fila. Nunca tente novamente indefinidamente uma resposta permanente. Se um erro citar um IP não registrado, confirme o endereço público de saída real do runtime e a configuração correta do Workspace, em vez de ampliar a lista de permissões. Preserve contagens agregadas com privacidade minimizada por sistema de origem, revisão de configuração, domínio do remetente, classe de status e horário. Gere alertas para respostas novas e picos de autenticação, porque podem indicar desvio de política, revogação de credenciais, mudança de NAT ou abuso.

Autentique o remetente além do acesso ao relay

Ter permissão para usar o relay do Google não é o mesmo que ter autenticação de remetente voltada ao destinatário. Publique uma política SPF que autorize o caminho de envio real para a identidade do envelope, configure a assinatura DKIM com um domínio controlado pela organização e alinhado ao DMARC e publique uma política DMARC revisada para o domínio From visível. Verifique a mensagem bruta recebida em caixas postais externas controladas. Registre o resultado e o domínio do SPF, o resultado do DKIM, o domínio d= e o seletor, o domínio From visível, o alinhamento e o resultado do DMARC. Uma assinatura tecnicamente válida do provedor ou do Workspace pode continuar sem alinhamento com um domínio From personalizado. O encaminhamento também pode alterar as evidências de SPF. Não adicione um segundo registro SPF nem enfraqueça o DMARC em toda a organização só para fazer um teste passar. Coordene os administradores de DNS e de e-mail, preserve os registros anteriores, teste as respostas autoritativas e recursivas e implante uma mudança de identidade por vez.

Exija observabilidade e um caminho de saída testado

Use a pesquisa de logs de e-mail do Google Admin e os logs do lado do relay quando disponíveis, mas mantenha o registro de saída do próprio produto como o sistema de decisão. Monitore idade da fila, aceitação, respostas temporárias e permanentes, uso dos limites, sinais de bounce e reclamação, autenticação e latência por classe de mensagem e domínio do remetente. Restrinja o acesso e evite endereços completos ou conteúdo nas métricas de rotina. Teste mudanças de IP de origem, rotação de credenciais, falha de TLS, desativação da configuração no Admin, suspensão de usuário, esgotamento de limites, fan-out de destinatários, mudanças de DNS e indisponibilidade do provedor. Defina um rollback que consiga pausar o grupo afetado sem descartar jobs duráveis. Para a migração, isole os campos SMTP específicos do provedor em um único adaptador e preserve as chaves de eventos de negócio, o estado de supressão, a autorização de remetentes e o histórico de tentativas. Um segundo relay não pode se tornar um desvio automático para rejeições permanentes de política ou de destinatários. Compatibilidade exige testes no nível dos campos e dos erros, não apenas a troca de um hostname.

Como o SendHQ se encaixa

O SendHQ é uma API de e-mail com escopo por workspace para comunicação de produto esperada, com envio com domínio verificado, e-mail de entrada, templates hospedados, eventos de entrega, supressões e um painel web. Compare-a com o relay SMTP do Google Workspace por meio da documentação atual e de testes controlados para limites de conta e tenant, credenciais e rotação, aplicação de remetentes permitidos, identidades de envelope e visíveis, falha de TLS, limites de destinatários, respostas temporárias e permanentes, resultados ambíguos, supressões, leitura de eventos e migração.

Perguntas frequentes

Qual hostname o Google Workspace usa para o relay SMTP?

O guia de configuração atual do Google usa smtp-relay.gmail.com. Escolha a porta e o comportamento de TLS a partir das instruções oficiais e da política de segurança aplicada na organização.

O relay SMTP do Google pode ser restrito por IP de origem?

Sim. A configuração no Admin pode aceitar apenas endereços IP públicos especificados. Mantenha as faixas restritas e verifique o endereço de saída real do runtime e o comportamento em failover.

A autenticação SMTP funciona sem TLS neste relay?

O guia atual do Google diz que a autenticação SMTP exige TLS. Clientes de produção devem falhar de forma segura (fail closed) se a negociação de TLS exigida ou a validação do certificado não forem bem-sucedidas.

Quantos destinatários uma transação do relay SMTP pode conter?

Atualmente, o Google documenta um limite de 100 destinatários por transação em smtp-relay.gmail.com. Consulte novamente a página oficial em vigor, porque os limites do provedor e as condições da conta podem mudar.

Um erro de limite de pico do relay deve ser tentado novamente?

O Google descreve o esgotamento do limite de pico como temporário. Mantenha o mesmo job durável e use backoff limitado, jitter, limite de tentativas e limite de idade da fila, em vez de um fan-out imediato.

A aceitação pelo relay significa que o destinatário recebeu o e-mail?

Não. A aceitação pelo relay é uma etapa do transporte. A aceitação pelo servidor do destinatário, um bounce posterior, a filtragem da caixa postal, a chegada à caixa de entrada e o engajamento humano continuam sendo observações separadas.

O acesso ao relay do Google pode substituir SPF, DKIM e DMARC?

Não. A autorização do relay controla o uso do serviço do Google. A autenticação voltada ao destinatário e o alinhamento DMARC exigem identidades de envio, registros DNS e assinaturas corretos, além da verificação das mensagens recebidas.

Esta página comprova que o SendHQ é compatível com o relay SMTP do Google?

Não. Compare os recursos documentados do SendHQ com os requisitos de relay SMTP do Google Workspace e use testes controlados para autenticação, TLS, cotas, erros e leitura de eventos de entrega.

Fontes

Continue aprendendo

Como avaliar um serviço de relay SMTPAvalie serviços de relay SMTP por segurança na submissão, autenticação, filas, comportamento de novas tentativas, limites, eventos de entrega, supressão, isolamento e adequação à migração.Protocolo SMTP: como os e-mails de aplicação trafegamEntenda como a submissão SMTP, o relay, os envelopes, os códigos de resposta, o TLS, as novas tentativas e o conteúdo da mensagem moldam o fluxo de e-mails de uma aplicação.Portas SMTP 25, 465 e 587: guia práticoEscolha a porta SMTP certa por função e modo de TLS e depois diagnostique falhas de conexão, handshake, autenticação e aceitação de mensagens.Como avaliar um serviço de entregabilidade de e-mailAvalie serviços de entregabilidade de e-mail por escopo, evidências, autenticação, feedback loops, supressões, privacidade, portabilidade e adequação operacional.Guia de implementação da Gmail API para equipes de produtoImplemente o acesso à Gmail API com OAuth de privilégio mínimo, sincronização durável da caixa postal, envio seguro, novas tentativas limitadas e um modelo claro de contas de serviço.