Como ler um relatório DMARC sem se afogar em XML

O que é um relatório DMARC de verdade

Publique um registro DMARC com um endereço em rua= e os provedores de e-mail começam a mandar relatórios agregados: um arquivo XML por provedor por dia, listando cada IP que enviou mensagens dizendo ser o seu domínio, quantas cada um enviou e se SPF e DKIM passaram e estavam alinhados.

Duas coisas que vale saber antes de abrir o primeiro:

• Relatórios agregados não contêm conteúdo das mensagens. Sem assuntos, sem destinatários, sem corpo. São contagens agrupadas por IP de envio. É por isso que são seguros de coletar e por isso que não conseguem dizer qual mensagem falhou.
• Não são a mesma coisa que relatórios forenses. Um endereço em ruf= pede amostras de falha por mensagem, que contêm cabeçalhos e às vezes mais. A maioria dos provedores já não envia, por privacidade, então na prática visibilidade de DMARC significa relatórios agregados.

O que eles dão é a única coisa impossível de obter de outro jeito: uma lista de tudo no mundo que envia e-mail como o seu domínio, incluindo os sistemas dentro da sua própria empresa que ninguém lembra de ter configurado. Esse inventário é o objetivo inteiro, e é o que torna possível ir para a aplicação da política sem quebrar nada.

Como começar a receber os relatórios

Um registro mínimo que só coleta dados, sem mudar nada na entrega:

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

Vai em _dmarc.example.com como registro TXT. p=none significa "não aplique política nenhuma, só me conte" — é o ponto de partida certo e não tem como prejudicar a sua entrega. Confira que o registro está mesmo no ar e legível com uma ferramenta de consulta DNS antes de esperar relatórios que nunca vão chegar.

Duas notas práticas. Os relatórios chegam diariamente e em volume, então mande para uma caixa dedicada e não para a sua. E se quiser recebê-los em um endereço de outro domínio, esse domínio precisa autorizar com o próprio registro DNS — a falta dessa autorização é o motivo mais comum de relatórios simplesmente nunca aparecerem.

Lendo o XML: três blocos

Todo relatório agregado tem o mesmo formato. Depois de ver uma vez, deixa de intimidar.

Bloco 1: quem mandou o relatório

<report_metadata> nomeia a organização que reporta e dá um identificador e um intervalo de datas. O intervalo é o que importa notar: os relatórios costumam cobrir 24 horas e chegam um ou dois dias depois, então o IP que você está olhando enviou no passado.

Bloco 2: a política que eles viram

<policy_published> é o seu próprio registro DMARC como aquele provedor o leu: p (a sua política), sp (a de subdomínios), pct (a porcentagem que você pediu para aplicar) e os modos de alinhamento. Este bloco serve de conferência: se não bate com o que você acha que publicou, o seu registro tem problema de sintaxe ou ainda não propagou.

Bloco 3: as linhas que importam

Depois vêm os elementos <record>. Cada um é um grupo de mensagens de um IP com um mesmo resultado, não um e-mail avulso. Cada um traz um <row> com o IP de origem e uma contagem, um <policy_evaluated> com o resultado DMARC e o que o provedor fez, e um <auth_results> com os resultados de SPF e DKIM por baixo.

Lendo uma linha na prática

Siga nesta ordem e a linha se explica sozinha:

1. De quem é o IP? Consulte. Um nome de plataforma de e-mail conhecida significa que é um serviço seu; uma rede desconhecida é a que precisa ser investigada.
2. Quantas mensagens? Duas mensagens é ruído. Vinte mil é um sistema.
3. O que diz <policy_evaluated><disposition>? none, quarantine ou reject — o que o provedor fez.
4. SPF e DKIM passaram, e estavam alinhados? Esse par é o diagnóstico inteiro, e é a próxima seção.

As quatro combinações e o que cada uma significa

O DMARC passa se um dos dois, SPF ou DKIM, passar e estiver alinhado com o domínio From: visível. Daí saem quatro casos:

• SPF passa + DKIM passa. O seu remetente bem configurado. Nada a fazer.
• SPF passa, DKIM falha. Normalmente um serviço enviando de um IP autorizado sem assinar. Ative a assinatura DKIM: SPF sozinho é frágil, porque quebra assim que a mensagem é encaminhada.
• SPF falha, DKIM passa. Quase sempre e-mail encaminhado legítimo: o IP de quem encaminha não está no seu registro SPF, mas a assinatura sobreviveu. O DMARC passa só com DKIM, que é exatamente o projeto funcionando.
• Os dois falham. Ou um remetente seu que nunca foi configurado, ou alguém falsificando o seu domínio. Separar os dois é a próxima seção.

Cuidado com uma armadilha do XML: um resultado pode marcar pass em <auth_results> e ainda assim o DMARC falhar, porque o domínio autenticado não estava alinhado com o domínio From:. Uma plataforma que assina com o próprio domínio produz exatamente isso. Se isso confunde, por que um pass de SPF não é um pass de DMARC explica alinhamento em detalhe.

Separando os seus remetentes de uma falsificação

