Substitua a promessa percentual por uma decisão explícita
Um plano de implementação que diz “aplicar rejeição a dez por cento das correspondências com falha” precisa ser revisado antes de ser reutilizado sob a atualização DMARC especificação. RFC 9989 remove o mecanismo pct e define um sinal de teste chamado t. Esta é uma mudança na linguagem política disponível, e não uma prova de que cada receptor mudou o seu software. A tarefa prática é identificar o que o plano existente pretendia proteger e, em seguida, comparar essa intenção com a semântica atual e o comportamento legado observado.
Não converta mecanicamente uma porcentagem em um valor de teste. Um plano percentual tenta limitar a quantidade de tráfego que recebe tratamento. Um sinal de teste altera o tratamento solicitado e pode desencadear um tratamento especial. Esses são controles diferentes. Os proprietários de empresas devem decidir quais as rotas legítimas que devem ser representadas na comparação, que impacto da falha é aceitável e que provas permitiriam a próxima mudança de política.
Entenda o que a especificação atual solicita
RFC 9989 Apêndice A.6 explica que o comportamento histórico de pct era inconsistente fora de seus pontos finais e que pct=0 adquiriu significados úteis de tratamento especial. O mecanismo atualizado preserva um conceito de teste em vez de uma percentagem geral seletor. A versão do registro permanece v=DMARC1; não há mudança DNS para uma string de versão chamada DMARC2.
Sob seção 4.7, t é padronizado como n. Com t=y, o tratamento de mensagem com falha especificado está um nível abaixo da política selecionada: a rejeição torna-se quarentena e a quarentena torna-se nenhuma. Uma política selecionada como nenhuma não é afetada. O sinal também pode solicitar tratamento especial por parte do ator avaliador e não altera a geração de relatórios DMARC . Estas são semânticas especificadas, não uma garantia da pasta final, resposta de rejeição ou resultado de entrega em cada destinatário.
Mantenha a política p, sp ou np selecionada na avaliação. O teste não está restrito à sequência de políticas que um operador vê primeiro em um painel. O domínio e o caminho de descoberta determinam qual política se aplica. Uma explicação correta de t não pode compensar uma investigação que verificou um domínio diferente do autor real da mensagem.
Identifique o risco de implementação mista
Um receptor que não reconhece t pode ignorá-lo e continuar usando sua lógica de política suportada. Por outro lado, uma implementação da especificação atualizada não ganha uma regra de distribuição percentual de um valor pct antigo. Um recorde conter ambas as tags não é, portanto, uma forma portátil de solicitar um experimento uniforme em todos os receptores.
Trate o status de implementação como uma propriedade medida de um ambiente e configuração nomeados. Um anúncio de fornecedor, formato de relatório ou logotipo de produto por si só não prova como uma mensagem específica foi processada. Quando um receptor não puder ser inspecionado, preserve a incerteza e evite atribuir sua ação final apenas a uma etiqueta. O tratamento receptor-local permanece um estágio separado sob Seção 5.4 RFC 9989.
Revise também as suposições ocultas do plano antigo. A percentagem destinava-se a limitar a perda de correio legítimo, avaliar o encaminhamento, estimar o volume de falhas ou testar o serviço de relatórios? Cada propósito precisa de observações diferentes. Reduzir o tratamento para todas as mensagens que falham não é a mesma experiência que aplicar um tratamento mais forte a um subconjunto selecionado, mesmo que ambos os planos sejam descritos informalmente como implementação gradual.
Escreva os critérios de aceitação antes de alterar DNS
Prepare uma comparação remetente por remetente que inclua rotas legítimas periódicas e de baixo volume. Retenha o registro atual exato, a diferença proposta, as identidades aplicáveis e os casos de mensagens representativos. Registre a autenticação comum e alinhamento resultados separadamente da política selecionada, status de teste, substituições locais e disposição final. Defina as condições que interrompem a implementação, incluindo falta de cobertura ou falhas inexplicáveis de mensagens legítimas.
Use evidências agregadas com cuidado. Seção 3.3 RFC 9990 explica que um período de relatório pode abranger mudanças políticas e conter observações mistas. Um rótulo de dia em um relatório não é prova de que uma política governe cada mensagem contada. Preserve o período do relatório, a política observada e o tempo de implantação, em vez de comparar duas porcentagens não rotuladas.
A mudança proposta deve ter um proprietário responsável e uma linha de base recuperável. A remoção de pct de um plano legado pode remover uma restrição que uma implementação mais antiga estava usando. Adicionar t não prova que a restrição foi substituída ali. Uma reversão também altera o estado publicado, em vez de reescrever instantaneamente todas as observações armazenadas em cache, portanto, a evidência de recuperação precisa de seu próprio tempo e escopo.
Exemplo fictício de uma tradução rejeitada
Nesta revisão fictícia, Exemplo de Fabricação tem uma planilha antiga contendo p=reject e pct=10. Um editor propõe substituir a porcentagem por t=y e chamar o resultado de “o mesmo piloto de dez por cento”. O revisor rejeita essa descrição: a semântica de teste atual solicita quarentena para mensagens com falha sob uma política de rejeição selecionada, em vez de selecionar dez por cento para rejeição.
A matriz proposta contém uma coluna de semântica atual, uma coluna de implementação legada e uma coluna de observação. O primeiro pode ser preenchido a partir da especificação; as outras colunas exigem implementações identificadas e testes autorizados. Eles permanecem não executados neste exemplo. Nenhum registro DNS foi publicado, receptor consultado ou mensagem entregue para o exercício.
A próxima decisão é chegar a acordo sobre a experiência real, como testar o tratamento especificado enquanto se observam fluxos legítimos representativos, em vez de preservar um rótulo impreciso. A organização deve então reunir as evidências que apoiam esse experimento antes de aprovar uma transição de produção.
Mantenha os portões de evidências visíveis
O requisito original exato permanece em aberto: comparar um plano antigo baseado em pct com a semântica de teste atual e observações do receptor legado/atuais. A planilha fictícia não fornece observações detalhadas e não pode atender a esse requisito. A porta de comissionamento também permanece visível: Valide as especificações primárias atuais e guarde um exemplo prático antes de esboçar. O texto primário e um exercício ficcional pré-rascunho foram mantidos; a aplicabilidade da implementação, a aprovação humana das PME e qualquer liberação operacional permanecem sem solução. Nenhuma publicação ou mudança de política é autorizada por este manuscrito.