Mapeie as decisões que os sistemas de correio realmente tomam
Um mapa útil de dependência de e-mail conecta um serviço de envio comercial às identidades, registros DNS e serviços de transporte que ele usa. Uma lista de cada Registro TXT não é suficiente. O mapa deve permitir que um proprietário responda o que poderia falhar se um provedor, nome de host, chave ou política mudasse, e identificar as evidências necessárias antes de aprovar essa mudança.
Mantenha a autenticação de identidade de saída e a política de transporte de entrada como ramificações separadas. Eles podem compartilhar administradores e domínios, mas não protegem a mesma decisão. O mapa aqui proposto é um modelo operacional que uma organização deve preencher a partir de seu próprio inventário autorizado e evidências de mensagens. Não se pretende que uma varredura DNS possa descobrir todos os remetentes ou determinar todo o comportamento do receptor.
Inicie cada filial de saída com uma rota de envio real
Crie uma entrada para cada serviço e rota materialmente distinta, incluindo faturamento periódico, sistemas de suporte e campanhas gerenciadas externamente. Registre seu proprietário comercial, proprietário técnico, domínio de autor visível, domínio de envelope, infraestrutura de envio e observado DKIM assinatura de domínio e seletor. Marque cada valor como observado, documentado pelo fornecedor ou ainda desconhecido. Não transforme o guia de configuração genérico de um fornecedor em evidência da configuração desta conta.
O SPF a ramificação começa com a identidade avaliada e segue os termos da política realmente relevantes para essa rota. Inclua referências de políticas externas e as equipes que as controlam. Seções 2.3 e 4.6.4 RFC 7208 explicar a avaliação de identidade e os limites dependentes do DNS. Um mapa de dependências pode mostrar onde as alterações externas podem afetar a avaliação, mas uma contagem estática de nós não estabelece o resultado para cada endereço de conexão.
A ramificação DKIM começa com os valores d e s da assinatura e leva ao registro de verificação do seletor. Adicione qualquer destino de alias, proprietário da zona de destino e proprietário do ciclo de vida da chave. Seção 3.6.2.1 RFC 6376 define esse namespace de pesquisa. Mantenha as chaves privadas fora do mapa; registre a propriedade operacional segura e faça referência a um sistema de gerenciamento de chaves aprovado.
Conecte a autenticação à decisão DMARC relevante
Adicione o domínio do autor, aplicável DMARC registro da política e a evidência de como a política foi descoberta. Link passando identificadores autenticados para o alinhamento decisão, com modo estrito ou relaxado identificado. Sob Seção 4.4 RFC 9989, um identificador SPF ou DKIM alinhado válido pode satisfazer DMARC ; duas passagens de autenticação não relacionadas não podem estabelecer o alinhamento.
Registre a especificação e o contexto de implementação usado para avaliação de descoberta de políticas. RFC 9989 descreve um Caminhada na árvore DNS, portanto, uma suposição herdada da planilha sobre a descoberta deve ser revisada, em vez de levada adiante silenciosamente. O mapa deverá manter a incerteza sobre os receptores cuja implementação não foi verificada. Inclua os destinos dos relatórios e sua propriedade, mas mantenha a disponibilidade dos relatórios separada das evidências de que todos os remetentes legítimos foram observados.
Mostre a política solicitada pelo proprietário e o tratamento observado pelo destinatário em diferentes campos. Isso torna mais difícil para um futuro revisor confundir uma sequência de políticas com uma prova de que uma mensagem foi rejeitada, entregue ou colocada em uma caixa de entrada.
Adicione a ramificação de transporte independente
Para mensagens de entrada, conecte o domínio do destinatário aos seus hosts MX e às suas dependências de endereço. Se MTA-STS é implantado, adicione o registro TXT de descoberta, o host da política HTTPS, o proprietário da manutenção do certificado, o modo publicado, os nomes MX permitidos e o tempo de vida da política. RFC 8461 seções 3 e 6 descrever a descoberta e o armazenamento em cache. O tempo de vida da política não é o mesmo campo que o TTL DNS , e alterar um não reescreve diretamente o outro.
Onde DANE SMTP está implantado, mapeie o DNSSEC cadeia, resolução MX , TLSA registros e o serviço TLS correspondente. RFC 7672 seção 2 torna DNS autenticado uma dependência central. Um registro TLSA copiado para o inventário sem sua validação e relacionamento de certificado é uma evidência operacional incompleta.
Adicione relatórios TLS como um canal de observação, não como um mecanismo de aplicação. RFC 8460 seção 3 define a descoberta de política de relatórios. O destino reportado necessita de um proprietário e de um processo de revisão, enquanto a política de transportes em si continua a ser uma dependência distinta.
Exemplo fictício de migração de provedor
A organização fictícia Example Repairs planeja transferir correspondências com faturas para um novo fornecedor. Seu mapa proposto vincula o serviço de fatura a billing.example.com como o domínio do autor, um domínio de envelope separado e um antigo seletor DKIM hospedado por meio de um alias. O proprietário da migração percebe que o provedor aposentado ainda controla o destino do alias e que algumas mensagens na fila podem conter a assinatura antiga.
A revisão propõe, portanto, uma alteração faseada da sinalização, a verificação da rota de substituição e uma decisão de retirada aprovada separadamente. Enquanto isso, as entradas MX e MTA-STS de entrada permanecem em uma filial diferente e não são editadas automaticamente como parte de uma mudança de fornecedor de saída. Este exemplo foi inventado; as identidades, aprovações e resultados de mensagens não foram obtidos de uma conta real.
O benefício do mapa é a questão que ele expõe: que evidências permitem a retirada desse pseudônimo sem quebrar a verificação de mensagens legítimas? O mapa em si não responde. O proprietário do serviço deve fornecer informações sobre fila e assinatura, e o revisor deve conectar esses fatos à mudança proposta.
Mantenha evidências e propriedade com o mapa
Dê a cada borda uma data da última verificação, referência de evidência, proprietário e gatilho de revisão. Revisite-o após uma migração de fornecedor, rotação de seletor, alteração de delegação, edição de política de transporte ou falha de autenticação inexplicável. Proprietários desconhecidos e arestas não verificadas devem permanecer visíveis em vez de serem preenchidos com suposições.
Antes da implementação, crie a matriz de preparação remetente por remetente, a diferença exata de política e o registro de aprovação. Após a execução autorizada, anexe a mensagem relevante e as observações DNS . Esses são os artefatos originais obrigatórios do catálogo e permanecem abertos aqui. Este manuscrito fornece um design de mapa e um exercício de decisão fictício, não um inventário preenchido de inquilinos ou uma implementação verificada.