Depois do novo padrão DMARC de 2026, o que fazer quando e-mails encaminhados por alias vão para o spam?

Um e-mail encaminhado por alias aparece no spam, embora a mensagem original pareça legítima.

O RFC 9989 atualiza o padrão DMARC, mas isso não significa que você precise reconfigurar aliases ou encaminhamentos: confira primeiro os resultados de autenticação e identifique se a falha está na mensagem original, no caminho de encaminhamento ou na classificação da caixa de destino (RFC 9989).

Este guia é para quem recebe assinaturas e avisos por alias e precisa descobrir por que uma mensagem foi classificada como spam.
Também ajuda profissionais autônomos a separar falhas do remetente de problemas no encaminhamento de mensagens de clientes e projetos.
Administradores de domínios próprios podem usar os resultados como evidência antes de alterar DNS ou regras de recebimento.

Última revisão: 2 de novembro de 2026. As informações sobre os padrões foram conferidas nos RFC 9989 e RFC 7960, e as orientações sobre encaminhamento foram comparadas com a documentação oficial para encaminhar mensagens.

A mudança do DMARC exige alterar aliases ou encaminhamentos?

Não por si só. O RFC 9989 foi publicado em maio de 2026 e substitui o RFC 7489, conforme o registro do novo padrão DMARC. Isso descreve uma atualização do padrão; não é uma instrução automática para cada pessoa mudar seus endereços, registros DNS ou regras de encaminhamento.

O problema pode ocorrer porque o servidor que recebe a mensagem encaminhada vê uma rota diferente da que o servidor original avaliou. O SPF verifica se o servidor que está entregando a mensagem está autorizado pelo domínio do remetente. Quando uma mensagem passa por um intermediário, esse servidor pode não ser o mesmo previsto pela política SPF original. A falha de SPF após o encaminhamento, portanto, não prova sozinha que a mensagem original era falsa.

O DMARC avalia o alinhamento entre o domínio visível no campo “De” e os resultados de SPF ou DKIM. A assinatura DKIM pode continuar válida se o conteúdo assinado não tiver sido alterado, mas também pode falhar se houver uma mudança relevante na mensagem. O RFC 7960 trata justamente de problemas de interoperabilidade entre DMARC e fluxos indiretos de e-mail, como encaminhamentos. Ele não determina que toda mensagem encaminhada falhará nem que toda falha terminará na pasta de spam.

O novo padrão afeta um encaminhamento que já estava configurado? Pode haver alterações de comportamento em sistemas que atualizem sua implementação, mas a publicação do RFC, sozinha, não demonstra que uma regra específica foi modificada. Antes de mudar qualquer configuração, verifique uma mensagem afetada e os resultados mostrados pelo serviço que a recebeu. Não troque em massa os aliases nem enfraqueça uma política DMARC com base apenas na data do padrão.

Essa distinção evita uma correção precipitada: uma alteração na política do domínio pode afetar mensagens legítimas e falsificadas, enquanto o problema observado pode estar apenas na classificação da caixa de destino. A decisão depende de evidências da mensagem, não de uma suposição geral sobre a atualização.

Primeiro, localize onde a mensagem parou

Antes de interpretar autenticação, determine se a mensagem não chegou ou se chegou e foi classificada em uma pasta diferente. A busca deve incluir a caixa principal, spam, lixeira e, quando existir, a área de quarentena administrada pela organização. Pesquise pelo remetente e por palavras do assunto; filtros ou regras podem ter movido o e-mail sem que ele tenha passado pelo spam.

Registre o endereço de destino, o remetente, o horário de recebimento mostrado pela caixa e o assunto. Escolha uma mensagem concreta como amostra e preserve seu conteúdo original. Esse registro facilita comparar o que foi enviado, o que passou pelo encaminhamento e o que o serviço de destino avaliou. Evite encaminhar a mensagem como um novo e-mail para fazer a análise: essa ação cria outra etapa de entrega e pode alterar os cabeçalhos que você precisa examinar.

A diferença é operacional: uma mensagem classificada como spam já chegou ao sistema de destino; uma mensagem que não aparece em lugar algum pode exigir investigação do remetente ou do encaminhador. Tratar ambos os casos como “DMARC bloqueou” costuma levar à pessoa errada e pode esconder a causa real.

Como ler os resultados de autenticação sem tirar conclusões apressadas

