Defaults.Exposed › Correções › Guides

Email reencaminhado falha o SPF — porque não o consegue corrigir, e o que funciona mesmo (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

Não consegue fazer o SPF passar para email reencaminhado — o reencaminhamento parte o SPF por conceção, e a correção honesta é o DKIM alinhado, que sobrevive ao reencaminhamento. A escala é do tamanho do censo: 7.355.985 de 138.927.207 domínios que publicam SPF autorizam apenas o include de reencaminhamento da Namecheap, com uma quota de SPF estrito de <0.1%, segundo o censo do Defaults.Exposed de 261 milhões de domínios.

Abaixo: porque é que nenhum registo SPF que pudesse escrever sobrevive ao reencaminhamento, porque é que o SRS e o ARC não são ferramentas que controla, e a correção que aguenta — a assinatura DKIM com o seu próprio domínio como o seu pass de DMARC — mais o único caso que parte também o DKIM (listas de correio que reescrevem mensagens) e o que fazer com esse resíduo.

Porque é que o reencaminhamento parte o SPF?

Os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom), não o cabeçalho From. Quando envia diretamente, o IP do seu servidor está no seu registo SPF e a verificação passa. Quando o seu destinatário reencaminha automaticamente a mensagem — para um Gmail pessoal, através de um alias universitário, via o produto de reencaminhamento de um registrar — é o servidor do reencaminhador que a retransmite, normalmente mantendo o seu domínio no Return-Path. O recetor final pergunta agora: este servidor de reencaminhamento está autorizado no seu registo SPF?

Não está, e nunca estará: não escolheu o reencaminhador, não sabe que ele existe, e a mesma mensagem reencaminhada amanhã por um serviço diferente falharia a partir de um IP diferente. O SPF responde a uma única pergunta — “este IP veio de um servidor que o domínio do Return-Path autorizou?” — e para o correio reencaminhado a resposta verdadeira é não. A falha é o SPF a funcionar como especificado, não o seu registo a estar errado.

O censo mostra quão corrente é este caminho: 7.355.985 domínios autorizam o include de reencaminhamento de email da Namecheap (spf.efwd.registrar-servers.com) — o produto de reencaminhamento de um único fornecedor, extraído dos 139 milhões de publicadores de SPF — com uma quota de SPF estrito de <0.1% e só 0,2% a aplicar o DMARC. Esse modelo brando não é desleixo: o reencaminhamento é precisamente onde um -all estrito dispara mal, e o fornecedor cujo produto é reencaminhamento distribui em conformidade. A história completa do qualificador está no nosso relatório ~all vs -all, e o retrato fornecedor a fornecedor em que fornecedor de email dá o SPF mais forte.

Não posso simplesmente adicionar o servidor do reencaminhador ao meu registo SPF?

Não — e o porquê é o artigo inteiro:

1. Não consegue enumerar os reencaminhadores. Qualquer destinatário, em qualquer lado, pode reencaminhar o seu correio por qualquer serviço. O seu registo SPF teria de listar servidores que não pode conhecer de antemão.
2. Listá-los derrotaria o propósito. Os grandes serviços de reencaminhamento retransmitem correio para milhões de clientes. Ponha as gamas deles no seu registo e cada mensagem que qualquer utilizador deles retransmita — incluindo a de um falsificador — passa o SPF como você.

A mesma lógica exclui afrouxar o seu qualificador para “fazer o reencaminhamento funcionar”: o qualificador não é a razão pela qual o correio reencaminhado falha, e com o DMARC em jogo muda menos do que a maioria dos guias afirma — veja os dados do qualificador. O registo não é a alavanca aqui. Pare de a puxar.

E o SRS e o ARC — não corrigem o reencaminhamento?

Abordam-no — mas nenhum deles é seu para implantar:

Dados e estado dos mecanismos a 2026-06-29.

O SRS faz desaparecer o problema de SPF do reencaminhador, não o seu: reescrever o Return-Path muda o SPF de quem é verificado, enquanto o seu cabeçalho From — o domínio que o DMARC defende — fica intocado. O ARC é uma decisão de confiança entre operadores de infraestrutura. Se um guia lhe diz para “implementar SRS” enquanto proprietário de domínio, confundiu-o com o fornecedor de reencaminhamento.

Como faço o meu email sobreviver ao reencaminhamento?

Faça do DKIM, alinhado com o seu domínio, o seu pass de DMARC. Uma assinatura DKIM é criptografia transportada nos cabeçalhos da mensagem: verifica onde quer que a mensagem acabe, por muitos servidores que a tenham retransmitido, desde que o conteúdo assinado não tenha sido modificado. O DMARC só precisa de um pass alinhado — SPF ou DKIM — portanto quando o reencaminhamento mata a perna do SPF, o DKIM alinhado mantém a mensagem autenticada.

