Faça da interoperabilidade uma comparação reproduzível
Uma declaração de que um receptor suporta atualização DMARC não é um resultado de interoperabilidade. A questão útil é se as implementações identificadas, dadas entradas equivalentes controladas, produzem a descoberta esperada, alinhamento, política e comportamento de relatórios. Uma comparação precisa preservar esses estágios, em vez de reduzir o experimento ao fato de duas mensagens terem chegado a uma caixa de entrada.
Comece com um catálogo de casos versionado e um proprietário de teste nomeado. Registre o software ou serviço do receptor, configuração, informações de versão acessível e quaisquer informações desconhecidas. Um serviço gerenciado não pode divulgar sua versão de implementação; essa limitação pertence à matriz. Não substitua as informações ausentes por uma reivindicação de adoção derivada de um anúncio de produto ou de um carimbo de data/hora de relatório recente.
Congele as entradas que podem alterar o resultado
Para cada caso, retenha os bytes da mensagem, as suposições do envelope e da fonte de conexão, os dados DNS relevantes, o tempo de observação e o perfil de configuração. Faça diferenças entre duas execuções de teste intencionais e visíveis. Se uma rota modifica uma mensagem assinada ou usa um domínio de envelope diferente, a comparação não é mais apenas sobre o comportamento da implementação DMARC .
Use apenas domínios autorizados, receptores e mensagens controladas e não confidenciais. Mantenha os casos de design fictícios separados dos acessórios executáveis e das amostras reais de entrega. Escreva o resultado esperado e sua referência de especificação antes de executar um teste; caso contrário, um resultado surpreendente pode ser descrito retroativamente como esperado. Um caso não executado deve permanecer explicitamente não executado e não receber uma aprovação inferida da documentação.
O inventário do remetente também é importante. Incluir rotas legítimas representativas, especialmente serviços indiretos e periódicos, ao decidir se a cobertura laboratorial é relevante para uma mudança na produção. Um caso de protocolo pode estar correto ao omitir o fluxo de negócios que será realmente afetado.
Compare a descoberta e o alinhamento antes da disposição
Seção 4.10 RFC 9989 descreve o comportamento de caminhada na árvore DNS , enquanto implementações anteriores podem usar seu método de descoberta herdado compatível. Os casos devem abranger uma política explícita de domínio do autor e acordos alternativos controlados. Adicione casos de política de subdomínios e domínios inexistentes aplicáveis apenas com condições DNS claramente especificadas; um rótulo dizendo que o subdomínio não é suficiente para definir a política esperada.
Capture o registro selecionado e os identificadores autenticados usados para alinhamento. Em seguida, registre a política p, sp ou np selecionada e o estado de teste. Seção 4.4 RFC 9989 define o relacionamento de alinhamento. Passagem SPF ou DKIM para uma identidade não relacionada não deve ser rotulada erroneamente como DMARC bem-sucedida apenas porque um receptor finalmente aceitou a mensagem.
Por fim, registre as substituições locais e a disposição real como resultados separados. A filtragem de conteúdo, o roteamento e as decisões locais podem criar resultados de entrega diferentes, mesmo quando o cálculo comum DMARC concorda. Diagnosticar o primeiro estágio diferente em vez de atribuir cada diferença de caixa de correio à descoberta de políticas.
Incluir a transição de teste sem assumir equivalência
Um caso útil compara como as implementações identificadas processam um recorde contendo p=reject e t=y. Sob Seção 4.7 RFC 9989, o tratamento de teste para uma mensagem com falha é um nível inferior, quarentena. Uma implementação legada que não reconhece t pode seguir uma lógica suportada diferente. Esta é uma questão de compatibilidade esperada para medir, não uma razão para implantar esse registro como uma chave de segurança universal.
Separe os casos pct históricos dos casos t. Um plano que uma vez solicitou amostragem não deve ser declarado compatível simplesmente porque um receptor atualizado ignora o controle antigo sem erro de sintaxe. O efeito comercial pretendido, o mecanismo especificado e o resultado observado precisam de seus próprios campos.
Retenha casos de tags desconhecidas, políticas ausentes e entradas malformadas em um escopo de teste controlado. Não use um domínio de produção como alvo experimental para registros deliberadamente ambíguos. O próprio projeto de teste deve identificar os requisitos relevantes de aprovação e recuperação antes de qualquer execução operacional.
Relatórios de teste como um recurso separado
RFC 9990 define a estrutura do relatório agregado, incluindo o método opcional de descoberta e o contexto de teste. Um relatório contendo esses campos pode apoiar uma observação sobre esse relatório; um campo opcional omitido não prova comportamento legado. Preserve o relatório bruto e o perfil do analisador, pois um consumidor pode perder informações mesmo quando o receptor as gerou corretamente.
Os períodos de relatório podem incluir transições de políticas, portanto um agregado nem sempre é uma transcrição de uma única política congelada. Alinhe a janela de tempo da comparação e a evidência da fonte antes de usar contagens para explicar uma mensagem específica. A desduplicação e a compatibilidade de esquema pertencem ao plano de teste de relatórios, em vez de ficarem ocultas em um painel.
O relatório de falhas é outra dimensão independente. RFC 9991 deixa a geração sujeita à disposição do receptor e às restrições de privacidade. Não relatório de falha não é prova suficiente de um teste de interoperabilidade que falhou. Registre se o relatório foi solicitado, apoiado, autorizado, recebido e interpretável sem coletar conteúdo desnecessário da mensagem.
Matriz fictícia sem células de resultado observadas
Uma planilha fictícia nomeia o Receptor A como uma referência semântica atual e o Receptor B como um perfil legado. Ambos recebem a mesma mensagem inventada e instantâneo DNS para p=reject; caso t=y . A coluna de política esperada para A é derivada da especificação. A implementação de B e todos os resultados reais ainda requerem evidências; nenhum produto deve se comportar como o rótulo.
A matriz planejada também inclui um controle alinhado direto, um caso de domínio autenticado não relacionado, um caso de descoberta de fallback e casos de formato agregado. Cada célula de execução permanece não executada. Isso torna a preparação da planilha útil sem a necessidade de fabricação de prova de conformidade ou adoção do receptor.
Preservar o requisito exato de liberação
A porta de evidência original é: Manter uma matriz de interoperabilidade versionada com casos de entrada idênticos e resultados observados completos. O requisito de comissionamento é: Validar as especificações primárias atuais e reter um exemplo prático antes de elaborar. A matriz ficcional retida não satisfaz nem a observação ao vivo nem a prontidão para a produção. Evidências de implementação nomeadas, resultados controlados, revisão humana das PME, aprovação de implementação de negócios e autorização de publicação permanecem em aberto. Este manuscrito não realizou nenhum teste de receptor, alteração DNS ou transmissão de mensagens.