Um SPF a investigação de encaminhamento começa com duas entradas observadas: o endereço IP conectado ao avaliador e o domínio que está sendo avaliado. Olhar apenas para o endereço De visível pode produzir um diagnóstico persuasivo, mas incorreto. Anote essas entradas em cada salto antes de adicionar servidores a um registro DNS . A política SPF do autor original não pode descrever todos os serviços de encaminhamento não relacionados que um destinatário pode escolher.
Capture as entradas SMTP
Referências: RFC 7208 §2.3, RFC 7208 §2.4, RFC 5321 §4.4.
No receptor inicial, identifique o IP remetente e CORREIO DE identidade a partir de registros confiáveis ou evidências confiáveis do receptor. No receptor final, repita o exercício para a conexão de encaminhamento. UM Return-Path registrado após a entrega final é útil, mas não é um histórico completo dos envelopes anteriores. Para um caminho reverso vazio, considere SPF 's Identidade HELO regras em vez de inventar um domínio de envelope. RFC 7208, especialmente as seções 2 e 4, definem os insumos da avaliação.
Registre as respostas DNS conforme observado no momento da avaliação, quando disponível. Uma pesquisa posterior pode mostrar autorização alterada e não pode reconstruir conclusivamente um resultado passado. Preservar erros temporários, erros permanentes, falhas e outros resultados de forma distinta. Colapsando cada não-passagem em falsificação perde a evidência necessária para separar o encaminhamento de uma política malformada ou de um problema transitório DNS .
Compare entrega direta e encaminhada
Referências: RFC 7208 §4.1, RFC 9989 §4.4.2.
Suponha que author.example autorize seu servidor de origem, mas não o servidor forwarder.example . No caminho direto, a primeira conexão pode passar por author.example . No caminho encaminhado com o envelope original retido, o destinatário final avalia um IP diferente em relação à mesma política. O resultado diferente decorre da entrada alterada; isso não implica que o DNS do remetente original estivesse necessariamente errado.
Se o intermediário reescrever o envelope em seu próprio domínio, a avaliação utilizará a política desse domínio. Um passe ali estabelece autorização para a identidade reescrita. DMARC compara separadamente a identidade autenticada com o domínio De da mensagem. Mantenha essa comparação visível no registro do caso. RFC 9989 define o alinhamento exigência.
Reproduzir a comparação de identidade
Referências: RFC 9989 §4.4, RFC 9989 §5.3.5.
O dispositivo de alinhamento rigoroso contrasta um envelope original com um envelope de forwarder estilo SRS. Ele fornece aprovação ou reprovação SPF como entrada e calcula a decisão de alinhamento downstream. No caso srs-footer, SPF é verdadeiro para forwarder.example , DKIM é falso e o From visível permanece author.example . O modelo retorna falso em vez de tratar uma verificação SPF bem-sucedida como suficiente.
Esta é uma aritmética de identidade executável, não um resolvedor SPF . Ele não implementa inclusões, redirecionamentos, macros, limites de pesquisa ou cache DNS e não reconstrói um envelope de produção. Use o resultado para entender a distinção e, em seguida, colete amostras diretas e indiretas autorizadas para a implantação real. Não há evidências de implantação externa; a captura histórica fornece uma comparação SMTP controlada separada abaixo.
Escolha o reparo responsável
Referências: RFC 7208 §2.4, RFC 6376 §3.4.
Para um intermediário sob seu controle, inspecione a reescrita de envelope suportada e sua própria autorização de envio. Para um remetente de origem, preserve DKIM alinhado ao longo da rota. Não adicione o encaminhador arbitrário de um destinatário ao SPF do domínio original apenas porque ele aparece em um relatório de falha; a autorização expande quem pode usar essa identidade de envelope.
Após uma alteração, compare a mesma rota e tipo de mensagem e registre SPF , alinhamento, DKIM e entrega como resultados separados. Mantenha um plano de reversão para a configuração específica alterada. Um mais amplo Registro SPF não substitui a prova de que o serviço de encaminhamento está autorizado, é necessário e funciona conforme pretendido.
Evidência laboratorial SMTP retida
Referências: RFC 7208 §4, RFC 6376 §6.
A captura retida datada de 7 de novembro de 2026 às 21:29:16 UTC registra conexão de IP e MAIL FROM para seis entregas. Com DNS do fixture autorizando apenas 127.0.0.2 para author.example , pyspf retorna passagem para a conexão direta e falha para o encaminhador 127.0.0.3 que retém esse envelope. Reescrever em forwarder.example , cuja política de fixture autoriza 127.0.0.3 , altera SPF para passar. O autor visível permanece author.example , portanto, o avaliador de alinhamento estrito ainda depende do resultado real DKIM . As respostas DNS e todas as pesquisas são retidas.
O executor histórico e as mensagens retidas foram inspecionados para esta revisão; o experimento de rede não foi executado novamente. Sua execução original usava apenas loopback e não enviava mensagens pela Internet. Seu receptor cria Authentication-Results provenientes dos seus próprios controlos, dando a esses domínios uma proveniência laboratorial conhecida. O resultado e a disposição da autenticação permanecem separados: todas as seis amostras SMTP recebem 250 sob uma política de captura explícita, incluindo amostras com falha. O limite de confiança é este laboratório controlado, não um fornecedor de caixa de correio de produção. O adaptador DNS fornece respostas de fixação retidas em vez de consultar DNS público, e o avaliador DMARC usa apenas igualdade de domínio estrita. A descoberta completa do domínio organizacional, a análise da política de produção e os resultados da implantação em tempo real permanecem não testados.