1. Execute a verificação gratuita em defaults.exposed antes de tocar no DNS. Mostra se tem DKIM de todo, se ele assina com o seu domínio, e onde está o seu DMARC — para corrigir a lacuna real em vez de lutar com o seu registo SPF.
2. Confirme que o reencaminhamento é mesmo o seu problema. No cabeçalho Authentication-Results de uma mensagem afetada, o correio direto passa o SPF enquanto a cópia reencaminhada falha a partir do IP do serviço de reencaminhamento. Se o SPF e o DKIM passam mas o DMARC ainda falha, tem antes um problema de alinhamento — veja DMARC falha mas SPF e DKIM passam.
3. Ative a assinatura DKIM com o seu próprio domínio em todos os serviços de envio — primeiro o fornecedor de caixas de correio, depois os ESPs e os remetentes transacionais. Os predefinidos dos fornecedores muitas vezes assinam com o domínio do fornecedor, que não alinha; quer d=yourdomain. Comece em como corrigir o DKIM, com percursos de cliques para o Google Workspace e o Microsoft 365.
4. Verifique o alinhamento, não só um pass. O domínio d= na assinatura tem de corresponder ao seu domínio From; dkim=pass no domínio de outra pessoa não faz nada pelo seu DMARC.
5. Deixe o seu registo SPF em paz. Mantenha-o exato para o seu correio direto — continua a autenticar a maior parte do seu tráfego e continua a ser a sua segunda perna de DMARC. Só deixe de tentar que cubra reencaminhadores.
6. Volte a verificar, e depois faseie a aplicação do DMARC deliberadamente — próxima secção, e o guia de implantação de p=none a p=reject.

Esta combinação — SPF mais DMARC aplicado assente em DKIM alinhado — é o padrão à prova de reencaminhamento, e é rara: dos 77,5 milhões de domínios que publicam ~all, só 9,2% (7.116.774) o sustentam com uma política DMARC aplicada, e apenas 3,87% dos 261 milhões de domínios classificados (10.092.481) completam a tríade completa SPF + DKIM + DMARC aplicado, segundo o censo (2026-06-29).

E as listas de correio que reescrevem mensagens?

O único caminho de reencaminhamento a que o DKIM alinhado não sobrevive: listas de correio que modificam a mensagem — uma etiqueta [nome-da-lista] no assunto, um rodapé de anulação de subscrição, um anexo removido. Mude o conteúdo assinado e o hash do corpo deixa de corresponder, portanto o DKIM também falha (dkim=fail: body hash did not verify é o guia próprio dessa falha). Agora ambas as pernas do DMARC estão mortas, e só a lista o pode mitigar (reescrita do From, selagem ARC).

Este resíduo é exatamente para o que serve a aplicação faseada do DMARC. Avançar por p=quarantine com uma rampa de pct enquanto acompanha os relatórios agregados mostra quanto do seu correio real flui por listas que reescrevem antes de uma política p=reject começar a devolvê-lo. Não salte para reject num domínio cujos utilizadores vivem em listas de correio; também não empanque em p=none para sempre. O guia de implantação faseada percorre a rampa.

Perguntas frequentes

O reencaminhamento também parte o DKIM? O reencaminhamento simples, não: a assinatura viaja com a mensagem e verifica no recetor final. O DKIM só parte quando o conteúdo assinado é modificado em trânsito — as etiquetas de assunto e os rodapés das listas de correio sendo o caso clássico — e é por isso que o resíduo das listas se trata com o faseamento da política DMARC, não com nada no DNS.

Devo passar de -all para ~all para o reencaminhamento deixar de falhar? Mudar o qualificador não vai fazer os reencaminhadores passar — não é por isso que falham. É revelador que o include de reencaminhamento da Namecheap, 7.355.985 domínios e a maior população de reencaminhamento dedicado do censo (2026-06-29), venha com uma quota de SPF estrito de <0.1%: o SPF brando é, defensavelmente, o modelo correto para um produto de reencaminhamento. Veja o relatório ~all vs -all para o que o qualificador realmente muda.

Porque é que o meu correio passa o SPF quando enviado diretamente mas falha quando alguém o reencaminha? O recetor verifica se o IP do último servidor transmissor está autorizado pelo registo SPF do seu domínio de Return-Path. Direto: o seu servidor, no seu registo, pass. Reencaminhado: o servidor do reencaminhador, fora do seu registo, fail. O seu registo não mudou — o IP transmissor mudou.

Posso montar SRS para corrigir isto? Só se for o reencaminhador. O SRS corre no servidor que faz o reencaminhamento, e mesmo onde corre, o pass de SPF resultante pertence ao domínio do reencaminhador e não alinha com o seu From — o seu DMARC continua a precisar da perna do DKIM.

O SPF é inútil se o reencaminhamento o parte de qualquer forma? Não. A maior parte do correio é entregue diretamente, onde o SPF funciona exatamente como pretendido, e continua a ser uma das suas duas pernas de DMARC. Dos 261.086.232 domínios no censo (2026-06-29), 138.927.207 publicam SPF — mantenha o seu exato via a página de correção do SPF, e deixe o DKIM transportar o remanescente reencaminhado.

Envie o relatório ao proprietário

Se está a corrigir isto para um cliente ou para o seu empregador, feche o ciclo com evidência. Assim que o DKIM de domínio próprio estiver ativo e o DMARC faseado, volte a executar a verificação gratuita e reencaminhe o relatório classificado ao dono do negócio: datado, em linguagem simples, a mostrar que o domínio se mantém autenticado mesmo quando o seu correio é reencaminhado. É esse o artefacto para a renovação do seguro cibernético e para o próximo questionário de fornecedores — um antes-e-depois documentado, não “liguei uma coisa”.

Verifique o seu domínio → · DMARC falha mas SPF e DKIM passam → · Corrigir o DKIM → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.