Defina o que significa aceitação
Um portfólio de domínios pode conter correspondência de funcionários, aplicativos transacionais, serviços de marketing, nomes inativos e subdomínios delegados. Uma marca verde ao lado de um domínio corporativo não estabelece que essas diferentes rotas se comportem corretamente. Um pacote de aceitação deve definir os domínios, identidades, implementações e rotas que estão sendo avaliadas antes de listar os testes. Seu objetivo é apoiar uma decisão de liberação limitada e não fabricar um selo de conformidade universal.
O núcleo atual DMARC especificação é RFC 9989, com relatórios agregados em RFC 9990 e relatórios de falhas em RFC 9991. Uma revisão da migração deve distinguir essas funções. O registro do protocolo ainda se identifica com v=DMARC1; uma alteração na especificação não cria um valor DNS denominado DMARC2. Mantenha a versão da especificação e o valor do registro on-wire como campos separados no pacote. RFC 9989 , seção 4.7 e Apêndice C
Divida o portfólio por comportamento, não apenas por propriedade
Crie grupos cujos membros compartilhem uma propriedade operacional significativa: uma rota de correspondência de funcionários, uma integração específica de fornecedor, um modelo de subdomínio delegado ou um escopo de política de não envio. Preserve as exceções em vez de forçar todos os domínios no mesmo modelo. Dois domínios pertencentes à mesma empresa podem usar provedores e caminhos de descoberta de políticas diferentes, enquanto várias marcas podem compartilhar uma rota subjacente.
Para cada grupo, registre o proprietário da empresa, o proprietário DNS , o aplicativo de envio, os domínios de origem e de autenticação relevantes e a implementação em análise. Separe um inventário de produção real de uma lista de exemplos proposta. A presença de um domínio num registo de activos não prova que todos os seus fluxos de envio foram encontrados. Rotas desconhecidas devem permanecer visíveis como lacunas, e não serem contadas silenciosamente como aceitas.
Decida o que o pacote pode estabelecer. Os dispositivos de análise off-line podem demonstrar o tratamento de entrada especificado em uma implementação nomeada, mas não comprovam a disponibilidade DNS em tempo real ou o comportamento de mensagens recebidas. Um instantâneo DNS pode suportar a descoberta de políticas de uma só vez, mas não mostra a implantação de cada receptor. Mantenha esses níveis de evidência explícitos durante toda a decisão de liberação.
Crie famílias de testes de protocolo distintas
Os testes de política devem abranger o posicionamento e o valor de versões válidas e inválidas, tags suportadas, descoberta de políticas e o comportamento relevante de caminhada na árvore DNS . Alinhamento os testes devem distinguir matérias-primas SPF ou DKIM sucesso a partir do alinhamento com o RFC5322 domínio. Inclui casos em que um mecanismo alinhado é aprovado e outro falha, para que o pacote não exija acidentalmente que ambos sejam aprovados para o sucesso DMARC .
Os testes de relatórios pertencem a famílias separadas. Os relatórios agregados possuem sua própria descoberta, verificação de destino externo e estrutura XML. O relatório de falhas tem um formato e uma superfície de privacidade diferentes. Uma análise política bem-sucedida não é evidência de que a entrega de relatórios ou o processamento seguro de relatórios funcionem. O pacote deve vincular cada resultado esperado à seção específica que o fornece, marcando separadamente o comportamento específico da implementação. RFC 9989 , seção 4.4, 4.7 e 4.10; RFC 9990 , seção 3, 4 e Apêndice A; RFC 9991 , seções 4 e 5
Versão de luminárias e observações juntas
Cada equipamento precisa de um identificador, hash de conteúdo, finalidade, requisito de fonte, suposições de entrada e resultado esperado. Cada execução precisa do nome e versão da implementação, configuração, tempo de execução, resultado observado, logs e revisor. Se o fixture mudar, preserve uma nova versão em vez de substituir silenciosamente a entrada antiga sob o mesmo identificador. Caso contrário, uma melhoria aparente poderia ser causada por testes mais fáceis, em vez de comportamento corrigido.
Os resultados esperados devem ser escritos antes de interpretar a execução observada. Quando um resultado for diferente, classifique se a expectativa estava errada, se a implementação era diferente, se o fixture era inválido ou se o ambiente impediu um teste significativo. Um teste ignorado ou bloqueado não é uma aprovação. Um resultado aceite pela política local não deve ser reclassificado como estando em conformidade com os padrões sem explicar a discricionariedade relevante.
Mantenha segredos e conteúdo desnecessário de mensagens fora dos equipamentos. Use insumos sintéticos autorizados e limitados para trabalhos de laboratório e evidências aprovadas separadamente para rotas de produção. Este artigo não fornece um conjunto de fixtures executado ou autorização para enviar mensagens de teste, alterar registros ou acessar contas de provedores.
Planilha de aceitação de portfólio
A planilha deve conectar um grupo de portfólio a identificadores de equipamentos, resultados esperados, resultados observados, diferenças não resolvidas e uma decisão de liberação. Inclua uma coluna de cobertura mostrando quais domínios ou rotas estão representados e por que esse agrupamento é justificado. Um caso representativo pode apoiar uma inferência documentada, mas não pode tornar-se silenciosamente uma prova de implementações ou fornecedores não relacionados.
Adicione colunas de portas separadas para evidências originais, revisão humana, aplicabilidade da fonte, rotas de produção, acessibilidade visual e liberação do proprietário. Essas portas podem permanecer abertas mesmo quando um teste do analisador offline for aprovado. Registre quem pode fechar cada um e qual artefato é necessário. O proprietário da versão deve ver uma lista concisa de exceções em vez de uma porcentagem que oculta escopos não suportados.
O pacote também deve conter um gatilho de reversão e reavaliação. Uma mudança de provedor, uma mudança de delegação DNS , uma nova rota de envio ou um esclarecimento de especificação podem invalidar uma suposição de aceitação anterior. Preserve o evento que requer reavaliação e as famílias de equipamentos afetadas para que a próxima revisão comece a partir de uma linha de base conhecida, em vez de reconstruir a intenção a partir de tickets dispersos.
Decisão de portfólio fictício
Imagine um portfólio fictício com correspondência de funcionários, um serviço de recebimento e um domínio de marca inativo. O pacote proposto atribui casos de alinhamento às duas rotas de envio e casos de descoberta de políticas a todos os três grupos. Uma implementação de laboratório hipotética lida corretamente com o valor da versão válida, mas difere em um dispositivo de descoberta. Nenhuma execução realmente ocorreu; estas são condições inventadas que ilustram uma decisão de liberação.
A resposta correcta não seria marcar todo o portfólio como pronto porque a maioria dos casos parecia aceitável. O revisor manteria a diferença da descoberta, identificaria quais grupos dependem dela e solicitaria evidências de implementação antes de divulgar esse escopo. O serviço de recebimento ainda precisaria de sua própria evidência de rota autorizada, mesmo que a lógica de alinhamento do laboratório estivesse correta.
Um resultado proposto poderia aceitar um comportamento off-line limitado, mantendo a prontidão para a produção. Essa distinção é útil e não embaraçosa: ela diz ao proprietário exatamente o que as evidências apoiam. O exemplo não afirma que um receptor nomeado adotou RFC 9989 ou que um domínio real passou em um teste.
A evidência original permanece aberta
O catálogo requer um conjunto de acessórios versionado e resultados esperados versus observados, não apenas uma lista de verificação. Este manuscrito descreve como construir esse pacote, mas nenhuma execução de fixture, consulta ao vivo ou resultado observado foi fornecido. A exigência de evidência original permanece, portanto, aberta, assim como todas as seis portas de liberação.
Antes da publicação operacional, um revisor qualificado deve verificar se cada resultado esperado tem uma base oficial atual e se cada observação pertence à versão de implementação declarada. Não trate uma citação da fonte como um substituto para um registro de execução. A declaração de aceitação final deverá indicar o escopo do portfólio coberto, suas exceções e as dependências operacionais pendentes.