Como ler relatórios DMARC antes de aplicar a política

Assim que você publica um registro DMARC com um endereço em rua=, os provedores de caixa postal começam a lhe enviar relatórios diários sobre cada servidor que usa o seu domínio — e aprender a ler relatórios DMARC é a diferença entre uma transição segura para a aplicação da política e mandar acidentalmente as suas próprias faturas para o spam. O detalhe é que esses relatórios chegam como um XML denso, que nenhum ser humano foi feito para folhear. Este guia explica exatamente o que um relatório agregado contém, como interpretá-lo para encontrar e-mails legítimos que estão falhando e onde um analisador de relatórios prova seu valor.

A resposta curta#

Os relatórios agregados de DMARC (aqueles disparados pela tag rua=) são arquivos XML que um receptor lhe envia mais ou menos uma vez por dia. Cada um agrupa por IP de envio os e-mails que ele viu se dizendo do seu domínio e, para cada fonte, informa: quantas mensagens, se o SPF e o DKIM passaram e alinharam e o que o receptor fez a respeito. Você os lê para montar um inventário completo de quem envia em seu nome e para confirmar que todo fluxo legítimo autentica em alinhamento antes de endurecer sua política de p=none para quarantine e reject. O XML bruto é sofrido, então quase todo mundo o carrega em um analisador de relatórios DMARC que o transforma em uma tabela legível.

Já tem um relatório em mãos? Cole ou faça upload dele no analisador de relatórios DMARC gratuito para acompanhar este guia com seus próprios dados — ele processa tudo no seu navegador, nada é enviado para servidores.

O que dispara um relatório agregado#

O gatilho é uma única tag no seu registro DMARC. Ao publicar rua= em _dmarc.seudominio.com, você está pedindo a cada receptor participante que lhe envie feedback agregado:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

A partir daí, grandes receptores — Google, Yahoo, Microsoft, Comcast e muitos outros — reúnem tudo o que viram do seu domínio ao longo de uma janela de 24 horas e enviam um único relatório XML por domínio. O relatório costuma chegar como um anexo compactado (.xml.gz ou .zip) com um nome de arquivo que codifica o autor do relatório, o seu domínio e o intervalo de datas. Você pode apontar rua para vários endereços e pode até coletar relatórios de um domínio que não controla usando um destino externo, embora isso exija um registro de autorização extra no domínio receptor. Se você ainda não publicou um registro, comece pelo passo a passo ordenado de configuração do DMARC — o envio de relatórios só começa depois que o registro está no ar.

Como ler um relatório agregado DMARC, linha por linha#

Todo relatório agregado segue o mesmo esquema XML, definido na RFC 7489. Ele tem três partes: quem enviou o relatório, qual política você tinha publicado na época e, então, um ou mais blocos <record> — um por fonte de envio. Aqui está um exemplo reduzido de um único registro:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

A coisa mais importante de entender é que um relatório apresenta o resultado da autenticação em dois lugares diferentes, e eles significam coisas distintas:

O bloco auth_results informa se o SPF e o DKIM passaram, e ponto. O bloco policy_evaluated informa se eles passaram em alinhamento, que é a única coisa com que o DMARC se importa. Esses dois podem divergir, e essa lacuna é onde acontece a maior parte do seu trabalho de investigação.

Identificando uma fonte legítima que está falhando#

Aqui está o padrão que você está caçando, e por que ele importa. Imagine um registro em que o source_ip claramente pertence a uma plataforma de marketing que você usa, o header_from é o seu domínio e auth_results mostra spf: pass — mas o domínio SPF listado é o próprio domínio de retorno (bounce) da plataforma, não o seu, e policy_evaluated/spf mostra fail. Aquela mensagem se autenticou para alguém, só que não para você de uma forma que alinhe. Sob p=none, a disposition ainda é none, então nada quebrou — ainda. No momento em que você passa para quarantine ou reject, cada mensagem naquele count começa a ir para o spam ou a ser rejeitada.

Então a leitura é sempre a mesma comparação em três passos:

