Comece com um comportamento, não com um registro substituto
Uma migração de padrões torna-se gerenciável quando cada decisão de implementação tem uma especificação nomeada e um proprietário responsável. Um editor DNS , um alinhamento o mecanismo e um analisador de relatório agregado não executam o mesmo trabalho. Chamando todos os três “DMARC suporte" oculta dependências que importam quando um componente muda e outro permanece em uma implementação mais antiga. O produto prático é um mapa de componentes para requisitos, com versões, interfaces e evidências de aceitação retidas, em vez de uma declaração de que todo o conjunto foi atualizado.
O conjunto de documentos atual foi publicado em maio de 2026. RFC 9989 define o mecanismo central e obsoletos RFC 7489 e RFC 9091 . RFC 9990 abrange relatórios agregados; RFC 9991 cobre relatórios de falhas e também atualiza RFC 6591 . Identificação de registros recentes do Editor RFC RFC 9989 e RFC 9990 como Padrões Propostos. O texto publicado RFC 9991 identifica sua categoria Standards Track. Estas são especificações publicadas, não rascunhos inacabados, mas a publicação não estabelece a implementação de um destinatário específico.
Dê ao mecanismo principal um contrato preciso
Atribuir análise de registros, descoberta de políticas, descoberta de domínio organizacional e alinhamento de identificadores para Seções 4.7–4.10 RFC 9989. O Domínio do Autor vem da mensagem RFC5322 campo. Um domínio de política descoberto pode ser diferente daquele Domínio do Autor, e o domínio organizacional usado para alinhamento relaxado é outra saída explícita. Perder essas distinções em uma interface pode fazer com que um analisador correto alimente um mecanismo de decisão incorreto.
O registro DNS ainda começa com v=DMARC1. “DMARCbis" é um nome para o trabalho de padrões, não uma permissão para inventar o DMARC2. A descoberta atual usa caminhada de árvore DNS limitada em vez de tratar uma lista de verificação histórica de lista de sufixos públicos como o algoritmo inteiro. As tags psd, np e t exigem cobertura de decisão separada. O Registro IANA marcas pct, rf e ri históricas; não certifica se um produto implementado os ignora, interpreta ou expõe.
Preserve as distinções entre uma falha normal DMARC , informações DNS indisponíveis, uma política inválida e a disposição final da mensagem do destinatário. A seção 4.10.1 RFC 9989 contém tratamento especial para tags de política inválidas quando um URI de relatório agregado sintaticamente válido permanece. Uma regra simplista de que “toda política malformada se torna nenhuma” eliminaria as suas condições. Registre a seção exata ao lado do caso do analisador que o exerce.
Trate o feedback agregado como sua própria implementação
Mapeie o produtor agregado, o validador XML, o consumidor de relatórios, o tratamento de duplicatas e a integração de entrega para Seções 3–4 RFC 9990 e Apêndice A. A interface de relatórios precisa da política realmente avaliada, dos resultados da autenticação, da contagem de mensagens e do contexto do período do relatório. Um painel que exibe XML não é evidência de que o receptor upstream selecionou a política correta ou de que todos os remetentes relevantes apareceram nos dados.
Os destinos de relatórios externos merecem sua própria linha de componentes. A autorização de destino é uma verificação técnica antiabuso e não um consentimento para transmitir dados organizacionais arbitrários. Coloque a geração de relatórios, a verificação de destino e as decisões de acesso/retenção sob critérios de aceitação distintos. A seção 7 RFC 9990 trata da privacidade, enquanto a seção 8 alerta sobre conteúdo de relatório malicioso ou falso. A proteção do analisador e a confiança na fonte, portanto, pertencem ao mapa junto com a validade do esquema.
Não reutilize um analisador agregado para relatórios de falhas
O feedback de falhas é um canal diferente, com diferentes riscos de divulgação. RFC 9991 rege sua geração e formato, trabalhando com as especificações de relatórios de falha de autenticação referenciadas. A solicitação ruf e as condições fo não são equivalentes à agregação rua. Um receptor pode recusar o relatório de falhas, e a ausência de um relatório de falha não há evidência de que todas as mensagens foram transmitidas.
Uma integração de relatório de falha pode encontrar cabeçalhos de mensagens ou conteúdo que um pipeline agregado foi projetado para não transportar. Identifique quem pode solicitá-lo, para onde pode ser enviado, como o material recebido está contido e qual análise de privacidade se aplica. Nunca ative-o apenas para fazer uma matriz de recursos parecer completa. Os requisitos básicos de participação, o relatório opcional de falhas e as capacidades anunciadas de um produto comercial são afirmações diferentes que exigem evidências diferentes.
Trabalhe em um inventário de componentes fictícios
Considere um serviço fictício com seis módulos: decodificador de políticas, resolvedor de descoberta, avaliador de alinhamento, construtor agregado, consumidor XML e coletor de falhas. Os três primeiros são mapeados para RFC 9989 . Os próximos dois são mapeados principalmente para RFC 9990 . O coletor mapeia principalmente para RFC 9991 . O armazenamento compartilhado e os controles de segurança herdam requisitos de todos os caminhos de relatórios que gerenciam. Este inventário é um exemplo documental original, não uma afirmação sobre a arquitetura do EmailAuth .
Para cada módulo, mantenha seu identificador de construção real, seções relevantes, contrato de entrada/saída, proprietário e dispositivo de aceitação. Um dispositivo de descoberta fictício pode passar uma política selecionada e seu domínio de origem para um dispositivo agregado fictício; a linha do relatório deve preservar essa distinção em vez de substituir silenciosamente o domínio From visível. Em seguida, introduza uma solicitação de relatório de falha e confirme se o projeto a encaminha para um caminho de processamento autorizado separadamente. Estas são verificações propostas, não execuções concluídas.
Mantenha o status, a errata e a implantação separados
A comissão exata é: Mapear cada componente de implementação para RFC 9989 , 9990 ou 9991 e verificar as erratas. A cobertura real da implementação não foi fornecida. A recuperação da errata atual falhou e foi interrompida, portanto este rascunho não pode afirmar que os documentos não possuem errata. A discussão da RFC 9989 sobre a errata resolvida RFC 7489 é um contexto histórico, não uma nova verificação de errata para os três novos documentos.
Antes do lançamento, o proprietário da implementação deve reconciliar o inventário real, o proprietário dos padrões deve resolver as erratas atuais e o proprietário do teste do receptor deve preservar as evidências de interoperabilidade no escopo da versão. A revisão especializada, as verificações da rota de produção, a aceitação visual e a aprovação da publicação também permanecem abertas. O resultado útil hoje é um mapa passível de revisão que expõe as provas em falta sem transformar uma norma actualizada numa afirmação sem suporte de implementação universal.