Resumo

  • A RFC 9990 define o relatório XML pelo qual um Mail Receiver comunica ao Domain Owner a política que observou, linhas de IP de origem, quantidades e resultados de autenticação em um período.
  • A confirmação DNS de um destino externo de rua confirma uma relação de recebimento de relatórios; ela não prova a veracidade integral dos dados nem transfere a decisão de aplicação de política.

Uma equipe vê uma sequência de milhares de mensagens em um painel e quer responder depressa. A tela apresenta um IP, uma contagem, uma disposição e talvez um motivo de substituição de política. A reação parece óbvia: bloquear o fornecedor, elevar a ocorrência, endurecer o p. Só que o relatório não é a história inteira do correio. Ele é a observação situada de um receptor.

RFC 9990 diz que policy_published contém a configuração DMARC observada pelo sistema receptor. Os record dizem que determinados IPs foram vistos entregando mensagens para o Author Domain naquele sistema. A diferença entre “naquele sistema” e “em toda a Internet” é o que protege uma operação de transformar telemetria útil em afirmação excessiva.

O dado pode revelar um remetente legítimo ainda ausente do inventário, uma alteração de chave, uma rota de reenvio ou um volume que exige investigação. Não identifica automaticamente uma pessoa, não mostra o que todos os outros receptores receberam e não prova intenção maliciosa. SPF e DKIM aparecem no auth_results, mas a RFC os descreve como não interpretados com respeito a DMARC. Mesmo a razão de override é uma explicação da decisão tomada por um receptor, não uma condenação de quem enviou.

A janela do relatório não preenche o que ela não mediu

A estrutura possui metadados, política publicada e pelo menos um registro. O intervalo begin e end é o período do relatório em UTC, tipicamente um dia, e as janelas não deveriam se sobrepor. Ele não é a hora da primeira e da última mensagem que o receptor observou. Essa regra é pequena, porém desarma um erro comum: converter ausência numa janela em ausência de tráfego e presença numa linha em medida completa de uma campanha.

Antes de dar efeito à leitura, compare-a com registros de envio próprios, catálogo de fontes autorizadas, histórico DNS e de chaves, mudanças de fornecedor, caminhos de encaminhamento e observações repetidas de outros receptores. Mantenha separadamente o anexo bruto, seu hash, os campos extraídos e a regra que o painel aplicou. Um rótulo como “risco crítico” é produto de uma escolha interna, não um atributo enviado por RFC 9990.

O DNS impede reflexão; não governa a informação depois da entrega

Um Domain Owner pode indicar por rua para onde deseja os relatórios. Quando o destino fica fora de seu domínio organizacional, o Mail Receiver precisa seguir a verificação de destino externo. Ele consulta a relação DNS especificada; se não houver confirmação positiva, deve ignorar a URI. O mecanismo protege um destinatário contra alguém que publique um endereço de vítima e provoque uma enxurrada de relatórios a partir de muitos receptores.

O que a confirmação positiva diz é estreito: o Report Consumer concordou em receber relatórios daquela relação. Ela não responde se os analistas podem acessar os dados, se um subcontratado os receberá, por quanto tempo ficam guardados, se podem ser associados a outras bases ou se justificam qualquer resposta contra um fornecedor. A RFC observa que a política de privacidade ou os termos do Mail Receiver podem limitar o envio a um intermediário. Os relatórios não trazem conteúdo de mensagens, endereços de pessoas ou IPs individuais, mas ainda podem permitir análise de tráfego em nível de domínio.

Logo, o DNS precisa ser acompanhado por uma ficha operacional: domínios autorizados, finalidade, dono responsável, grupo de acesso, transformações permitidas, retenção, destruição, transferência posterior e contato de incidente. O registro DNS confirma a rota; a ficha define o uso pelo qual alguém responde.

Integridade de transporte não é verdade de conteúdo

Os dados agregados viajam como XML anexado a e-mail, geralmente comprimido com GZIP. A RFC requer que o fluxo que carrega feedback passe DMARC de modo alinhado, reduzindo o risco de processar um relatório fraudulento. IDs e nomes de arquivo ajudam a tratar reenvios duplicados. Isso melhora a disciplina de entrega, não autentica toda afirmação de dentro do XML.

O texto alerta que dados agregados podem ser forjados para influenciar decisões de política ou de arquitetura. Também alerta que relatórios malformados podem esgotar um descompactador ou parser com zip bomb ou XML bomb. Uma mensagem que chega por uma rota conhecida ainda pode ser perigosa ou enganosa.

Receba com orçamento: tamanho antes e depois da descompressão, profundidade XML, tempo de parser, esquema esperado e armazenamento bruto restrito. Quando o formato estiver em dúvida, o avaliador pode descartar ou deixar de lado o relatório e discutir o problema com quem o gerou. Parsear não é confiar; confiar num dado não é decidir uma sanção.

RFC 9989 acrescenta a dimensão temporal: dependendo da cadência, um Domain Owner pode precisar consumir relatórios agregados por meses para ter certeza de que autentica corretamente todo o seu correio; a escolha de p depende de suas necessidades. O informe abastece a política, mas não a produz.

Interpretação editorial: uma camada comum contida

Esta é uma interpretação editorial, não uma regra da IETF: formato comum, transporte e defesa contra reflexão são suficientes para interoperar. Não é necessário que o formato nomeie um soberano da política de e-mail. A trilha concreta deve mostrar qual receptor viu, qual validador aceitou, quem decidiu e qual efeito ocorreu.