Os primeiros relatórios de quase todo mundo parecem alarmantes e quase nada ali é ataque. Separe os IPs que falham em três pilhas:

• Seus, mal configurados. Um CRM, um sistema de faturamento, uma ferramenta de tickets, uma plataforma de marketing, um servidor de aplicação. Pistas: o IP resolve para um provedor reconhecível, o volume é estável dia após dia e as mensagens estão sendo entregues. Correção: autorize direito, de preferência com DKIM.
• Encaminhadores. Pouco volume, IPs espalhados, universidades e pequenos provedores de e-mail, SPF falhando enquanto o DKIM passa. Não é problema e não dá para corrigir do seu lado.
• Falsificação de verdade. Redes desconhecidas, muitas vezes em rajadas, frequentemente sem relação com o seu negócio, falhando nas duas verificações. A parte tranquilizadora: com uma política aplicada, esse e-mail já está sendo rejeitado, que é todo o objetivo.

A ordem importa. Identifique a primeira pilha inteira antes de apertar a política, porque a aplicação transforma um remetente seu mal configurado em e-mail que não chega.

Por que encaminhamentos parecem ataques

Isso confunde todo mundo uma vez. Uma lista de e-mails ou um alias retransmite a sua mensagem do próprio servidor, então o seu registro SPF é verificado contra um IP que você nunca autorizou e falha — corretamente. O relatório mostra um IP desconhecido falhando SPF enquanto envia como você, que se lê exatamente como abuso.

Dois sinais separam os casos. E-mail encaminhado normalmente continua passando no DKIM, porque a assinatura viaja com a mensagem, então o DMARC passa no conjunto. E o volume é pequeno e espalhado por muitos IPs sem relação, em vez de concentrado. Listas de e-mail são a exceção que pode quebrar as duas coisas: algumas reescrevem o assunto ou acrescentam um rodapé, o que invalida a assinatura DKIM e deixa uma mensagem legítima falhando tudo.

Usando os relatórios para chegar à aplicação

Os relatórios existem para tornar esse passo seguro. Uma sequência que funciona:

• Fique em p=none até os relatórios ficarem chatos — normalmente algumas semanas. Você está esperando até que todo remetente legítimo encontrado esteja autorizado e nada novo apareça.
• Corrija os remetentes conforme os encontrar, preferindo DKIM. Um remetente com DKIM sobrevive ao encaminhamento; um só com SPF, não.
• Vá para p=quarantine, opcionalmente com pct= para subir aos poucos. O e-mail que falha vai para spam em vez de sumir, então um erro é reversível.
• Depois p=reject, quando a quarentena estiver quieta. É o ponto em que o e-mail que falsifica o seu domínio passa a ser realmente recusado.
• Continue lendo os relatórios depois. Um fornecedor novo contratado daqui a seis meses vai aparecer como um IP falhando, e você quer ver isso antes de alguém dizer que as faturas dele estão voltando.

Não coloque p=reject no primeiro dia. A única coisa que torna a aplicação segura é o inventário que os relatórios dão, e esse inventário leva semanas para ficar completo. O guia de SPF, DKIM e DMARC cobre os registros em si.

Erros comuns

• Pular para p=reject sem ler relatórios. O sistema esquecido costuma ser o que fatura os seus clientes.
• Ler cada linha como uma mensagem. Uma linha é um grupo de mensagens de um IP com um mesmo resultado.
• Tratar todo IP que falha como atacante. A maioria das falhas iniciais são serviços seus e encaminhamento comum.
• Supor que um pass em auth_results significa DMARC passando. Sem alinhamento com o domínio From:, não significa.
• Mandar os relatórios para uma caixa humana. Chegam diariamente de dezenas de provedores. Use um endereço dedicado.
• Esquecer a política de subdomínios. Sem sp=, subdomínios herdam p, o que pode não ser o que você quer durante a implantação.
• Corrigir só SPF. SPF quebra no encaminhamento; é o DKIM que leva o DMARC através dele.
• Desligar os relatórios ao chegar em reject. É justamente quando eles viram um sistema de alerta antecipado.

Versão curta

Um relatório agregado de DMARC é uma lista XML diária de cada IP que envia como o seu domínio, com contagens e resultados de SPF e DKIM — sem conteúdo das mensagens. Leia cada linha em quatro passos: identifique o IP, olhe o volume, leia a disposição, depois verifique se SPF ou DKIM passou e estava alinhado. Espere que a maioria das falhas iniciais sejam serviços seus não configurados e encaminhamento comum, e não falsificação; corrija remetentes com DKIM sempre que puder; e só vá de p=none para quarentena e depois reject quando os relatórios estiverem quietos. Confira que o seu registro _dmarc está publicado e legível com a ferramenta gratuita de consulta DNS, e se um resultado de SPF em um relatório parecer contraditório, o guia de diagnóstico de SPF explica.

Ferramentas e guias relacionados:

• Consulta de DNS — Consulte registros A, AAAA, MX, TXT, NS e mais, com valores e TTL, além de DNS reverso.
• Por que o seu registro SPF continua falhando (e como corrigir) — Como ler seu registro SPF

Perguntas frequentes