Ler relatórios DMARC

Módulo 4: Capacidade de entrega: SPF, DKIM e DMARC na prática · Tempo de leitura: 12 minutos

Objetivo de aprendizagem: Depois desta lição, saberá abrir e ler um relatório agregado DMARC, determinar por linha qual é a origem e porque é que esta é aprovada ou rejeitada, e decidir o que corrigir, o que pode ignorar e quando pode reforçar a sua política.

Conceitos-chave: relatório agregado (aggregate report, RFC 9990), rua, XML, gzip ou zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, relatório de falhas (ruf, RFC 9991), serviço de relatórios, privacidade

O que recebe

Se tiver colocado um endereço rua no seu registo DMARC (lição 4.4), os grandes destinatários como Google, Microsoft e Yahoo enviam-lhe aproximadamente todos os dias um relatório agregado. Trata-se de um e-mail com um anexo, normalmente um ficheiro XML comprimido com um nome do género:

receiver.example!example.com!1793923200!1794009599.xml.gz

Isto significa: do destinatário receiver.example, sobre o seu domínio example.com, referente ao período entre os dois carimbos temporais (segundos desde 1970; neste caso, 6 de novembro de 2026, o dia inteiro em UTC).

Um relatório não contém conteúdo de mensagens, nem assuntos, e na maior parte dos casos nem endereços de destinatários. Contém, por servidor de envio, o número de mensagens e o resultado do SPF, DKIM e DMARC. Por isso, constitui um resumo fiável de quem envia e-mail em nome do seu domínio, incluindo origens que o próprio tenha esquecido e eventuais burlões.

A estrutura de um relatório

Um relatório tem três partes. A seguir apresentam-se os excertos mais importantes do ficheiro de exemplo desta lição (dmarc-rapport-1.xml).

1. Quem reporta e sobre que período

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Que política o destinatário encontrou no seu domínio

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Verifique sempre isto: se o conteúdo não corresponder ao que pensa que está no seu DNS, significa que o destinatário leu um registo diferente (ou desatualizado).

3. Por origem: um registo

Cada record corresponde a um endereço IP de envio com uma combinação de resultados:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

A diferença mais importante: auth_results versus policy_evaluated

Aqui está o cerne da leitura. No exemplo acima, em auth_results surge duas vezes pass: o DKIM foi aprovado para mailer.example e o SPF foi aprovado para bounce.mailer.example. No entanto, em policy_evaluated surge duas vezes fail. Isto não é uma contradição: policy_evaluated só contabiliza uma verificação aprovada que esteja alinhada com header_from. Nenhum dos dois domínios pertence a example.com, pelo que o DMARC falha.

É assim que se lê cada linha:

1. Veja policy_evaluated. Aparece um pass em dkim ou spf? Então o DMARC foi aprovado e esta origem está em ordem.
2. Tudo falha? Veja os domínios em auth_results. Trata-se de um serviço seu que é aprovado, mas com o seu próprio domínio? Então deve ativar o DKIM com o seu domínio junto desse serviço (lição 4.3).
3. Falha também em auth_results, ou o DKIM está totalmente ausente? Averigue a quem pertence o endereço IP (DNS reverso, lição 5.1, ou uma consulta whois). Se for um dos seus próprios sistemas: corrija. Se for desconhecido e os números forem suspeitos: provavelmente é falsificação.

Padrões que verá recorrentemente

Preste também atenção ao IPv6: um servidor próprio que por vezes envia através de IPv6, enquanto o seu SPF só indica o endereço IPv4, gera um softfail nessas linhas. Com uma assinatura DKIM, o DMARC ainda assim é aprovado, mas é um sinal de que o seu SPF está incompleto.

Do relatório à decisão

Está pronto para reforçar a sua política (de none para quarantine, depois para reject) quando:

