Seu encaminhamento de e-mail não funciona. Mensagens somem, o remetente não vê uma notificação de falha e as regras parecem corretas nos painéis consultados. Sem erro visível, é preciso acompanhar o trajeto da mensagem e reunir registros.
Encaminhamento de e-mail que não funciona pode ter origem em regra, endereço, política ou autenticação SPF, DKIM e DMARC. O destinatário vê o IP do servidor intermediário, que talvez não esteja autorizado pelo domínio original. Conforme as verificações e a política, pode haver rejeição, classificação como spam ou descarte sem aviso visível. Os resultados reais permitem distinguir essas situações.
Percorra esta lista antes de alterar DNS. O guia completo de configuração e correção de encaminhamento explica as limitações de SPF e o papel de SRS e ARC. Aqui você encontra uma sequência rápida de diagnóstico para um problema que está acontecendo agora.
Por que o encaminhamento pode falhar sem erro visível
O resultado depende do servidor e do momento da falha. Uma rejeição SMTP pode gerar aviso; após a aceitação, pode haver notificação posterior, quarentena ou descarte conforme a política. O aviso segue o remetente de envelope, que nem sempre é o remetente exibido. Consulte logs e filas: não receber aviso não demonstra, por si só, falha DMARC.
Cabeçalhos e logs ajudam quando não há erro aparente. Uma regra ativa não impede filtragem no destino nem uma mensagem pendente na fila. As seis verificações abaixo seguem uma ordem prática de diagnóstico. Conferir spam primeiro pode evitar, por exemplo, 45 minutos alterando DNS sem relação com a falha.
Triagem em 60 segundos: identifique o sintoma
Reserve 60 segundos, como orientação, para classificar o sintoma antes de mudar configurações. Ele indica onde começar, mas não confirma sozinho a causa. Estes quatro padrões ajudam a escolher a primeira verificação.
| Sintoma | O que aparece | Causa possível | Primeira verificação |
|---|---|---|---|
| Aviso de não entrega (NDR) | O remetente recebe erro 5xx | Bloqueio por política ou endereço inválido | Leia o código SMTP e o detalhe do aviso |
| Ausência sem aviso | Não chega mensagem nem notificação | Filtragem, descarte ou problema de autenticação | Confira primeiro spam ou lixo eletrônico do destino |
| Loop | “Hop count exceeded” ou cópias repetidas | Encaminhamentos circulares | Procure rotas A → B → A |
| Atraso | A mensagem chega horas depois | Greylisting, fila ou limitação do servidor | Procure status=deferred nos logs |
Lista de verificação do encaminhamento
Comece pela etapa 1 e pela etapa 2: spam e avisos de não entrega oferecem pistas sem alterar DNS. Isso pode evitar, por exemplo, 45 minutos de mudanças desnecessárias. Siga a sequência e pare quando as evidências identificarem a causa.
Etapa 1: confira o spam do destino
Verificação inicial | Sintoma: sem mensagem e sem aviso
Sem aviso, a mensagem pode estar em spam, mas também em quarentena ou na fila. Ao encaminhar de client@gmail.com para you@outlook.com, o destinatário pode ver o IP do intermediário em vez de um IP autorizado pelo SPF original. SPF pode falhar; uma assinatura DKIM preservada, válida e alinhada ainda pode permitir DMARC. A classificação depende das verificações e da política do destinatário.
Ação: entre na caixa final e examine spam e lixo eletrônico.
Correção: marque a mensagem legítima como “Não é lixo eletrônico”. No servidor, Sender Rewriting Scheme (SRS) pode reescrever o remetente de envelope para que SPF avalie o domínio do intermediário. Esse domínio não fica automaticamente alinhado ao From original. Sem SRS, DKIM alinhado também pode permitir DMARC; a configuração não elimina todos os filtros futuros.
Etapa 2: leia o aviso de não entrega e seu código NDR
Leitura do erro | Sintoma: notificação de “Não foi possível entregar”
O código SMTP e o texto ajudam a direcionar a investigação. Confira também qual servidor emitiu o erro e o endereço afetado. O assunto ou um código fora de contexto nem sempre identifica uma causa única.
| Código | Interpretação possível | Verificação ou correção |
|---|---|---|
550 5.7.520 | Acesso negado por política de encaminhamento externo do M365 | Revise a política no M365 Defender e peça autorização restrita à necessidade (etapa 4) |
550 5.7.26 | Rejeição do Gmail relacionada à autenticação, conforme o detalhe | Confira SPF, DKIM, DMARC e o intermediário; SRS sozinho não basta |
5.4.14 / 5.4.6 | Possível loop de roteamento | Interrompa o ciclo entre regras (etapa 5) |
550 5.1.1 | Destinatário desconhecido ou indisponível | Confira o endereço de destino e possíveis erros de digitação |
Etapa 3: confira o alinhamento DMARC
Verificação de autenticação para Gmail, Yahoo e Outlook | Sintoma: ausência ou rejeição
DMARC pode ser a causa. Publicar p=reject não significa que o encaminhamento falhe em 100% dos casos sem SRS ou ARC: DKIM pode continuar válido e alinhado. DMARC passa quando SPF ou DKIM valida com domínio alinhado ao From visível. O destinatário aplica sua política; SRS não alinha automaticamente o envelope reescrito ao From original.
Consulte a política DMARC do domínio original em um terminal:
dig _dmarc.originalsender.com TXT +short
Encontrar p=reject não prova a rejeição dessa mensagem. Examine os resultados: SPF pode falhar pelo IP do intermediário, enquanto DKIM pode sobreviver ou falhar se o conteúdo assinado for alterado. Alinhamento compara domínios autenticados ao From, não o remetente de envelope à assinatura DKIM.
Correção: avalie encaminhamento no servidor com SRS e suporte a ARC quando adequado. ARC permite verificar uma cadeia de resultados anteriores; o destinatário decide se confia no intermediário e como usa esses dados, sem garantia de passar DMARC ou entregar. Filtros Gmail, regras Outlook e redirecionamentos cPanel têm implementações diferentes; cPanel pode encaminhar no servidor. Confira os recursos reais do serviço.
Etapa 4: revise o encaminhamento de saída do Microsoft 365
Revisão de políticas para Office 365 | Sintoma: NDR 550 5.7.520
Uma política do Microsoft 365 pode bloquear deliberadamente encaminhamentos externos para reduzir saída não autorizada de dados. Uma regra de usuário não supera as restrições da organização. Confirme destino, necessidade e aprovação antes de habilitar. A navegação abaixo é orientativa e pode mudar; não amplie a política padrão para todo o tenant sem justificativa.
- Acesse com autorização o Microsoft 365 Defender
- Procure Email e colaboração → Políticas e regras → Políticas de ameaças → Antispam
- Revise a política antispam de saída e seu escopo; prefira uma exceção específica aprovada a ampliar Default indiscriminadamente
- Consulte Editar configurações de proteção
- Apenas no escopo autorizado, avalie Regras de encaminhamento automático e Ativado: o encaminhamento está habilitado
Uma opção indisponível pode depender das suas permissões ou da política organizacional. Peça a intervenção do administrador autorizado, sem tentar contornar a restrição com uma regra pessoal. Verifique depois o efeito e registre a aprovação.
Etapa 5: procure loops de roteamento
Verificação das rotas | Sintoma: erro 5.4.14 ou várias cópias
Um loop pode surgir quando A encaminha para B e B devolve para A. A mensagem pode circular até um limite de saltos ou outro controle. Confira, por exemplo, um catch-all do domínio A que envia a B e uma regra de B que devolve certos endereços a A.
Procure estes cabeçalhos em mensagens atrasadas ou duplicadas:
X-LoopX-MS-Exchange-Inbox-Rules-LoopDelivered-Torepetido com o mesmo endereço
O guia de roteamento catch-all de domínio ajuda a desenhar rotas sem ciclos. Um destino final claro facilita a revisão. Outro alias ou intermediário não causa necessariamente loop, mas exige verificar toda a cadeia e seus limites.
Etapa 6: confirme o destino no Gmail
Verificação de ativação | Sintoma: regra existe, mas está inativa
No Gmail pessoal, pode faltar confirmar o endereço de destino. Confira o estado da verificação e depois se o encaminhamento está selecionado nas configurações. Salvar um endereço não basta para ativá-lo.
Ação: procure a confirmação de “Gmail Team” na caixa de destino, inclusive no spam. Confirme que o pedido é legítimo e autorizado antes de abrir o link. Se a mensagem não chegou ou expirou, consulte Configurações do Gmail → Encaminhamento e POP/IMAP e repita a verificação conforme o fluxo atual.
Leia cabeçalhos para diagnosticar o encaminhamento
Uma mensagem em spam chegou à caixa. Autenticação, reputação, conteúdo e outros sinais podem explicar sua classificação. Authentication-Results fornece resultados de verificação, não a explicação de toda falha. Confira qual servidor adicionou o cabeçalho e compare com logs; um cabeçalho vindo de origem não confiável não é prova.
Como consultar cabeçalhos, conforme a versão do cliente:
- Gmail: abra a mensagem → menu de três pontos → “Mostrar original”
- Outlook: Arquivo → Propriedades → Cabeçalhos de Internet nas versões compatíveis
Exemplo ilustrativo de resultados com SRS e ARC, não um modelo canônico de cabeçalho nem uma prova de entrega. Verifique autenticação, alinhamento e cadeia ARC reais:
Authentication-Results: mx.google.com;
dkim=pass header.i=@sender.com;
spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
designates 1.2.3.4 as permitted sender)
dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
arc=pass (i=1 spf=pass dkim=pass)
| Resultado | Interpretação | Próxima verificação |
|---|---|---|
spf=fail | SPF não autoriza o IP para o remetente de envelope avaliado; confira domínio e salto | Examine o intermediário e SRS quando adequado |
spf=pass + SRS0= em Return-Path | Indícios de reescrita e SPF válido para esse domínio, não de alinhamento automático ao From original | Confira DKIM e DMARC |
dmarc=fail | Nenhuma verificação SPF ou DKIM alinhada ao From passou | Investigue resultados e alterações; avalie ARC e a política do destinatário |
arc=pass | A cadeia ARC valida; o destinatário ainda decide se confia no intermediário | Confira sua política e os filtros do destino |
dkim=pass | Uma assinatura valida as partes assinadas, não a ausência de toda alteração na mensagem | Confira domínio e alinhamento; DKIM alinhado pode bastar para DMARC |
O prefixo SRS0= em Return-Path indica uma forma comum de reescrita. Sua ausência não prova que todos os encaminhamentos falhem; examine o envelope e a implementação. Gmail, Yahoo e Outlook aplicam regras distintas. Os requisitos do Google para remetentes em massa de 2024 não representam todos os domínios empresariais nem todos os destinatários.
Quando uma falha de encaminhamento afeta o negócio
Um e-mail de cliente, contrato ou pedido de suporte não recebido pode atrasar uma relação comercial. Às vezes o problema só aparece quando alguém cobra a resposta. Alertas, logs e testes ajudam a detectar essas lacunas.
O diagnóstico manual é útil, mas vários domínios precisam de acompanhamento contínuo. Mudanças de autenticação ou política podem alterar o resultado. O Google Postmaster Tools mostra dados agregados de reputação, denúncias de spam e outros indicadores do tráfego elegível para Gmail pessoal, sujeitos a volume e atrasos. Falhar na autenticação não gera automaticamente uma denúncia nem afeta necessariamente todo envio.
Reduza os problemas recorrentes
Se encaminhamentos falham repetidamente, avalie infraestrutura, preservação de DKIM e suporte a SRS e ARC, além das regras. Um desenho adequado pode reduzir diagnósticos repetidos, mas ainda precisa de monitoramento e revisão das políticas.
Gestão dispersa: conferir regras Gmail ou cPanel, investigar SPF por domínio e pedir mudanças aprovadas de políticas M365 quando requisitos mudam.
Modelo TrekMail: definir rotas no painel e verificar o tratamento SRS e ARC no servidor conforme os recursos disponíveis. Entrega continua dependendo do destinatário e da configuração.
O TrekMail descreve encaminhamento no nível do Postfix, com reescrita SRS e selagem ARC antes do próximo envio. Confirme o funcionamento atual e a preservação de assinaturas DKIM originais nas alterações. ARC registra resultados anteriores; não mantém sozinho uma assinatura válida após mudar conteúdo assinado nem garante aceitação por Gmail, Outlook ou Yahoo.
Para uma agência com dezenas de domínios, centralizar pode simplificar o trabalho. Em vez de entrar, por exemplo, em 30 painéis, configure e verifique cada rota com as permissões adequadas. O guia de gestão de e-mail dos clientes explica cadeias multidomínio sem loops A→B→A como os da etapa 5.
A descrição histórica situa o encaminhamento ARC e SRS em Pro por $10/mês (100 domínios, 50GB) e Agency por $23.25/mês (1,000+ domínios), com teste de 14 dias. Confira recursos, cotas, cobertura do teste e exigência de cartão antes de contratar: compare os planos em trekmail.net/pricing.
Reduza chamados recorrentes com configuração verificada e acompanhamento. Conheça o tratamento SRS e ARC do TrekMail e confira os recursos atuais.