Os resultados podem aparecer no cabeçalho Authentication-Results. A especificação RFC 8601, sobre esse campo de cabeçalho, define como informações de autenticação podem ser registradas. O nome do campo, sozinho, não garante que a avaliação veio de uma fonte confiável: considere qual servidor o adicionou e se o cabeçalho pertence ao serviço que realmente recebeu a mensagem.

Se a interface tiver uma opção para exibir a mensagem original ou os cabeçalhos completos, procure os resultados de spf, dkim e dmarc. O guia oficial para consultar a autenticação de mensagens também descreve como localizar informações desse tipo na interface correspondente. A tela varia entre serviços, mas a lógica da análise é a mesma: anote cada resultado e, quando disponível, o domínio usado em cada verificação.

Como interpretar DMARC, SPF e DKIM nos cabeçalhos? Leia os resultados separadamente e confirme a relação entre eles. Um SPF com fail mostra que aquela verificação não passou para o domínio avaliado; não identifica, por si só, onde a mensagem foi alterada nem prova que o remetente original era fraudulento. Para o DMARC, importa também se o domínio autenticado por SPF ou DKIM está alinhado com o domínio visível no campo “De”.

O que fazer se SPF falhar, mas DKIM passar? Não altere imediatamente a política SPF nem conclua que a mensagem é inválida. Primeiro confirme se o dkim=pass corresponde a um domínio alinhado com o endereço do remetente e se o resultado DMARC aparece como aprovado. Se o encaminhamento mudou o caminho de transporte, o SPF pode falhar enquanto uma assinatura DKIM válida ainda sustenta o alinhamento. Se o DMARC também falhou, encaminhe os resultados completos ao responsável pelo remetente ou pelo encaminhador, conforme a etapa que apresenta a inconsistência.

Verifique se o encaminhamento mudou a mensagem

A próxima pergunta é se o conteúdo chegou intacto ao destino. Alguns sistemas acrescentam informações, reescrevem o assunto, inserem avisos ou modificam partes do corpo. Dependendo do que foi alterado e do que a assinatura protege, isso pode invalidar a verificação DKIM. Uma mensagem encaminhada também pode ter cabeçalhos adicionais, por isso compare os resultados registrados pelo servidor original com os que aparecem no destino, quando ambos estiverem disponíveis.

A documentação oficial sobre boas práticas para encaminhar e-mails recomenda atenção ao modo como a mensagem é retransmitida e à preservação de informações relevantes para autenticação. Isso é uma orientação operacional do serviço, não uma garantia de que qualquer mensagem encaminhada terá um resultado específico. Uma configuração que funciona para uma lista de mensagens não prova que funcionará para todos os remetentes ou destinos.

Para uma comparação útil, guarde a mensagem original, se o remetente puder fornecê-la, e examine a mensagem recebida depois do encaminhamento. Verifique se o assunto ou o corpo foram alterados, se há avisos inseridos e se a assinatura DKIM passou em uma etapa e falhou em outra. Quando só existe a versão encaminhada, não é possível atribuir com segurança uma mudança ao remetente ou ao intermediário sem evidência adicional.

Cinco etapas para encontrar o responsável

Siga a sequência abaixo antes de alterar regras. Ela separa a coleta de evidências da correção e reduz o risco de modificar uma configuração de domínio que não causou o problema.

Etapa 1: escolha uma mensagem afetada

Use um e-mail específico que tenha ido para spam. Anote remetente, destinatário, assunto e horário de recebimento. Se o problema se repetir, registre cada ocorrência separadamente; não misture resultados de remetentes diferentes como se fossem uma única falha.

Etapa 2: confirme que houve entrega

Pesquise nas pastas disponíveis e na quarentena. Se encontrar a mensagem, registre onde ela apareceu e se o serviço indicou um motivo de classificação. Se não encontrar, confirme se o remetente usou o endereço correto e pergunte se recebeu uma notificação de falha ou rejeição.

Etapa 3: examine os cabeçalhos completos

Localize Authentication-Results e anote os resultados de SPF, DKIM e DMARC, além dos domínios avaliados e do serviço que registrou cada resultado. Não copie apenas a palavra fail: o domínio e o contexto da verificação são necessários para comparar o que ocorreu.

Etapa 4: compare o conteúdo antes e depois do encaminhamento

