Encaminhar e-mails do domínio ao Gmail: guia de configuração

Você configura contact@yourdomain.com para encaminhar os e-mails do domínio ao Gmail. Um cliente envia um contrato. Um banco envia um alerta de segurança. Nenhuma das mensagens aparece.

Você verifica o spam e não encontra nada. Na sua conta, não há sinal das mensagens, erro ou notificação. O recebimento de um aviso pelo remetente original depende do fluxo de entrega.

Isso não precisa ser um problema do Gmail em si. Uma possível causa é a autenticação. Ao encaminhar e-mails do domínio para o Gmail, seu servidor retransmite uma mensagem de terceiros usando seu próprio IP. Se o remetente do envelope for preservado, o Gmail verifica SPF para o domínio original, que normalmente não autoriza seu IP. SPF falha. Com uma política DMARC rigorosa (p=reject) e sem uma assinatura DKIM válida e alinhada, o Gmail pode rejeitar a mensagem com 550-5.7.26. O servidor de encaminhamento recebe esse erro SMTP; uma notificação de não entrega pode chegar ao remetente original, enquanto você não recebe nenhum aviso.

A reescrita do remetente do envelope com SRS (Sender Rewriting Scheme) e o registro da autenticação com ARC (Authenticated Received Chain) podem ajudar no encaminhamento ao Gmail. São componentes importantes da infraestrutura, mas não garantem alinhamento DMARC nem entrega. Uma assinatura DKIM válida e alinhada que sobreviva ao encaminhamento também pode fazer DMARC passar mesmo quando SPF falha.

Este guia aborda a configuração: reescrita SRS, prevenção de loops e a opção “Enviar e-mail como” do Gmail. Para entender os protocolos, a interação de SPF, DKIM e DMARC no encaminhamento e o funcionamento técnico de SRS, consulte o guia completo de configuração e correção do encaminhamento de e-mail.

Por que o Gmail pode rejeitar e-mails encaminhados

SPF pode falhar no encaminhamento porque o IP do seu servidor não está autorizado no registro SPF do domínio do remetente original. SRS reescreve o remetente do envelope para que o Gmail verifique SPF no seu domínio, que precisa autorizar esse servidor. Sem autenticação válida e alinhada ao domínio do remetente visível, políticas DMARC rigorosas podem levar à rejeição.

Este é um possível fluxo de falha quando uma mensagem de client@bank.com é encaminhada para you@gmail.com:

1. bank.com entrega a mensagem ao seu servidor de encaminhamento
2. Seu servidor retransmite a mensagem ao Gmail
3. O Gmail verifica SPF para o remetente do envelope: client@bank.com
4. O registro SPF de bank.com não autoriza o IP do seu servidor → SPF FAIL
5. A política DMARC é p=reject; sem DKIM válido e alinhado, o Gmail pode retornar 550-5.7.26
6. A mensagem não é entregue. Você pode não receber aviso; uma notificação para bank.com depende do servidor de encaminhamento.

DKIM pode sobreviver ao encaminhamento se as partes assinadas permanecerem intactas. Rodapés de antivírus ou alterações em um assunto assinado podem invalidar a assinatura. Com DKIM válido e alinhado, o Gmail pode aprovar DMARC mesmo se SPF falhar. A opção aspf=s define alinhamento SPF estrito e não altera o alinhamento DKIM. SRS pode ajudar SPF, mas sozinho não é uma solução garantida para DMARC ou problemas de entrega.

Três maneiras de encaminhar e-mails do domínio ao Gmail

As configurações de encaminhamento não têm todas o mesmo risco. Antes de configurar, escolha uma arquitetura adequada ao seu caso de uso.

O catch-all pode prejudicar especialmente a entregabilidade. Spammers testam endereços aleatórios, como abc123@yourdomain.com e junk@yourdomain.com. Seu servidor recebe essas mensagens e as encaminha ao Gmail. Se, no cenário ilustrativo, 90% do tráfego encaminhado for spam, o Gmail poderá reduzir a reputação do IP de envio ou bloqueá-lo. Mensagens legítimas também podem começar a cair no spam, e a recuperação pode levar semanas. Esse percentual não é uma estatística geral nem um limite garantido de bloqueio.

Para entender quando aliases fazem sentido e quando caixas completas são preferíveis, veja o artigo sobre riscos e escolhas no encaminhamento por alias. Se estiver decidindo entre alias e caixa dedicada para um novo endereço, o guia de alias e caixa de e-mail no domínio apresenta os critérios.

SRS: por que é importante no encaminhamento ao Gmail

