SPF a delegação permite que uma política dependa de informações controladas em outro lugar. Isso pode reduzir a administração duplicada, mas também transfere parte da decisão de autorização para fora do registro local. A questão prática não é se a delegação é boa ou má. É se o seu escopo e responsabilidades operacionais são compreendidos.
Identifique o mecanismo de delegação real
Leia o registro publicado e desenhe o caminho de avaliação. Uma inclusão e um redirecionamento não são intercambiáveis. Um include corresponde quando sua avaliação alvo é aprovada, com o qualificador include determinando o resultado externo; uma falha alvo não se torna simplesmente a falha final da política pai. Um redirecionamento é considerado quando os mecanismos locais não correspondem e um mecanismo all impede que ele seja usado. Essa semântica é definida em RFC 7208 §5.2 e RFC 7208 §6.1.
Distinga também uma dependência de política de delegação de zona DNS ou de uma integração de publicação. Uma política referenciada pode influenciar a autorização sem ter permissão para editar sua zona. Uma integração DNS pode conceder poderes de mudança mais amplos. Documente ambas as camadas, se ambas existirem.
Indique o que o outro operador pode autorizar
Registre o serviço comercial, os domínios do envelope e o escopo permitido. Mantenha as instruções atualizadas do fornecedor e o proprietário da empresa nomeado. Determine se o alvo é específico do inquilino ou partilhado entre clientes, sem assumir que uma política partilhada fornece automaticamente proteção de identidade ao nível do inquilino.
Use uma análise ilustrativa: uma empresa delega um subdomínio de envelope de cobrança a uma política gerenciada. Suponha que o alvo seja alcançado por meio de uma inclusão ou redirecionamento positivo. Posteriormente, a operadora adiciona outro provedor a esse destino. O registro local da empresa pode permanecer inalterado enquanto sua autorização efetiva for alterada. Se isso é aceitável depende do escopo e dos controles acordados. Um log de alterações DNS local por si só não forneceria o histórico completo.
Mantenha as questões de identidade relacionadas separadas. Alinhamento DMARC não transforma todas as redes autorizadas em remetentes confiáveis de todas as mensagens e não certifica o conteúdo das mensagens.
Planeje dependências ausentes ou com falha
Um alvo quebrado não é necessariamente uma incompatibilidade inofensiva. SPF distingue falhas temporárias DNS , erros permanentes de política e resultados normais de autenticação. Teste os comportamentos relevantes para o mecanismo em uso, em vez de prometer que a avaliação “não dará certo” durante uma interrupção.
Preserve um inventário e monitoramento de dependências que possa detectar alterações de destino, políticas ausentes e erros de avaliação. Alerte a equipe capaz de atuar, e não apenas a pessoa que originalmente comprou o serviço. Defina quando um incidente exige escalonamento de fornecedores, substituição local ou alterações temporárias de roteamento. Qualquer intervenção na produção ainda necessita do processo normal de aprovação e comprovação.
Prepare uma substituição enquanto o acesso funciona
Mantenha uma lista independente de remetentes legítimos e as instruções dos provedores suportados. Elabore um registro de saída desse inventário, não copiando uma lista de endereços inexplicável do alvo atual. Uma substituição de redirecionamento pode exigir a restauração de toda a política pretendida, incluindo o resultado não correspondente.
Teste a substituição proposta para remetentes relevantes, endereços não relacionados, IPv4 e IPv6 quando usados e comportamento de limite de pesquisa. Identifique quem pode publicá-lo e quais evidências são necessárias para aprovar a mudança. Preserve a política atual e planeje visualizações mistas em cache durante a transição.
Verifique o fechamento após sair
Após a mudança aprovada, inspecione as respostas autoritativas e recursivas e envie mensagens representativas. Confirme se a dependência antiga não é mais referenciada pelas políticas afetadas, enquanto verifica outros domínios antes de cancelar o acesso ao serviço compartilhado. Remova o acesso desnecessário à integração por meio do processo de conta autorizada.
Mantenha a configuração final, a evidência da mensagem recebida e a transferência de propriedade juntas. Uma saída bem sucedida significa que a sua política restante é compreensível e mantida, e não apenas que o nome do antigo fornecedor desapareceu. Para uma comparação mais ampla, use Modelos operacionais SPF.
Coloque a decisão por escrito
Use dois casos hipotéticos de falha. Um include alcançado cujo destino não retorna nenhum produz permerror, não é uma incompatibilidade inofensiva; um redirecionamento alcançado cujo alvo não tem Registro SPF também produz permerror sob RFC 7208 §5.2 e RFC 7208 §6.1. Por outro lado, uma falha no retorno do destino de inclusão é uma não correspondência e a avaliação pode continuar no pai. Teste esses casos em um equipamento controlado antes de confiar em um substituto de interrupção. Nenhum teste desse tipo foi executado aqui.