How to Read DMARC Aggregate Reports and Safely Move to p=reject

DMARC aggregate reports are XML files that mailbox providers send you, usually once a day, listing every source that sent mail claiming to be your domain and whether it passed SPF, DKIM and alignment. Reading them is how you find every legitimate sender, fix the ones that fail and discover who is spoofing you, so you can move from p=none to p=reject without blocking real mail.

The short version

1. Ask for reports. Add a rua address to your DMARC record while the policy is p=none.
2. Wait and collect. Gather two to four weeks of reports, including any monthly sending.
3. Sort the sources. Mark each source IP as legitimate and aligned, legitimate but failing, or unknown.
4. Fix what fails. Give each legitimate service an aligned DKIM signature or Return-Path.
5. Enforce in steps. Quarantine at a low percentage, raise it, then move to reject.

The DMARC record that requests reports

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

Sending reports to another domain

If the rua address is on a different domain from the one being reported, that other domain must publish a record that allows it. Otherwise providers will not send reports. For reports about example.com going to reports.example.net:

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

What is inside a report

Reports arrive as an attachment, usually gzip or zip compressed. Open one and you will find three parts: information about the sender of the report, the policy the provider found, and a list of rows, one per source IP and result combination.

<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>

Sort every source into one of three groups

How to identify a source

• Reverse DNS: dig -x 203.0.113.10 +short often names the provider.
• Authentication domains: the SPF and DKIM domains in auth_results usually reveal the service.
• Your own inventory: list every tool that sends as your domain: marketing platform, helpdesk, CRM, billing system, website forms, HR tools and servers.
• Volume and pattern: a small, steady count from a known service is normal; a sudden burst from an unknown IP is suspicious.

Summarise reports with a short script

For a first look at a folder of unzipped reports, this script totals messages by source IP and DMARC result:

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}")

Fixing alignment failures

Move to enforcement in steps

Once the legitimate sources are aligned and only unknown sources fail, raise the policy gradually. Wait at least a week at each step and read the reports before moving on.

Keep monitoring after p=reject

• Review weekly at first, then monthly. New tools that send as your domain will show up as failures.
• Add a step to onboarding: any new system that sends email as your domain gets authenticated before it goes live.
• Protect parked domains: publish p=reject and an empty SPF record on domains you do not send from.
• Watch for BIMI readiness: an enforced DMARC policy is a prerequisite if you later want your logo to appear in the inbox.

Further reading and sources

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• dmarc.org: DMARC overview
• Google: Set up DMARC
• RFC 8617: The Authenticated Received Chain (ARC)
• Related guides: Authenticate a sending domain and Bulk sender requirements.