Encaminhar e-mails parece simples: configurar um redirecionamento e pronto. Mas, sem encaminhamento com SRS (Sender Rewriting Scheme), o SPF pode falhar. Imagine que bank.com envie uma mensagem para um endereço encaminhado no seu servidor, que a repassa ao destino. A conexão chega do seu IP, enquanto o remetente do envelope continua usando bank.com. Se esse domínio não autorizar seu IP, o SPF falha. Com DMARC p=reject, a mensagem pode ser rejeitada quando também não há uma assinatura DKIM válida e alinhada. Pode haver rejeição SMTP ou aviso de falha na entrega; nem toda mensagem desaparece silenciosamente.
Este guia aborda a configuração operacional do SRS. O guia completo de configuração do encaminhamento de e-mail e suas falhas apresenta o panorama geral. Aqui, o foco é a camada SRS: arquitetura, sintaxe de reescrita, integração com Postfix e ARC como possível complemento à decisão de autenticação do destinatário.
O que o encaminhamento com SRS realmente faz
O SRS reescreve o endereço do remetente do envelope quando seu servidor encaminha uma mensagem, substituindo o domínio original por um domínio que você controla. O SPF pode passar no destino quando esse domínio autoriza corretamente a rota real de envio do intermediário. O From do cabeçalho, visto pelo destinatário no cliente de e-mail, permanece inalterado.
Sem reescrita, mensagens encaminhadas podem falhar no SPF se o domínio original não autorizar o novo servidor. O SRS pode ajudar nessa verificação, mas não preserva automaticamente toda a cadeia de autenticação nem o alinhamento DMARC com o remetente original. Verifique os requisitos da sua rota real.
As duas camadas de identidade do e-mail
Para configurar o SRS corretamente, é preciso distinguir dois campos de endereço separados. O SPF verifica a camada do envelope; quando o servidor de envio muda, a autorização pode deixar de corresponder à conexão.
- Remetente do envelope (RFC 5321 MAIL FROM): Endereço de retorno usado pelos servidores de e-mail para direcionar mensagens de falha na entrega. O SPF verifica se o IP da conexão pode enviar pelo domínio. Esse endereço também pode ser consultado no Return-Path dos cabeçalhos brutos.
- From do cabeçalho (RFC 5322 From): Endereço exibido nos clientes de e-mail. O DMARC verifica o alinhamento com pelo menos um domínio autenticado com sucesso por SPF ou DKIM. O SRS mantém esse campo inalterado.
O exemplo abaixo mostra resultados SPF de um encaminhamento com e sem SRS, sob as autorizações de domínio indicadas:
| Etapa | IP da conexão | Remetente do envelope | Resultado SPF |
|---|---|---|---|
| 1: Alice → seu servidor | Servidor de Alice | alice@client.com | PASS |
| 2: Seu servidor → Gmail (sem SRS) | Seu servidor | alice@client.com (inalterado) | FAIL |
| 2: Seu servidor → Gmail (com SRS) | Seu servidor | SRS0=Hash=Time=client.com=alice@yourdomain.com | PASS |
A reescrita SRS coloca um domínio sob seu controle no remetente do envelope. O registro SPF desse domínio precisa autorizar sua rota de envio. Isso pode viabilizar a verificação, mas não garante a entrega. O endereço reescrito normalmente não aparece como remetente visível, embora possa ser lido nos cabeçalhos brutos.
Sintaxe do SRS: o significado de cada componente
Um endereço reescrito por SRS parece enigmático, mas cada componente tem uma função. Saber interpretá-lo ajuda a investigar falhas nos logs de retorno e nas cadeias de entrega com várias etapas.
A reescrita SRS da primeira etapa (SRS0) tem este formato:
SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomainOs componentes:
- Hash: Código de autenticação HMAC truncado, gerado com uma chave secreta local; algumas implementações usam SHA1. Ele dificulta a falsificação de endereços SRS de retorno no seu domínio. Sem validação adequada, endereços SRS0 aparentemente válidos podem ser usados para enviar avisos indesejados de falha na entrega. A proteção depende do método e da gestão das chaves.
- Timestamp: Neste exemplo, codificado em Base32, com uma janela de validade configurável de cerca de 7-21 dias. Endereços expirados podem ser rejeitados. Isso limita certos riscos de repetição, mas não os elimina.
- Origin: Dados para reconstruir o remetente original quando há falha na entrega. Seu servidor recebe o aviso, recupera o endereço original e redireciona a notificação ao remetente correto.
- AnchorDomain: Domínio sob seu controle. Seu registro SPF deve autorizar o intermediário, e uma rota de retorno acessível precisa receber mensagens de falha na entrega. Normalmente se configura MX para isso; em determinadas condições, uma rota implícita por A ou AAAA também é possível.
Em outro encaminhamento, SRS0 pode passar a SRS1:
SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomainO SRS1 limita o crescimento da parte local do endereço. O limite de 64 caracteres da RFC 5321 continua relevante; o mecanismo não garante seu cumprimento em toda cadeia. Em falhas de encaminhamento com várias etapas, verifique o tamanho do endereço, mas também o roteamento e a autenticação.
Integração com Postfix: configuração do PostSRSd
O PostSRSd é uma opção comum para integrar SRS em sistemas Linux/Postfix. Um serviço em segundo plano fornece endereços de envelope reescritos ao Postfix por interfaces de mapeamento adequadas. Os exemplos a seguir precisam corresponder à versão realmente instalada. Verifique a sintaxe, o caminho do socket, as permissões de acesso e a integração com sua configuração existente do Postfix antes de aplicar mudanças.
Etapa 1: requisitos do domínio âncora
Prepare o domínio âncora antes de alterar arquivos de configuração. Ele aparece nos remetentes de envelope reescritos pelo servidor. Os pontos importantes são:
- Registros MX: Mensagens de falha na entrega são direcionadas a esse domínio. Confirme que a rota de retorno realmente recebe mensagens. A falta de recebimento pode fazer os avisos se perderem. A RFC 5321 também descreve a entrega por MX implícito usando A ou AAAA em certas condições; a ausência de MX explícito, por si só, não comprova que o domínio seja inacessível.
- Registro SPF: Os servidores de destino verificam o SPF desse domínio contra seu IP de envio. Se a rota real não estiver autorizada, o SPF pode falhar mesmo com a reescrita SRS ativa.
- Boa reputação: O spam encaminhado pode prejudicar a reputação do IP e do domínio âncora e contribuir para listagens de bloqueio. Isso não é inevitável, mas o SRS não isola você do conteúdo encaminhado.
# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"
# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +shortEtapa 2: configurar o PostSRSd
Conforme o pacote e a versão, a configuração pode estar em /etc/default/postsrsd (Debian/Ubuntu) ou /etc/postsrsd/postsrsd.conf. Confirme o arquivo utilizado e a sintaxe suportada, incluindo as exclusões de domínio que variam entre versões:
# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com
# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret
# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.comSe ainda não houver uma chave, você pode gerar uma chave secreta forte. Atenção: o redirecionamento no exemplo abaixo sobrescreve um arquivo existente. Não o execute sem verificar o sistema atual. Faça uma cópia protegida das chaves existentes, planeje a rotação e a sincronização no cluster e confira proprietário e permissões. Endereços de retorno já emitidos podem depender das chaves antigas:
openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secretEtapa 3: integrar ao Postfix
A integração é definida em /etc/postfix/main.cf. O exemplo abaixo mostra socketmaps para PostSRSd 2.x e TCP para a versão 1.x. Não copie sem adaptação: verifique o caminho real do socket, as permissões, a acessibilidade e a sintaxe da versão instalada:
# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient
# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipientApós validar a configuração, você pode reiniciar os dois serviços na janela de manutenção apropriada:
systemctl restart postsrsd
systemctl restart postfixO SRS nem sempre basta: ARC como complemento
O SRS pode tratar o problema SPF do novo domínio do envelope, mas não estabelece automaticamente o alinhamento DMARC. O DMARC exige que o domínio autenticado com sucesso por SPF ou o domínio de uma assinatura DKIM válida esteja alinhado com o From do cabeçalho. Após a reescrita SRS, o SPF autentica relay.yourdomain.com no exemplo, não client.com. Sem esse alinhamento, uma assinatura DKIM válida e alinhada continua sendo a via para o DMARC passar.
O encaminhamento pode invalidar o DKIM. Um prefixo “External Sender” no assunto, links de descadastramento no rodapé ou mudanças nos delimitadores MIME podem invalidar a assinatura original quando afetam partes assinadas e a canonicalização utilizada não elimina as diferenças. Se depois disso faltam tanto alinhamento SPF quanto DKIM válido e alinhado, o DMARC falha e um destinatário rigoroso pode rejeitar a mensagem.
Um complemento possível é o ARC, Authenticated Received Chain, definido na RFC 8617. O intermediário pode registrar com assinaturas os resultados de autenticação realmente observados na chegada. Destinatários que confiam no signatário ARC e na cadeia podem considerar essas informações ao decidir como tratar uma falha DMARC atual. O ARC não corrige alinhamento de domínio nem garante a entrega.
O ARC adiciona três cabeçalhos à mensagem encaminhada:
ARC-Authentication-Results: resultados de autenticação realmente observados na chegada, e não necessariamente verificações bem-sucedidasARC-Message-Signature: assina cabeçalhos selecionados e o corpo no estado presente no momento da assinatura ARCARC-Seal: vincula criptograficamente o conjunto ARC à cadeia ao longo das etapas
O SRS trata o envelope; o ARC documenta o contexto de autenticação. Em ambientes com DMARC rigoroso, como Google ou Microsoft, ambos podem ser úteis. Não são obrigatórios em toda situação nem, juntos, suficientes para garantir entrega. Sem alinhamento SPF e DKIM válido e alinhado, o SRS sozinho não faz o DMARC passar.
A referência normativa do SPF, cujo problema de encaminhamento o SRS aborda, é a RFC 7208.
Falhas específicas dos provedores a conhecer antes da implantação
Mesmo com SRS e ARC configurados corretamente, políticas dos provedores podem restringir o encaminhamento. Isso não precisa ser um erro da sua configuração. Verifique a rota afetada e a política aplicável antes de encontrar essas restrições em produção.
| Provedor | Erro ou comportamento | Causa possível | Medida |
|---|---|---|---|
| Microsoft 365 | 550 5.7.520 Access denied | A política de segurança do tenant M365 de origem pode bloquear encaminhamento externo automático para prevenir vazamento de dados | Um administrador autorizado verifica a política de filtro de spam de saída no Defender; liberação somente conforme a política da organização |
| Microsoft 365 | 554 5.4.14 Hop count exceeded | Possível loop de roteamento, por exemplo com encaminhamento catch-all e uma rota de retorno ao endereço inicial | Revisar catch-all e caminhos de retorno e interromper o loop na origem do problema |
| Gmail / Workspace | Mensagens ausentes sem aviso visível de falha na entrega | A detecção de loops pode afetar o processamento; nem toda situação gera um aviso visível | Consultar o status da entrega no Google Admin Console quando houver acesso ao Workspace e permissões; corrigir o loop no roteamento anterior |
| Gmail / Workspace | Verificação de remetentes em massa | >5,000 mensagens encaminhadas por dia é um exemplo de volume aqui; as regras de remetentes em massa não se aplicam universalmente a todo tráfego encaminhado | Revisar requisitos atuais do provedor e se a arquitetura de encaminhamento é adequada ao volume |
O erro M365 550 5.7.520 pode consumir muito tempo quando tratado como um problema SRS. Neste cenário, uma política de segurança no tenant de origem bloqueia o encaminhamento externo antes de a mensagem sair dele. SRS ou ARC em um servidor posterior não resolvem isso. Mudanças no portal Microsoft Defender exigem permissões administrativas adequadas e autorização da organização.
Como verificar se o encaminhamento com SRS funciona
Verifique o SRS antes de confiar nele em produção. Envie uma mensagem de teste pela cadeia e examine os cabeçalhos brutos no destino. Um endereço SRS no Return-Path mostra uma reescrita visível nessa mensagem, não comprova toda a configuração. Se o endereço original permanecer, investigue, entre outras causas, exclusões de domínio, outra rota de envio ou a ausência de consulta ao PostSRSd.
1. Verifique o cabeçalho Return-Path
Envie uma mensagem de teste de uma conta externa, como ProtonMail, para o endereço encaminhado. Abra o código-fonte da mensagem no destino e localize a linha Return-Path:
Return-Path: <SRS0=...@yourdomain.com>→ a reescrita SRS está visível nessa mensagem; confira também os resultados de autenticaçãoReturn-Path: <alice@protonmail.com>→ não há reescrita visível; verifique exclusões, rota de envio e integração do serviço
2. Verifique o DNS do domínio âncora
# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short
# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short3. Consulte os logs do Postfix
grep -E "srs_forward|canonical" /var/log/mail.log | tail -50Confira se o Postfix consulta o serviço SRS e recebe endereços reescritos; os detalhes disponíveis dependem da configuração e do nível de log. “Connection refused” pode indicar serviço parado, endereço incorreto ou problemas de socket e rede. Verifique, entre outros pontos, systemctl status postsrsd, a interface configurada e, quando aplicável, as regras de firewall.
4. Teste a acessibilidade e o TLS
Problemas de SRS e TLS podem aparecer como falhas de entrega semelhantes. Por isso, verifique também a conexão de rede e o STARTTLS:
openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtpUm timeout pode resultar de problemas de rede ou bloqueio de porta e não comprova falha no TLS. Se a negociação falhar, examine também a configuração TLS e as mensagens de erro. Essas causas devem ser investigadas separadamente da reescrita SRS.
Quando parar de encaminhar e começar a hospedar caixas
SRS, ARC, domínio âncora, gestão de chaves, exclusões de domínio e monitoramento de reputação criam trabalho operacional real. Muitas organizações usam encaminhamento para evitar licenças por caixa nos grandes provedores. Você encaminha sales@ para sua caixa pessoal e economiza, no exemplo, uma licença de $6 por mês. O que parece razoável para um endereço pode custar caro em operação para dez.
Se está comparando opções, o guia de vantagens e desvantagens do encaminhamento por alias explica quando encaminhar faz sentido e quando os problemas se acumulam. O guia de decisão entre alias e caixa de e-mail ajuda a escolher a estrutura dos endereços.
| Antes: encaminhar tudo | Alternativa: hospedar na TrekMail | |
|---|---|---|
| Autenticação SPF | PostSRSd e domínio âncora são uma configuração possível para a etapa de encaminhamento | Configuração gerenciada no servidor na oferta descrita; verificar resultados reais |
| Autenticação DMARC | Exige SPF ou DKIM alinhado; ARC pode acrescentar contexto | Processamento automático por OpenARC quando suportado pelo plano e pela configuração; sem garantia de DMARC |
| Falhas na entrega | Domínio âncora precisa de uma rota funcional de retorno | Processamento pela infraestrutura TrekMail conforme a rota suportada |
| Operação contínua | Rotação de chaves, exclusões de domínio e monitoramento de reputação | Menos manutenção própria do servidor; contas, DNS, permissões e uso continuam exigindo gestão |
| Modelo de armazenamento | Depende do provedor de destino, que também pode oferecer armazenamento compartilhado | Armazenamento compartilhado por todas as caixas dentro dos limites do plano |
O plano TrekMail Pro descrito custa $10 ao mês e oferece 100 domínios e 50GB de armazenamento compartilhado. Verifique preços, limites e recursos atuais. Hospede sales@, support@ e info@ como caixas IMAP reais, sem cobrança por usuário conforme o modelo descrito. A etapa adicional de encaminhamento e sua manutenção SRS deixam de ser necessárias. A entrega direta e o armazenamento continuam dependendo da configuração, das cotas e das decisões dos provedores.
Se precisar encaminhar, por exemplo para reunir vários domínios em um destino, o encaminhamento gerenciado descrito nos planos Pro e Agency faz a reescrita SRS e a assinatura OpenARC no servidor. Confirme o suporte atual. Você define o destino no painel; o processamento no servidor não garante alinhamento DMARC nem aceitação. Nano com BYO SMTP não significa automaticamente acesso ao encaminhamento gerenciado. Se encaminhar pela sua própria infraestrutura, o SRS é relevante nela; os exemplos de PostSRSd precisam corresponder à sua versão e arquitetura.
Para a rota específica de um domínio próprio até o Gmail, o guia de encaminhamento de e-mail do domínio para o Gmail detalha falhas específicas e etapas de verificação.
A versão resumida
O encaminhamento com SRS reescreve o remetente do envelope para que o SPF verifique o domínio do intermediário. A verificação pode passar se esse domínio autorizar corretamente o IP de envio. Nem toda mensagem encaminhada falha sem SRS. O PostSRSd é uma integração possível com Postfix, usando domínio âncora acessível, SPF adequado, chave secreta, exclusões de domínio apropriadas e mapeamentos em main.cf. Confira a versão e a sintaxe. O ARC pode acrescentar contexto quando o DKIM é invalidado no trânsito, mas não corrige a falta de alinhamento DMARC.
Após cada alteração, examine os cabeçalhos brutos e os resultados reais de autenticação. Quando o custo operacional do SRS supera a economia com licenças, hospedar diretamente pode fazer mais sentido. Confira os planos TrekMail e as condições atuais da oferta Nano descrita, sem cartão. A ativação depende de DNS e configuração e não é imediata em toda situação. O Pro oferece encaminhamento SRS gerenciado e ARC no escopo descrito, se você preferir delegar esse processamento.