SRS (Sender Rewriting Scheme) pode reduzir falhas SPF na camada do envelope. Ele reescreve o remetente do envelope, refletido no Return-Path e usado para notificações de falha, do domínio original para o seu domínio. O Gmail passa a verificar SPF no seu domínio. Se o IP do servidor estiver corretamente autorizado, SPF poderá passar. Isso não implica entrega automática nem aprovação DMARC.

Sem SRS (cenário de falha):
Envelope From: client@bank.com
IP de envio: 203.0.113.10 (seu servidor de encaminhamento)
Verificação SPF: registro SPF de bank.com → FAIL (203.0.113.10 não autorizado)
DMARC: FAIL (p=reject), se também não houver DKIM alinhado → possível rejeição

Com SRS (SPF aprovado no exemplo):
Envelope From: SRS0=HASH=TT=bank.com=client@yourdomain.com
IP de envio: 203.0.113.10 (seu servidor de encaminhamento)
Verificação SPF: registro SPF de yourdomain.com → PASS (203.0.113.10 autorizado)
Header From: client@bank.com (inalterado, você vê o remetente original)

Seu registro SPF precisa autorizar o caminho real de envio, por exemplo o IP do servidor de encaminhamento ou os mecanismos apropriados do serviço de envio. Sem isso, SPF ainda pode falhar após SRS: o endereço reescrito usa seu domínio, mas a política desse domínio não autoriza o servidor.

Uma infraestrutura bem configurada também pode acrescentar cabeçalhos ARC (Authenticated Received Chain). A cadeia de assinaturas criptográficas documenta os resultados de autenticação realmente observados em cada etapa. O Google pode considerá-la quando confia no encaminhador. ARC exige uma configuração de assinatura própria e correta; uma assinatura DKIM comum não substitui ARC. Em serviços hospedados, a implementação cabe ao provedor.

A especificação SPF está na RFC 7208. ARC, que documenta a autenticação ao longo de vários saltos, é definido na RFC 8617.

Prevenção de loops: quatro verificações antes de começar

Loops de encaminhamento podem gerar erros como 5.4.14 Hop count exceeded e impedir a entrega de mensagens legítimas. Antes de usar o encaminhamento em produção, confira estes quatro pontos.

1. Sem rotas circulares. Verifique se you@gmail.com não tem um filtro que encaminha de volta para you@yourdomain.com. Se esse endereço voltar a encaminhar ao Gmail, haverá um ciclo.
2. Controle das respostas automáticas. Em endereços de função (team@domain.com → várias contas Gmail), desative respostas automáticas desnecessárias ou configure mecanismos adequados de prevenção. Cabeçalhos como Precedence: bulk podem ser considerados, mas não oferecem proteção completa sozinhos.
3. Teste de uma terceira conta. O Gmail pode suprimir mensagens duplicadas. Um teste enviado da conta de destino para seu próprio alias pode aparecer apenas em Enviados. Teste também de uma conta independente do Yahoo ou Outlook.
4. Política de saída do M365. No Microsoft 365, a política antispam de saída precisa permitir o encaminhamento externo automático. Um administrador autorizado pode ajustar a configuração após avaliar os riscos. Caso contrário, pode ocorrer 550 5.7.520.

Essas são causas comuns de problemas na primeira configuração de encaminhamento ao Gmail. As mensagens de erro, sozinhas, nem sempre identificam a causa com precisão.

Como encaminhar e-mails do domínio ao Gmail com o TrekMail

A fonte descreve reescrita SRS e assinatura ARC no MTA para os encaminhamentos suportados pelo TrekMail. Você informa o destino, e o processamento no servidor ocorre automaticamente segundo essa descrição. Verifique os recursos atuais. Mesmo assim, a decisão de aceitar a mensagem continua sendo do Gmail.

Segundo a fonte, o encaminhamento de caixas está disponível nos planos Pro e Agency, não em Free ou Starter. Confira as condições atuais antes de mudar de plano. As etapas estão na documentação de encaminhamento de caixas do TrekMail:

1. Abra Caixas de e-mail no painel
2. Clique em Gerenciar na caixa desejada
3. Ative Habilitar encaminhamento
4. Informe seu Gmail no campo Encaminhar para
5. Ative Manter uma cópia e deixe a opção ligada durante a configuração inicial
6. Clique em Salvar configurações de encaminhamento

A opção “Manter uma cópia” é importante. No modo descrito, uma cópia permanece na caixa, desde que a cota e a entrega local permitam, enquanto o servidor também tenta encaminhar ao Gmail. Sem a opção, essa cópia local não é mantida; diante de uma rejeição, o tratamento depende da fila e da gestão de erros do servidor. Deixe a opção ligada até verificar o recebimento e os cabeçalhos. Ela não substitui uma estratégia de backup ou retenção.