• Identifique a fonte. Mapeie cada source_ip para um serviço real. Um DNS reverso rápido ou a rotulagem embutida do analisador normalmente dá nome a ele. Seu objetivo é uma lista completa — os relatórios costumam revelar uma ferramenta de faturamento esquecida ou uma antiga plataforma de campanhas ainda enviando em seu nome.
• Verifique o alinhamento, não apenas a autenticação. Olhe para policy_evaluated, não para auth_results. Uma fonte pode passar no SPF ou no DKIM e ainda assim reprovar no DMARC porque o domínio para o qual ela se autenticou não coincide com o seu "From".
• Decida: corrigir ou deixar falhar. Se a fonte for legítima, corrija o alinhamento dela — adicione-a ao SPF ou, melhor, configure a assinatura DKIM no seu domínio para que o domínio de assinatura coincida. Se for um falsificador, a falha é exatamente o que você quer, e é a prova de que o seu futuro p=reject vai cumprir seu papel.

Normalmente vale priorizar o alinhamento de DKIM em vez do de SPF, porque uma assinatura DKIM viaja junto com a mensagem e sobrevive ao encaminhamento, enquanto o alinhamento de SPF quebra no instante em que o e-mail é retransmitido. A mecânica do alinhamento — relaxado versus estrito, domínio organizacional versus correspondência exata — é abordada no guia explicativo de SPF, DKIM e DMARC caso você precise ir mais devagar no conceito.

RUA versus RUF: dois relatórios bem diferentes#

O DMARC define duas tags de relatório, e elas não são intercambiáveis:

• rua — relatórios agregados. Os resumos XML diários descritos acima. Eles contêm contagens e resultados agrupados por fonte, sem conteúdo de mensagem, e são aquilo em que você se apoia durante toda a implantação. Todo receptor sério os envia.
• ruf — relatórios forenses (de falha). Relatórios por mensagem gerados no momento em que uma mensagem individual falha. Historicamente, eles podiam incluir cabeçalhos e, às vezes, trechos da mensagem, o que significa que podem carregar dados pessoais.

Como os relatórios forenses podem expor informações de destinatários, a maioria dos grandes provedores parou de enviá-los anos atrás por questões de privacidade, e muitos remetentes nunca chegam a publicar ruf. Um registro que solicita ambos se parece com isto:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com"

Na prática, você vai receber um fluxo constante de relatórios agregados rua e poucos ou nenhum relatório forense ruf. Planeje seu monitoramento em torno dos dados agregados; trate quaisquer relatórios forenses que você receber como um bônus ocasional e só habilite ruf se tiver uma base legal e um lugar para armazenar o que pode ser dado pessoal.

Por que você quer um analisador, e não uma caixa de entrada bruta#

Você pode abrir o XML na mão e, para um único domínio com dois ou três remetentes, isso é suportável por um tempo. Deixa de escalar rápido. Um domínio movimentado gera dezenas de relatórios por dia de diferentes receptores, cada um listando muitos IPs de origem, e o sinal interessante — um remetente legítimo falhando silenciosamente no alinhamento — fica soterrado sob tags com carimbos de tempo Unix e endereços IP sem rótulo.

Um analisador de relatórios DMARC ou painel de monitoramento recebe os relatórios em um endereço dedicado, descompacta e interpreta o XML, resolve os IPs para nomes de serviços reconhecíveis e consolida tudo em uma tabela que você efetivamente consegue ler: fontes de um lado, volumes de aprovação e falha do outro, tendências ao longo do tempo. Os bons destacam fontes novas ou que começaram a falhar, para que você perceba uma mudança sem reler cada arquivo. Quer você use um serviço hospedado ou um parser auto-hospedado, o trabalho é o mesmo — transformar uma pilha de XML em "aqui está quem envia em seu nome, e aqui está quem ainda não está alinhado". Essa clareza é o que torna os relatórios acionáveis em vez de meramente arquivados.

Como isso se encaixa na implantação segura#

Ler relatórios não é uma tarefa separada de configurar o DMARC — é o meio da implantação, e pular essa etapa é como as pessoas soterram o próprio e-mail. A sequência:

