Um inventário de remetente herdado é uma ferramenta de decisão, não uma lista de endereços IP. Antes de padronizar os domínios adquiridos, conecte a correspondência observada ao serviço específico do cliente que a produziu, ao proprietário da empresa e às identidades aprovadas. Um provedor familiar pode hospedar tráfego legítimo e indesejado, portanto, o reconhecimento da infraestrutura por si só não é aprovação.
Comece com múltiplas fontes de evidências
Reúna exportações de configurações autorizadas, registros de aplicativos, registros de contas de fornecedores, observações DNS e evidências de correio disponíveis. Preserve de onde veio cada observação e quando foi coletada. Relatórios agregados pode revelar IPs de origem e padrões de autenticação, mas não pode estabelecer de forma independente a intenção comercial da organização ou completar a população de remetentes. RFC 9990.
Para cada serviço, finalidade do registro, proprietário responsável, conta do provedor ou inquilino, criticidade, visível Do domínio, domínio do envelope, DKIM identidade de assinatura, último teste representativo e evidência de aprovação. Mantenha os campos desconhecidos explícitos. Registre a finalidade de envio e recebimento separadamente para domínios que possam estar inativos ou defensivos.
Atribuir identidades antes de adicionar autoridade
Compare os identificadores observados com a configuração real do fornecedor e o fluxo de trabalho comercial. DMARC usa alinhamento entre o domínio do autor e um identificador autenticado com sucesso; um resultado de aprovação genérico sem os identificadores pode ocultar o problema que você precisa resolver. RFC 9989.
Não adicione uma fonte desconhecida ao SPF simplesmente porque o correio parece ter origem lá. SPF autoriza hosts para a identidade avaliada e sua avaliação inclui limites de pesquisa DNS . RFC 7208 , seção 4.6.4. Uma nova inclusão pode expandir a autoridade, exceder os limites operacionais ou não conseguir corrigir o alinhamento. Estabeleça primeiro o serviço pretendido e a rota autenticada apropriada.
Mantenha a aprovação e os testes separados
Um serviço aprovado ainda pode falhar no teste de migração; uma mensagem autenticada ainda pode vir de um serviço não aprovado. Armazene ambos os estados. As evidências de aprovação devem identificar a decisão responsável, enquanto as evidências de teste devem descrever a transação real, as identidades, o resultado e o prazo. Não use um passe de teste como substituto da propriedade de uma empresa.
Suponha que um serviço de cobrança herdado tenha um proprietário de empresa nomeado e uma finalidade aprovada, mas a identidade de assinatura da conta de destino não tenha sido verificada. Um segundo serviço tem uma mensagem de passagem alinhada, mas nenhum empresário identificado. A primeira necessita de provas de rota antes da migração; o segundo necessita de atribuição e aprovação antes de ser tratado como um serviço autorizado. Nenhuma das lacunas é resolvida pelo resultado tranquilizador do outro serviço.
Estas são decisões hipotéticas de inventário, não registros gerados ou testes executados. Mantenha campos separados para propriedade, identidades pretendidas, aprovação e cobertura de teste atual. Quando o proprietário da aplicação fornecer a evidência da conta faltante, atualize apenas o estado que ela estabelecer; não altere automaticamente um resultado de migração não testado para aprovado.
Transforme a atribuição em um plano de migração
Serviços de grupo por proprietário verificado, dependência e prontidão. Defina as identidades e os testes alvo pretendidos antes de editar os registros. Preserve rotas desconhecidas para investigação, com nome de proprietário e prazo, em vez de aprová-las ou excluí-las silenciosamente. Mantenha a configuração antiga e um plano de recuperação aprovado para cada transição consequente.
Após a padronização, conciliar as observações reais com o inventário aprovado e investigar novas identidades. Mantenha os serviços aposentados e suas decisões no histórico. Um inventário útil continua sendo um registro operacional durante mudanças de fornecedor e resposta a incidentes, em vez de uma planilha abandonada quando o projeto de fusão termina.
Este fluxo de trabalho de inventário e revisão é um modelo operacional recomendado. NIST SP 800-53 Rev. 5 CM-8 e CM-3 fornecem uma base geral para inventários contábeis e mudanças controladas; eles não prescrevem esses campos específicos de e-mail nem conferem aprovação. Catálogo de controle NIST.