Corrija a população de evidências
A porcentagem do painel tem pouco significado sem o seu denominador. Defina o conjunto de relatores, as janelas de tempo, as regras exclusivas de identidade do relatório e as mensagens representadas por cada linha. Compare os mesmos arquivos de entrada imutáveis entre ferramentas. Registre as configurações de importação e as versões de esquema suportadas para que as diferenças na análise possam ser investigadas em vez de descartadas como opções de apresentação.
Preservar os resultados brutos da autenticação separadamente dos resultados avaliados por políticas alinhamento. Um relatório pode mostrar uma SPF passa para um domínio de envelope não relacionado enquanto o alinhamento SPF avaliado pela política falha. As contagens agregadas de linhas representam a população de mensagens relatadas, não necessariamente todas as mensagens enviadas pela organização. Os relatórios de participação e chegadas atrasadas limitam a cobertura, conforme descrito por RFC 9990.
Reconciliar duplicatas e totais de linhas
Considere um exemplo de relatório fictício normalizado escrito, não um conjunto de dados XML. O Repórter A contribui com um relatório com oitenta mensagens alinhadas e vinte com falhas. Uma importação repetida e exata desse mesmo relatório não deve duplicar o denominador. O repórter B contribui com cinquenta mensagens alinhadas sob o mesmo ID de relatório textual; sua identidade de repórter diferente evita a desduplicação inadequada nesta política de teste defensiva. A Seção 3.5.1 RFC 9990 exige que os identificadores de relatório sejam exclusivos entre os relatórios do mesmo domínio; esta colisão intencional é um caso de robustez, não um endosso à reutilização de identificadores em conformidade. O total único esperado é cento e cinquenta, com cento e trinta alinhados.
Uma cópia conflitante usando o mesmo relator, ID de relatório, janela e domínio de política, mas com linhas diferentes, é colocada em quarentena para revisão, em vez de substituir silenciosamente a primeira importação. Uma implementação futura deve comparar cargas canônicas sob uma regra de normalização documentada para detectar esse conflito. Estas escolhas são uma política de ingestão proposta; eles não afirmam que os IDs de relatório por si só sejam globalmente exclusivos ou que todos os fornecedores implementem as mesmas regras.
Explique as diferenças antes de julgar a qualidade
Se uma ferramenta exibir um total diferente, rastreie a discrepância até uma linha, relatório ou exclusão documentada. Verifique limites de fuso horário, vários domínios de relatórios, erros de análise, importações repetidas e filtros. Uma alta porcentagem de aprovação pode resultar do descarte de linhas malformadas ou desconhecidas. Uma percentagem mais baixa pode simplesmente incluir uma população mais vasta. Nenhum dos resultados estabelece qualidade sem reconciliação.
Exigir uma exportação vinculando o resultado exibido às identidades, contagens e regras de classificação do relatório de origem. O exemplo escrito demonstra apenas contabilidade normalizada e tratamento duplicado; ele não valida compactação, segurança XML, análise de esquema ou serviço de relatório de produção. Eles precisam de testes separados com arquivos brutos aprovados. Termine com um registro de exceção que torna visíveis os formatos não suportados e a atribuição incerta, em vez de ocultá-los em uma contagem de importação bem-sucedida.
Inspecione o razão de casos com escopo definido
A chave de ingestão revisada inclui relator, ID do relatório, janela do relatório e domínio da política. O primeiro relatório para brand.test está incluído; sua cópia idêntica é excluída; o relatório do segundo repórter está incluído; a cópia conflitante do primeiro repórter é colocada em quarentena. Isso preserva a população brand.test em 150 mensagens, 130 alinhadas.
Um quinto controle usa o ID de relatório e a janela idênticos do primeiro relator, mas o domínio de política other.test, com sete mensagens alinhadas. Ele é incluído como um relatório separado, não confundido com uma duplicata ou conflito. O total combinado é 157, enquanto o painel brand.test ainda usa 150. O livro de caso escrito indica cada entrada hipotética e decisão pretendida. Esta proposta de política chave e de conflito deve ser avaliada em relação aos formatos e populações reais que estão sendo importados; não é uma afirmação universal sobre todas as ferramentas de relatório.
Aplique o denominador correto
Para brand.test, o cálculo ilustrativo é (80 + 50) / (80 + 20 + 50) = 130/150, ou cerca de 86,67 por cento. Incluir other.test altera o cálculo combinado para 137/157, cerca de 87,26 por cento, e responde a uma pergunta diferente. Os dados conflitantes em quarentena devem permanecer visíveis como não resolvidos, e não convertidos silenciosamente em uma contagem de mensagens boas ou ruins. Estas são demonstrações aritméticas sobre rótulos inventados, não relatórios analisados ou resultados observados de produtos.
Escopo do protocolo e limites de avaliação
RFC 9989 Seções 4.4, 5.3.5 e 5.4 distinguir identificadores autenticados, alinhamento e manuseio do receptor. Uma assinatura válida por si só não é uma assinatura completa DMARC veredicto, e um passe não valida o conteúdo comercial. RFC 9990 Seções 3.1, 3.5.1, 3.5.4 e 7 descrever evidências agregadas, relatar identidade, duplicatas e privacidade. A avaliação comercial proposta, a equipe e as portas de autoridade aqui são recomendações editoriais, e não características do produto exigidas pela RFC. Nenhum suplemento executável ausente é necessário para ler estes exemplos escritos; as reivindicações operacionais exigem testes observados autorizados separadamente.