• todas as origens que são suas têm, em policy_evaluated, pelo menos um pass;
• isto já se verifica há algumas semanas, em todos os grandes destinatários;
• o que ainda falha é apenas correio reencaminhado com uma assinatura DKIM válida (que ainda assim é aprovado) ou claramente falsificação.

Se uma grande origem própria falhar, como no exemplo o serviço de newsletter com 1250 mensagens, ainda é cedo. Com p=reject, o destinatário rejeitaria essas 1250 newsletters.

Tornar os relatórios legíveis

Um relatório num editor de texto é manejável. Vinte por dia, não. Existem três formas:

• Um serviço de relatórios (existem muitos, incluindo com uma versão gratuita). Coloca o endereço deles em rua e eles transformam os dados em gráficos e listas. Atenção: isto dá a esse serviço acesso a informação sobre quais os servidores que enviam em seu nome, e o endereço de relatório fica no domínio deles (consulte a autorização através de _report._dmarc na lição 4.4). Escolha um serviço de confiança que cumpra o RGPD.
• Uma ferramenta própria: existem programas de código aberto que extraem relatórios de uma caixa de correio e os organizam num resumo.
• Ler manualmente com um visualizador de XML ou um navegador, para consultas ocasionais.

Os relatórios de falhas (ruf, RFC 9991) são diferentes: por mensagem falhada, por vezes com excertos da própria mensagem. Praticamente nenhum grande destinatário os envia, precisamente devido à privacidade. Não precisa deles para implementar corretamente o DMARC.

Na prática: assim é que se apresenta

No WebOké, pode preencher o endereço de relatório na ajuda DMARC no DirectAdmin ou no O meu WebOké (ver lição 4.4), e escolhe uma caixa de correio própria onde os relatórios chegam; um endereço separado, como dmarc@, com uma pasta própria, evita que o correio normal fique soterrado. A leitura é feita com um serviço de relatórios ou um programa à sua escolha. Isto funciona da mesma forma em qualquer fornecedor: o relatório segue um formato padrão.

Resumo

• Um relatório agregado é um ficheiro XML diário (muitas vezes comprimido) por destinatário, com o número de mensagens e os resultados por IP de envio.
• auth_results indica o resultado em bruto do SPF e do DKIM; policy_evaluated indica apenas o que foi aprovado com alinhamento. Um pass em auth_results pode corresponder a um fail no DMARC.
• O correio reencaminhado reconhece-se por DKIM pass com SPF fail; a falsificação reconhece-se por tudo fail a partir de um IP desconhecido.
• Só reforce a sua política quando todas as suas próprias origens forem aprovadas durante algumas semanas.
• Os relatórios de falhas (ruf) são raros e não são necessários.

Quiz

Exercício

Exercício Z4.5: Ler um relatório DMARC. Abra o ficheiro de exemplo dmarc-rapport-1.xml (um relatório agregado sobre example.com, com dados fictícios). Responda às perguntas: que política o destinatário encontrou, quantas mensagens constam no total no relatório, quantas delas falharam o DMARC, qual é a linha do serviço de newsletter e o que deve acontecer aí, qual é a linha de correio reencaminhado, qual é a linha provavelmente de falsificação, o que deve mudar no registo SPF de acordo com a linha 6, qual é a linha que só é aprovada graças ao DKIM num serviço com o seu próprio Return-Path, e pode o domínio passar agora para p=quarantine? O programa verifica as suas respostas com uma chave fixa e explica, para cada pergunta, qual a linha do relatório que dá a resposta.

Para saber mais

Os passos indicados nestes artigos aplicam-se aos painéis do WebOké; noutros fornecedores o funcionamento é semelhante.

• O que é o DMARC? Explicação em linguagem simples
• Manual DirectAdmin 5.9: Configurar o DMARC
• Curso gratuito de DNS 4.5: DMARC: o que os destinatários devem fazer com e-mails falsos
• RFC 9990 (DMARC Aggregate Reporting), com o relatório de exemplo no anexo B; RFC 9991 (Failure Reporting)