1. Publique p=none com rua. Nada muda na forma como o seu e-mail é tratado; o envio de relatórios simplesmente é ativado.
2. Leia os relatórios agregados por um ciclo de envio completo. Duas semanas no mínimo, mais tempo se você tiver fluxos de baixa frequência, como extratos mensais. Monte o inventário completo das fontes.
3. Corrija toda fonte legítima que falha no alinhamento. É aqui que o tempo de verdade vai, e é para onde os relatórios lhe apontam.
4. Passe para quarantine e depois reject. Só quando os relatórios mostrarem cada fluxo genuíno passando em alinhamento. p=reject é a configuração que de fato interrompe a falsificação e satisfaz as regras para remetentes em massa nos requisitos de remetente do Google e do Yahoo.

Os relatórios continuam valendo seu lugar depois que você chega ao reject, também — é assim que você pega uma ferramenta SaaS recém-adicionada que começa a enviar em seu nome, ou uma campanha de falsificação ganhando força contra a sua marca. Observá-los junto com suas reclamações de feedback loop e sua reputação de remetente geral lhe dá um sistema de alerta precoce, em vez de uma tarefa de configuração única.

Um limite honesto: passar no DMARC em alinhamento prova quem você é, não que você é um bom remetente. Um domínio perfeitamente alinhado enviando para endereços mortos ou spam traps ainda cai no spam — a autenticação é o bilhete de entrada, e a qualidade da lista e o engajamento decidem a colocação. Esse quadro maior é o tema do guia de entregabilidade, e é o motivo mais comum para e-mails legítimos ainda irem para o spam mesmo com relatórios limpos.

Perguntas frequentes#

O que os relatórios agregados de DMARC realmente contêm?#

Um relatório agregado (rua) é um arquivo XML que agrupa, por endereço IP de envio, os e-mails que um receptor viu vindos do seu domínio. Para cada fonte, ele lista a quantidade de mensagens, os resultados brutos de SPF e DKIM e contra quais domínios foram verificados, o veredito alinhado ao DMARC e a disposição que o receptor aplicou de acordo com a política que você publicou. Ele nunca inclui assuntos, corpos de mensagens nem endereços de destinatários — apenas contagens agregadas e resultados de autenticação, o que é justamente o que o mantém seguro em termos de privacidade.

Qual é a diferença entre relatórios RUA e RUF?#

rua solicita relatórios agregados diários: contagens resumidas e resultados de aprovação/falha agrupados por fonte, sem conteúdo das mensagens. ruf solicita relatórios forenses ou de falha, gerados por mensagem que falha e, historicamente, capazes de incluir cabeçalhos e dados da mensagem. Como os relatórios forenses podem carregar dados pessoais, a maioria dos grandes receptores já não os envia, então você deve montar seu monitoramento sobre os relatórios agregados e tratar quaisquer dados forenses como um extra ocasional.

Por que uma fonte aparece com SPF aprovado, mas DMARC reprovado no meu relatório?#

Porque o DMARC exige alinhamento, não apenas autenticação. Uma mensagem pode passar no SPF pelo próprio domínio do serviço de envio enquanto o seu domínio fica no "From" visível — o SPF passa, mas os domínios não coincidem, então o DMARC reprova. Leia o resultado de policy_evaluated em vez do auth_results bruto: o primeiro reflete o alinhamento. Corrigir isso normalmente significa adicionar a fonte ao seu registro SPF ou, de forma mais robusta, habilitar a assinatura DKIM no seu próprio domínio para que o domínio de assinatura coincida.

Preciso de um analisador de DMARC ou consigo ler os relatórios sozinho?#

Para um domínio com um ou dois remetentes, dá para ler o XML bruto por um tempo. Isso deixa de ser prático rapidamente, porque um domínio movimentado recebe dezenas de relatórios por dia cheios de IPs sem rótulo e carimbos de data e hora. Um analisador ou painel de monitoramento descompacta e interpreta os relatórios, nomeia as fontes e consolida os dados em uma tabela legível com tendências — que é o que transforma os relatórios em decisões, em vez de uma pasta não lida.

Os relatórios agregados dizem quem está enviando em seu nome; eles não dizem se a lista por trás desse e-mail está limpa. Passe seus endereços pelo verificador de e-mail gratuito para eliminar domínios mortos, erros de digitação e spam traps antes que eles gerem bounce — porque um domínio perfeitamente alinhado ainda precisa de uma lista saudável para conquistar a caixa de entrada.