SPF's Limite de 10 pesquisas aplica-se a termos específicos dependentes de DNS avaliados durante uma verificação SPF . Não é uma regra permitir dez instruções de inclusão visíveis no registro raiz. As políticas aninhadas compartilham o limite da avaliação, e uma correspondência antecipada pode interromper a verificação antes que as ramificações posteriores sejam alcançadas.
Quando o limite de prazo contado é excedido, o resultado é permerror. Um diagnóstico útil rastreia o remetente conectado através da política aplicável e registra onde a avaliação continua, corresponde ou falha. Esse rastreamento mostra quais dependências precisam de atenção e quais permissões a empresa ainda precisa.
Entenda o que SPF conta
RFC 7208 §4.6.4 identifica incluir, a, MX, PTR e existe, mais o redirecionar modificador, como termos causadores de consultas de DNS sujeitos ao limite geral quando avaliados. Sob RFC 7208 §4.1, as políticas referenciadas compartilham o limite global da avaliação em vez de receberem novos subsídios independentes.
O todos, ip4 e ip6 mecanismos não consomem esse limite de prazo. O experiência modificador não o consome durante a avaliação SPF , embora uma pesquisa de explicação possa ocorrer posteriormente. Outros limites e restrições operacionais ainda se aplicam, incluindo requisitos envolvendo expansão MX / PTR e pesquisas nulas.
A pesquisa SPF TXT inicial não deve ser confundida com um mecanismo de inclusão avaliado. Um diagnóstico deve indicar o que o número exibido representa: uma contagem de termos de protocolo, uma estimativa de expansão estática ou consultas DNS observadas.
Exemplo resolvido: duas inclusões levam a um décimo primeiro mandato
A seguir está um acessório sintético usando domínios de exemplo reservados e endereços IP de documentação. Não é DNS ativo e não é um registro de produção para colar.
A política raiz é:
v=spf1 include:billing.example.net include:messages.example.org -allSuponha que a política de faturamento avalie três inclusões adicionais, cada uma contendo apenas um ip4 mecanismo e -all. Suponha que a política de mensagens avalie seis inclusões adicionais construídas da mesma maneira. Suponha que cada política alcançada tenha um SPF sintaticamente válido Registro TXT, todas as recuperações DNS serão bem-sucedidas, cada política intermediária terminará em -all e nenhum outro termo estará presente. Neste exemplo, nenhum dos endereços autorizados corresponde ao remetente da conexão.
- O faturamento raiz inclui: total em execução 1.
- Três cobranças aninhadas incluem: total em execução 4.
- As mensagens raiz incluem: execução total 5.
- As primeiras cinco mensagens aninhadas incluem: total de execução 10.
- As sextas mensagens aninhadas incluem: excederia o limite, produzindo permerror .
A raiz contém apenas duas inclusões visíveis. O caminho completo não correspondente tenta um décimo primeiro termo contado.
Agora considere um remetente diferente que corresponda à primeira política de cobrança aninhada. Neste jogo, pode passar após duas inclusões contadas. A avaliação não continua através do serviço de mensagens posterior apenas para esgotar o subsídio.
É por isso que um rastreamento de caminho e seu endereço de entrada são importantes. É também por isso que uma ferramenta de expansão estática e uma avaliação específica de um receptor podem exibir contagens de aparência diferente sem medir a mesma coisa.
Rastreie a avaliação real com falha
Colete o IP de conexão, o domínio do envelope avaliado pelo SPF, as respostas TXT relevantes completas e o diagnóstico do receptor. Preservar o tempo: a política referenciada de um fornecedor pode mudar após a entrega original.
Registre cada termo contado alcançado, a política referenciada e o resultado que faz com que a avaliação continue, corresponda ou falhe. Distinguir um erro de prazo excessivo de uma sintaxe malformada, vários Registros SPF, uma dependência circular ou uma falha temporária DNS .
Uma pesquisa de registro raiz ajuda a estabelecer o ponto de partida:
cavar TXT example.com . +noall +respostaO Manual de escavação BIND documenta essas opções de consulta/exibição de DNS. Ele não avalia, por si só, SPF nem estabelece a contagem de pesquisas. Um comando de consulta DNS não substitui o rastreamento.
Escolha uma correção sustentável
Comece com permissões obsoletas. Confirme se uma inclusão não é mais necessária antes de removê-la; serviços compartilhados e correio sazonal podem tornar enganoso um intervalo de silêncio.
Para serviços ativos, verifique a configuração suportada pelo provedor. Um subdomínio de envio dedicado ou uma identidade de envelope personalizada suportada pode reduzir dependências não relacionadas e melhorar a governança, mas as identidades e alinhamento ainda precisa de verificação.
Alterar a ordem do mecanismo pode alterar o caminho avaliado. Teste entradas representativas legítimas e não correspondentes, em vez de mover primeiro o serviço mais ocupado e declarar toda a política corrigida.
O nivelamento pode substituir políticas referenciadas por dados de endereço e reduzir os termos contados. Também cria trabalho de manutenção: as alterações de endereço do provedor devem ser refletidas, as permissões obsoletas removidas e as falhas detectadas. As restrições de comprimento de registro e DNS não desaparecem. Não use faixas amplas ou permissivas +all como um atalho.
Verifique o efeito em serviços legítimos
Uma empresa pode atingir esse problema depois de anos adicionando serviços ao mesmo domínio. As inclusões antigas permanecem, os provedores adicionam dependências e ninguém possui o conjunto completo de permissões.
Peça uma explicação sobre o nível de serviço: quais mensagens legítimas encontram o caminho com falha, quais permissões ainda são necessárias e quem manterá a substituição. A solução aparente mais barata pode se tornar cara se copiar os endereços dos provedores para um recorde que ninguém mantém atualizado.
Avalie o resultado por meio de mensagens legítimas restauradas e permissões controladas. Uma contagem de verificadores mais baixa é uma evidência útil, mas não representa todo o resultado do negócio.
Verifique as permissões resultantes e o alinhamento DMARC
Exigir um mapa mantido de serviço para permissão, uma mudança responsável e evidências de todas as rotas legítimas afetadas. Pergunte se a correção introduziu uma nova dependência DNS ativa, manutenção terceirizada ou reteve o acesso desnecessário à infraestrutura.
Acompanhe o motivo de cada permissão e a condição para aposentadoria. Uma política SPF tecnicamente válida ainda pode autorizar demais. Também não estabelece reputação do remetente ou a segurança do conteúdo de uma mensagem.
Após a correção, reavalie as entradas com falha anterior e o tráfego legítimo representativo. Então verifique DMARC alinhamento separadamente. Uma passagem SPF bruta restaurada para um domínio de envelope não relacionado não corrige uma falha de alinhamento.
A lição prática
Uma correção bem-sucedida demonstra uma avaliação compatível para as entradas relevantes e a continuação do envio legítimo. Mantenha o rastreamento de dependência e o motivo de cada permissão retida. Em seguida, verifique o alinhamento nas mensagens reais; um resultado SPF bruto reparado é apenas uma parte do DMARC .
Registre a próxima decisão
O fixture não correspondente tem 1+3+1+6=11 tentativas de termos contados; a sexta inclusão de mensagens aninhadas excede o limite após 10. A correspondência de faturamento antecipado precisa apenas de duas inclusões. Mantenha esta suposição definida com qualquer comparação de ferramentas e expansão do gráfico de rótulos separadamente da contagem de caminhos avaliados. Nenhum avaliador ou consulta de rede foi executado para esses exemplos.