How to Read a DMARC Aggregate Report: A Beginner’s Guide

A DMARC aggregate report summarizes how a receiving provider evaluated messages that claimed to use your domain during a reporting period. The XML format can look technical, but most small businesses need to answer only a few questions: who sent mail, was that source expected, did SPF or DKIM align, and does anything require action before the next policy change?

Start with the report’s scope

Look for the reporting organization, date range, domain, and published policy. The report describes what one receiving provider observed during a time window; it is not a complete global record of every message your domain sent. Compare several reports over time before making a broad conclusion.

Find the source and message count

Each record usually includes a source IP and message count. Treat the IP as a lead, not a verdict. A source could belong to your mailbox provider, CRM, marketing platform, helpdesk, agency, or an unauthorized sender. Compare it with the sender inventory and use provider documentation or account owners to verify it.

Read the policy evaluation

The policy section indicates whether SPF and DKIM aligned and how the receiving provider applied your DMARC policy. A pass usually means SPF or DKIM succeeded with a domain aligned to the visible From address. A technical SPF or DKIM pass can still fail DMARC if it used an unrelated identity. See what a DMARC report is for the context.

Understand identifiers

Reports often show the visible header-from domain, an SPF envelope-from domain, and a DKIM signing domain. Compare each with your expected setup. The visible domain is the brand recipients see; aligned SPF or DKIM must be appropriately related to it. Record an unexpected domain rather than assuming it is harmless.

Walk through an actual XML record

This illustrative <record> belongs inside a report’s <feedback> element; it is a fragment, not a complete report:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>25</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</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>mailer.example.net</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

1. row: groups 25 messages seen from the documentation-only source IP 192.0.2.10.
2. policy_evaluated: reports DMARC-aligned DKIM pass and SPF fail, plus the receiver’s disposition. none here is the applied disposition; it is not necessarily the published p=none policy.
3. identifiers: supplies the visible From domain, example.com, used for alignment.
4. auth_results: contains raw authentication results before DMARC alignment. SPF passed for mailer.example.net but that identity is unrelated to example.com, so aligned SPF failed. DKIM passed with an aligned domain, so these messages pass DMARC.

At report level, report_metadata identifies the reporter and time window, while policy_published records the DNS policy the reporter saw. Compare those with each record before deciding to change DNS. The schema is documented in RFC 7489, Appendix C.

Classify each source

Use simple categories: known and aligned, known but misaligned, unknown and needs investigation, retired, or clearly unauthorized. Add a business owner and evidence for every decision. A source that sends only occasional invoices or support notices can be easy to miss, so do not move to reject enforcement until critical exceptions have been checked.

What to do with a failure

First confirm whether the source is legitimate. If it is, configure SPF or DKIM correctly, enable DKIM where possible, and test a fresh message. If it is retired, remove its authorization when safe. If it is unknown, investigate before authorizing it. Do not weaken all DMARC enforcement because one sender has not been understood yet.

Use trends, not one report

Repeated volume from a new source, a sudden alignment failure after a vendor change, or a rising failure rate deserves attention. A single small failure may be a forwarder or transient issue. Keep reports, sender inventory, change dates, and test headers together so you can compare before and after a remediation.

Know when to use a reporting tool

Manual XML review is practical for an occasional learning exercise, but multiple domains or clients benefit from a reporting service that labels sources, retains history, and routes alerts. The tool should still support a human decision process. Review DMARC monitoring tools when choosing that workflow.

Safe policy progression

Aggregate reports support the path from monitoring to quarantine and reject. They do not automatically authorize a strict policy. Use the DMARC implementation checklist to sequence sender inventory, testing, alignment fixes, and gradual enforcement.

Run Beacon’s free domain check to validate the public SPF, DKIM, and DMARC record before interpreting report results.