DMARC Aggregate Report XML Fields Explained (No Tool Needed)

The first DMARC report lands in your mailbox as a zipped XML attachment with a file name like google.com!yourdomain.com!1720051200!1720137599.xml.gz, and it looks unreadable. It is not. A report has three parts, and once you know which five fields matter you can triage one in a couple of minutes without paying for a dashboard. This guide walks through a real report structure line by line.

Quick answer

An aggregate report lists, per sending IP, how many messages used your domain during a 24-hour window and whether they passed SPF and DKIM with alignment. Look at source_ip, count, the policy_evaluated block, and the auth_results block. A row with count in the hundreds, both checks failing, and an IP you do not recognise is spoofing. A row with a service you use and a failure is a configuration job.

Opening the file

1. Save the attachment. It is either .zip or .gz; both are standard archives.
2. On Windows, right-click a .zip and choose Extract All. For .gz use 7-Zip. On macOS, double-click either. On Linux, run gunzip on the file.
3. Open the resulting .xml in any browser or text editor. Browsers indent it into a readable tree.
4. The file name tells you the reporter (google.com), your domain, and the report window as two Unix timestamps.

Part one: report_metadata

This block identifies who sent the report and when. org_name is the receiver (google.com, Yahoo, Outlook.com, or a smaller provider). report_id is unique per report. date_range holds begin and end as Unix timestamps; convert them at any epoch converter if you need the exact hours. Nothing here needs action.

Part two: policy_published

This echoes the DMARC record the receiver saw when it evaluated your mail. Check it matches what you think you published. If you moved to p=quarantine yesterday and this still says p=none, DNS had not propagated when the report window began, which is normal for the first report after a change.

<policy_published>
  <domain>yourdomain.com</domain>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <p>none</p>
  <sp>none</sp>
  <pct>100</pct>
</policy_published>

Part three: one record block per sending source

This is where the information is. Each record block covers one source IP. A small business typically sees between one and ten record blocks per report. Here is one from a message sent through OquMail, annotated:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>   <!-- the server that delivered the mail -->
    <count>42</count>                     <!-- messages from that IP in the window -->
    <policy_evaluated>
      <disposition>none</disposition>     <!-- what the receiver did: none, quarantine, reject -->
      <dkim>pass</dkim>                   <!-- DKIM aligned with the From domain? -->
      <spf>pass</spf>                     <!-- SPF aligned with the From domain? -->
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>yourdomain.com</domain>     <!-- domain in the DKIM signature -->
      <selector>sel2026</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>yourdomain.com</domain>     <!-- envelope (Return-Path) domain -->
      <result>pass</result>
    </spf>
  </auth_results>
</record>

The five fields to read, in order

1. source_ip. Look it up with a reverse DNS or WHOIS check. Does it belong to your mail host, a tool you use, or nobody you know?
2. count. One or two messages from an unknown IP is often a forwarded email. Hundreds is a campaign.
3. policy_evaluated DKIM (a digital signature that proves your email was not tampered with) and SPF (Sender Policy Framework — a list of servers allowed to send email as your domain). These are the aligned results, the ones DMARC actually uses. Both fail means the message failed DMARC.
4. auth_results dkim domain. If DKIM passed but the domain here is your newsletter tool's domain rather than yours, that is an alignment failure, fixable by enabling custom-domain DKIM in the tool.
5. auth_results spf domain. If this shows a bounce domain owned by the tool rather than yourdomain.com, SPF cannot align even when it passes; DKIM alignment must carry that sender.

Reading the three common patterns

• Both pass, known IP: healthy. This is what mail sent through mail.oqumail.com should look like.
• DKIM pass with your domain, SPF fail, low count, IP belongs to a university or a company: a recipient forwarded your message. DMARC still passes because DKIM aligned. No action.
• Both fail, unknown IP, high count: someone is sending as your domain. If your policy is still p=none the disposition will say none, meaning receivers delivered it. This is the evidence for moving to quarantine and then reject.

When a tool is worth it

Hand-reading works for a few reports a day. Once you have several domains, or dozens of record blocks per report, a free or paid DMARC aggregator that graphs sources over time saves hours. Until then, an inbox rule that files reports into a folder, plus ten minutes a week, is enough. OquMail gives you the rua mailbox for free and shows outbound delivery per message in its logs, so you can cross-check that a report row matches something you actually sent.

Common questions

Why do I get reports from receivers I have never emailed?

Because someone else emailed them using your domain, or a message you sent was forwarded there. Either way the report tells you something true about your domain's footprint.

Why do counts not match my sent folder?

Reports are per receiver and per day, counted at delivery attempt. Bounces, retries, and mail to providers that do not send reports all create differences. Look for patterns, not exact totals.

Is there personal data in aggregate reports?

No. Aggregate reports contain IPs, counts, and domains, never recipient addresses or message content. Forensic (ruf) reports can contain headers, which is one reason most small businesses do not request them.