A fonte descreve uma ação em massa para agências: selecionar várias caixas e aplicar o mesmo destino pelo menu de ações. Isso pode facilitar a configuração em cem domínios, quando os recursos atuais e seus limites permitirem. Confira a seleção antes de aplicar.

Complete o envio: “Enviar e-mail como” no Gmail

O encaminhamento cuida do recebimento. Sem configurar corretamente “Enviar e-mail como”, as respostas podem sair do seu @gmail.com pessoal em vez do domínio. O cliente vê Gmail, não ceo@yourdomain.com.

Use “Enviar e-mail como” com credenciais SMTP externas autorizadas, quando essa configuração for suportada. A opção “Tratar como alias”, sozinha, não determina com segurança o caminho de envio. Confira o servidor realmente usado, o remetente visível e o alinhamento DMARC, em vez de confiar apenas nessa caixa de seleção.

No Gmail: Configurações → Contas e importação → Enviar e-mail como → Adicionar outro endereço de e-mail. Revise “Tratar como alias” conforme sua configuração; desmarcar a opção não garante um resultado específico de autenticação.

Configurações SMTP do TrekMail na fonte (Starter, Pro, Agency):

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Nano na fonte: SMTP próprio (SES, SendGrid, Mailgun etc.):

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

Os blocos SMTP são exemplos; confirme os dados de conexão atuais com cada provedor. Durante a configuração, o Gmail pode enviar um código de verificação para sua caixa. Informe-o seguindo o procedimento atual e, se desejar, defina o endereço do domínio como remetente padrão. Depois, teste também as respostas às mensagens encaminhadas, pois o remetente depende das configurações da conta.

Confira o resultado: leia os cabeçalhos de autenticação do Gmail

Depois que uma mensagem de teste de uma conta externa chegar ao Gmail, examine os cabeçalhos completos antes de confiar na configuração em produção.

No Gmail: abra a mensagem → menu de três pontos → Mostrar original. Procure Authentication-Results.

Um exemplo com verificações aprovadas pode ter este formato; ele não comprova, sozinho, alinhamento DMARC:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

Se aparecer spf=softfail ou spf=fail, revise a reescrita SRS e a autorização do IP real de envio no registro SPF. Outros erros de configuração também são possíveis. arc=fail pode indicar alteração de conteúdo assinado, assinaturas inválidas ou problemas na cadeia ARC, entre outras causas. A orientação oficial do Google sobre encaminhamento ao Gmail aborda o uso apropriado do remetente do envelope. SRS é um mecanismo para reescrevê-lo.

Servidor próprio ou serviço gerenciado: a escolha real

Em um Postfix administrado por você, uma opção é instalar postsrsd, proteger o arquivo srs_secret e planejar sua rotação, configurar OpenARC com chaves adequadas e acompanhar a reputação pelo Google Postmaster Tools, quando houver dados disponíveis. Problemas de dependências, rotação incorreta de segredos ou novas políticas dos remetentes ainda podem causar falhas. Você pode acabar analisando cabeçalhos de autenticação às 11 da noite.

O processamento no MTA descrito na fonte reduz o trabalho com SRS e ARC após a configuração do destino. Ainda assim, confira o suporte atual, a autenticação do domínio e os resultados dos testes. O acompanhamento contínuo permanece importante.

Como começar

Para configurar inicialmente um único domínio, a fonte indica Nano sem cartão de crédito. Pela divisão de recursos descrita, porém, esse plano não oferece o encaminhamento de caixas em si. Para o encaminhamento suportado com SRS no servidor, ela indica Pro a partir de $10/mês, com preço fixo e sem cobrança por usuário dentro dos limites do plano. Confira as condições atuais e conclua a verificação do domínio antes de testar.

A fonte informa um teste gratuito de 14 dias nos planos pagos, com cartão de crédito obrigatório. Você também pode consultar trekmail.net/pricing para ver as condições atuais do Nano e dos planos pagos.

Quatro pontos são importantes para encaminhar ao Gmail: SRS reescreve o envelope, ARC documenta a autenticação, SPF autoriza o IP real de envio e “Enviar e-mail como” configura as respostas. Nenhum deles, isoladamente ou em conjunto, garante a entrega. Confira também DKIM alinhado, as políticas de recebimento e o tratamento dos erros para identificar mensagens ausentes o quanto antes.

Configure, verifique os cabeçalhos e continue acompanhando os resultados em produção.