Pesquisar

Configuração e Troubleshooting de SRS

1. O Problema: Quebra de SPF em Redirecionamentos (Forwarding)

Quando um cliente configura um redirecionamento de e-mail (ex: contato@dominiocliente.com.br -> emailpessoal@gmail.com), o servidor de destino (Gmail, Microsoft) avalia o SPF baseado no remetente original.

Como o e-mail está saindo pelos IPs da Kangaroo, mas o domínio original não autoriza nossos IPs em sua zona de DNS, a verificação falha (geralmente gerando um erro 550 5.7.1 Unauthenticated email is not accepted) no rastreamento de entregas do próprio cPanel do usuário, além do registro no EXIM.

2. A Solução: O que o SRS faz na prática?

O SRS (Sender Rewriting Scheme) resolve esse gargalo no nível do MTA (Exim). Quando o redirecionamento ocorre, o Exim reescreve o Return-Path da mensagem para utilizar o domínio do nosso servidor de hospedagem.

Dessa forma, quando o Gmail recebe a mensagem, ele valida o SPF contra o nosso domínio (que está devidamente configurado), o teste de SPF passa, e a mensagem é entregue, contornando o bloqueio inicial do redirecionamento.

3. Procedimento de Ativação (Interface WHM)

A ativação nativa suportada pela cPanel é feita diretamente no gerenciador do Exim:

  1. Acesse o WHM como root.
  2. Navegue até Service Configuration » Exim Configuration Manager.
  3. Na aba Basic Editor, selecione a sub-aba Mail.
  4. Localize a diretiva: Enable Sender Rewriting Scheme (SRS) Support.
  5. Altere para On, por padrão está marcado como Off
  6. Clique em Save (Isso fará o rebuild do exim.conf e reiniciará o serviço).

4. Troubleshooting e Validação via CLI

Execute um tail no servidor enquanto dispara um e-mail de teste para uma conta com redirecionamento ativo:

grep -i "srs0" /var/log/exim_mainlog

O que procurar no log: Você deve identificar a reescrita no formato padrão do SRS. O log de entrega (=>) vai mostrar o Return-Path alterado. Ele terá um formato semelhante a este:

SRS0=xxxx=yy=dominio-original.com=usuario@dominio-do-servidor.com

Se o log mostrar a entrega (Completed) para o destino externo utilizando esse padrão no remetente, o SRS está operacional e o vazamento de SPF via forwarders está mitigado.

5. Erros de Recebimento: Conflito do SRS com Sender Verification Callouts

Este é o cenário onde o nosso servidor atua como destino final e barra mensagens legítimas. Quando recebemos um e-mail roteado por um filtro externo (como Skymail, Gmail, MailChannels etc..) que já sofreu SRS na origem, o remetente chega no formato <SRS0=...>.

Se a proteção Sender Verification estiver ativa no WHM, o Exim fará um callout para verificar se a conta SRS gigante existe no servidor de origem. Como SRS é um alias dinâmico e não uma caixa postal real, a verificação falha sumariamente.

Exemplo do bloqueio no /var/log/exim_mainlog:

sender verify fail for <SRS0=0e3e=b3=uall.ai=ib_bounces-financeiro=dominio.com.br@dominio.com.br>: No Such User Here
rejected RCPT <financeiro@dominio.com.br>: Sender verify failed

Solução (Bypass de Verificação para Relays): Não desative o Sender Verification globalmente, ou o servidor receberá muito spam. Isente os IPs do relay confiável (ex: como Skymail, Gmail, MailChannels etc..) da checagem.

  1. No WHM, vá em Exim Configuration Manager » aba Access Lists.
  2. Localize Trusted SMTP IP addresses.
  3. Clique em Edit e insira os IPs/blocos do serviço de e-mail (ou do filtro em uso).
  4. Salve as configurações. O Exim fará o bypass da verificação para essas rotas e o tráfego SRS entrará normalmente.

6. Falhas Persistentes em Envios: O Fator DNS Externo

O SRS não substitui a necessidade de o domínio ter suas próprias políticas de autenticação. Se o e-mail redirecionado continua voltando, o domínio pode estar com a zona de DNS externa sem os apontamentos corretos.

  1. Valide a autoridade do DNS: É obrigado que todas as entradas TXT que validam o SPF, DKIM e DMARC estejam presentes se o domínio do cliente esteja disparando e-mails a partir dos servidores da Kangaroo Host.
  2. Se o DNS for externo, os registros de SPF e DKIM gerados localmente no cPanel são inúteis, visto que as entradas de DNS estão sendo administratidas remotamente em serviço de terceiros.
  3. Ação necessária: É necessário que o cliente copie as informações e valores de SPF e DKIM do cPanel e orientar a criação manual na zona DNS do provedor externo. Sem SPF público e válido, provedores rigorosos rejeitarão as mensagens, independentemente do SRS.

Rolar para cima