Como ler relatórios agregados do DMARC e migrar para p=reject com segurança

Os relatórios agregados do DMARC são arquivos XML que os provedores de caixa de entrada enviam a você, geralmente uma vez por dia, listando todas as fontes que enviaram e-mails afirmando ser o seu domínio e se passaram no SPF, no DKIM e no alinhamento. Lê-los é como você encontra todos os remetentes legítimos, corrige os que falham e descobre quem está falsificando o seu domínio, para poder migrar de p=none para p=reject sem bloquear e-mails reais.

Resumo rápido

1. Peça os relatórios. Adicione um endereço rua ao seu registro DMARC enquanto a política for p=none.
2. Espere e colete. Reúna de duas a quatro semanas de relatórios, incluindo qualquer envio mensal.
3. Classifique as fontes. Marque cada IP de origem como legítimo e alinhado, legítimo mas com falhas, ou desconhecido.
4. Corrija o que falha. Dê a cada serviço legítimo uma assinatura DKIM ou um Return-Path alinhado.
5. Aplique em etapas. Quarantine com uma porcentagem baixa, aumente e depois migre para reject.

O registro DMARC que solicita relatórios

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Enviando relatórios para outro domínio

Se o endereço rua estiver em um domínio diferente daquele sobre o qual se reporta, esse outro domínio precisa publicar um registro que o autorize. Caso contrário, os provedores não enviarão relatórios. Para relatórios sobre example.com indo para reports.example.net:

example.com._report._dmarc.reports.example.net.  3600  IN  TXT  "v=DMARC1"

O que há dentro de um relatório

Os relatórios chegam como anexo, geralmente compactados em gzip ou zip. Ao abrir um, você encontrará três partes: informações sobre o remetente do relatório, a política que o provedor encontrou e uma lista de linhas, uma para cada combinação de IP de origem e resultado.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>1234567890</report_id>
    <date_range><begin>1759708800</begin><end>1759795199</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain><adkim>r</adkim><aspf>r</aspf><p>none</p><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>1250</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>mail1</selector><result>pass</result></dkim>
      <spf><domain>bounce.example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Classifique cada fonte em um de três grupos

Como identificar uma fonte

• DNS reverso: dig -x 203.0.113.10 +short costuma indicar o nome do provedor.
• Domínios de autenticação: os domínios de SPF e DKIM em auth_results geralmente revelam o serviço.
• Seu próprio inventário: liste todas as ferramentas que enviam em nome do seu domínio: plataforma de marketing, helpdesk, CRM, sistema de cobrança, formulários do site, ferramentas de RH e servidores.
• Volume e padrão: uma contagem pequena e constante de um serviço conhecido é normal; um pico repentino de um IP desconhecido é suspeito.

Resuma os relatórios com um script curto

Para uma primeira visão de uma pasta de relatórios descompactados, este script totaliza as mensagens por IP de origem e resultado do DMARC:

import glob
import xml.etree.ElementTree as ET
from collections import defaultdict

totals = defaultdict(int)
for path in glob.glob("reports/*.xml"):
    for rec in ET.parse(path).getroot().iter("record"):
        row = rec.find("row")
        ip = row.findtext("source_ip")
        ev = row.find("policy_evaluated")
        key = (ip, ev.findtext("dkim"), ev.findtext("spf"))
        totals[key] += int(row.findtext("count"))

for (ip, dkim, spf), n in sorted(totals.items(), key=lambda x: -x[1]):
    print(f"{ip:18} dkim={dkim:5} spf={spf:5} messages={n}")

Corrigindo falhas de alinhamento

Avance para a aplicação da política em etapas

Quando as fontes legítimas estiverem alinhadas e apenas fontes desconhecidas falharem, aumente a política gradualmente. Espere pelo menos uma semana em cada etapa e leia os relatórios antes de avançar.

Continue monitorando depois do p=reject

• Revise semanalmente no início e depois mensalmente. Novas ferramentas que enviam em nome do seu domínio aparecerão como falhas.
• Adicione uma etapa ao onboarding: qualquer novo sistema que envie e-mails em nome do seu domínio é autenticado antes de entrar em produção.
• Proteja domínios estacionados: publique p=reject e um registro SPF vazio nos domínios dos quais você não envia.
• Fique atento à prontidão para o BIMI: uma política DMARC aplicada é pré-requisito se, mais tarde, você quiser que o seu logotipo apareça na caixa de entrada.

Leitura complementar e fontes

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• dmarc.org: Visão geral do DMARC
• Google: Configurar o DMARC
• RFC 8617: The Authenticated Received Chain (ARC)
• Guias relacionados: Autentique um domínio de envio e Requisitos para remetentes em massa.