Verifique se o assunto, o corpo ou cabeçalhos relevantes foram reescritos. Se possível, peça ao remetente uma cópia original ou os resultados registrados na saída. Compare essa evidência com a mensagem recebida e veja se a assinatura DKIM continuou válida.

Etapa 5: encaminhe o caso à parte responsável

Use o padrão dos resultados para escolher o próximo contato. Se a mensagem já falhava na origem, o remetente ou a equipe que administra o domínio de envio deve verificar sua autenticação. Se a divergência surge após a retransmissão ou coincide com uma alteração de conteúdo, procure quem administra a regra ou o domínio de encaminhamento. Se SPF, DKIM e DMARC aparecem aprovados, mas a mensagem continua no spam, trate o caso como uma decisão de classificação do serviço de destino e use o mecanismo de revisão ou de remetentes permitidos oferecido por ele.

Para domínios próprios, o administrador deve verificar os registros DNS atuais, os serviços que enviam mensagens e todas as rotas de retransmissão antes de alterar políticas. Não copie valores de SPF, DKIM ou DMARC de um exemplo genérico: registros dependem da arquitetura efetivamente usada. Uma alteração indiscriminada pode autorizar servidores indevidos, interromper envios legítimos ou mascarar um problema que está na caixa de destino.

Decida entre corrigir autenticação e revisar a classificação

A investigação deve terminar com uma ação proporcional à evidência, não com uma mudança preventiva para toda a conta. Se a falha aparece na autenticação original, o remetente precisa conferir a configuração do domínio de envio. Se a mensagem muda durante o encaminhamento, o administrador desse fluxo deve avaliar a regra e a preservação do conteúdo. Se a autenticação está consistente e o serviço ainda classifica a mensagem como spam, use a ferramenta de revisão ou a lista de remetentes permitidos da caixa de destino, quando disponível.

Há vantagens e limites em cada caminho:

• Ajustar a origem resolve problemas de autenticação que se repetem em vários destinatários, mas depende do administrador do domínio remetente.
• Corrigir o encaminhamento pode preservar melhor o conteúdo e os resultados de autenticação, mas não controla a decisão final do serviço que recebe a mensagem.
• Revisar a classificação no destino pode corrigir um falso positivo localizado, mas não deve substituir a correção de uma falha de autenticação recorrente.
• Alterar a política DMARC sem diagnóstico pode afetar muitos envios legítimos e não garante que a mensagem deixe de cair no spam.

Quando um alias é a escolha certa

Um alias ajuda a separar identidades de recebimento e a manter mensagens de projetos ou serviços organizadas. No entanto, encaminhar uma mensagem por um alias acrescenta uma etapa à rota; isso não equivale a controlar a autenticação do remetente nem a decisão do provedor que recebe a mensagem. Para mensagens importantes, mantenha uma forma de localizar o remetente e recuperar o acesso, em vez de depender de um endereço que possa ser desativado ou de uma regra que ninguém monitore.

Se estiver decidindo entre um alias duradouro e um endereço temporário, a diferença central é a necessidade de continuidade: mensagens de clientes e avisos que precisam permanecer acessíveis pedem um caminho estável; uma inscrição pontual ou um teste que não requer acompanhamento pode não justificar um endereço permanente. O guia sobre alias de e-mail ou endereço temporário ajuda a avaliar essa escolha sem confundir privacidade de cadastro com solução para autenticação de mensagens.

Para cadastros pontuais nos quais você quer limitar a exposição do endereço principal, consulte também este guia para proteger seu e-mail ao se cadastrar em serviços. Essa medida ajuda a separar o endereço usado no cadastro da caixa que recebe mensagens, mas não corrige autenticação falha nem substitui um endereço estável para comunicações que exigem acompanhamento.

Para reduzir falsos diagnósticos, conserve um registro simples para cada incidente: remetente, destino, horário, pasta em que a mensagem apareceu, resultados SPF/DKIM/DMARC e se o conteúdo parecia ter sido alterado. Esse conjunto permite identificar padrões por remetente ou por rota e é mais útil do que mudar configurações depois de uma única mensagem.

Se o caso envolver apenas uma inscrição, um teste ou o recebimento pontual de um código, um endereço temporário pode evitar expor o endereço principal a esse cadastro. O OrbForward pode ser considerado para esse tipo de uso; já mensagens de clientes, contas importantes ou comunicações que exigem respostas e recuperação de acesso pedem um endereço estável e uma rota de recebimento que você possa acompanhar.