How to read a DMARC aggregate report, line by line

Identifying unknown source IPs#

For each IP you do not recognize:

dig +short -x 198.51.100.25
whois 198.51.100.25 | grep -iE 'orgname|netname|descr' | head

The PTR record and the IP's registered owner usually reveal the sender: a known email platform, a cloud provider (often a misconfigured app server), or a residential network (often spoofing via compromised machines).

A quick way to summarize a report#

A few lines of Python turn the XML into something readable. Reports come from outside your organization, so parse them with defusedxml rather than the standard library parser, which is not hardened against malicious XML:

import gzip, sys
from defusedxml import ElementTree as ET

root = ET.parse(gzip.open(sys.argv[1])).getroot()
print(root.findtext("report_metadata/org_name"))
for r in root.iter("record"):
    row = r.find("row")
    pe = row.find("policy_evaluated")
    dk = r.find("auth_results/dkim")
    print(f'{row.findtext("source_ip"):16} {row.findtext("count"):>6} '
          f'dkim={pe.findtext("dkim"):4} spf={pe.findtext("spf"):4} '
          f'd={dk.findtext("domain") if dk is not None else "-"}')

Once you have done this a few times, a commercial or open source report processor becomes an efficiency tool rather than a black box.

A routine for reviewing reports#

Reading reports is most useful as a habit rather than an emergency activity. A light weekly routine works well for most organizations:

1. Check total volume per source. Compare the week's message counts for each known sender with what you expect. A transactional provider whose count drops to zero may have broken authentication or lost its configuration.
2. List new source IPs. Any IP that appears for the first time deserves a lookup. Most turn out to be forwarders or new infrastructure at a known vendor; a few are new tools someone adopted without telling you.
3. Review failing rows by size. Sort failures by count. Large failing counts from a single legitimate-looking source usually mean a vendor needs custom DKIM. Large failing counts from residential or cloud ranges usually mean spoofing.
4. Confirm the published policy. Make sure the policy_published section matches your current record at every receiver.
5. Note changes. Keep a short log of what you found and fixed, so the next person reviewing has context.

During a DMARC rollout, do this more often, ideally every few days, because each fix you make should be visible in the next reports.

When reports disagree#

Different receivers sometimes report different results for the same source. One may show DKIM passing while another shows it failing. That usually reflects a real difference in the path, such as one receiver getting mail through a forwarder, or a difference in how each receiver handles an edge case like a long DKIM record. Treat a disagreement as a clue about where to look, not as an error in the report.

What reports cannot tell you#

• Content. Aggregate reports contain no subjects, bodies or recipient addresses.
• Everything. Not every receiver sends reports, and volumes are what each receiver chose to count.
• Real-time events. Reports cover a 24-hour period and arrive after it ends.
• Delivery outcome. A DMARC pass does not mean inbox placement; filtering happens separately.

Key takeaways#

• An aggregate report has three parts: metadata, the policy the receiver saw, and records grouped by source IP and result.
• policy_evaluated shows aligned results; auth_results shows raw results. The difference explains most confusion.
• The source IP is your key to identifying each sender.
• Common patterns map to vendors needing DKIM setup, forwarding, lists, spoofing and possible replay.
• Read a few reports by hand so you can sanity-check any dashboard you use.