DMARC XML Report Fields Explained — Complete Field Reference

You downloaded a DMARC aggregate report and opened the XML. What you saw probably looked like this: hundreds of nested elements with names like policy_evaluated, auth_results, and disposition. This reference decodes every field, one by one, in plain English.

Top-level structure

Every DMARC XML file has exactly one root element: feedback. Inside it you will always find two metadata sections followed by one or more record elements.

<feedback>
  <report_metadata>…</report_metadata>
  <policy_published>…</policy_published>
  <record>…</record>
  <record>…</record>
</feedback>

The number of record elements equals the number of unique combinations of source IP, authentication result, and policy outcome observed during the reporting period. A single report from Google can have thousands of records.

report_metadata fields

The report_metadata block identifies who sent the report and when.

policy_published fields

The policy_published block records the DMARC policy that was in your DNS at the time the messages were received. This is a snapshot of your policy as the receiving server saw it — not your current policy.

record — the core data

Each record represents a unique sending scenario observed during the reporting period. If Google saw 12 different IP addresses sending mail from your domain, there will be 12 or more records (potentially more if the same IP had different auth results).

row fields

policy_evaluated fields

This is what DMARC decided, based on your policy and the authentication results.

auth_results fields

The auth_results section gives you the raw authentication results, separate from alignment. This is where you diagnose why alignment failed.

Reading a complete record: annotated example

<record>
  <row>
    <source_ip>198.2.128.150</source_ip>     <!-- Mailchimp relay IP -->
    <count>12847</count>                      <!-- 12,847 messages -->
    <policy_evaluated>
      <disposition>none</disposition>         <!-- p=none, so no action -->
      <dkim>pass</dkim>                       <!-- DKIM aligned ✓ -->
      <spf>fail</spf>                         <!-- SPF not aligned ✗ -->
    </policy_evaluated>
  </row>
  <auth_results>
    <dkim>
      <domain>example.com</domain>            <!-- matches From: domain -->
      <selector>mc1</selector>
      <result>pass</result>                   <!-- signature valid -->
    </dkim>
    <spf>
      <domain>mcsv.net</domain>               <!-- Mailchimp envelope domain -->
      <result>pass</result>                   <!-- SPF passes for mcsv.net -->
    </spf>                                    <!-- but mcsv.net ≠ example.com -->
  </auth_results>
</record>

This record passes DMARC (because DKIM is aligned and passing) even though SPF alignment fails. The message is from Mailchimp, which signs with your domain via DKIM but sends using its own envelope domain.

Common field combinations and what they mean

Diagnosing failures: what to look for

1. High count DMARC failures from unknown IPs — Check the source IP against known ESP ranges. If it does not belong to any service you use, it is likely spoofing or phishing.
2. DKIM fail with auth_results showing pass — The DKIM signature verified, but the signing domain (dkim/domain in auth_results) does not align with your From: domain. Fix: configure your ESP to sign with your domain instead of its own.
3. SPF fail with auth_results showing pass — SPF verified for the envelope domain, but that domain does not align with your From: domain. Fix: either add the sending IP to your own SPF record or configure DKIM alignment instead.
4. disposition = quarantine or reject despite p=none — The receiving server applied a local policy override. This is rare but indicates the server ignores your published p=none in certain conditions.

Frequently asked questions

What does the source_ip field mean in a DMARC report?

The source_ip field contains the IP address of the mail server that actually delivered the message to the receiving provider. This is the outbound SMTP server — a Google Workspace relay, a Mailchimp IP, your office mail server, or a spoofing server. Identifying and cross-referencing these IPs is the core task in DMARC report analysis.

What is the difference between disposition and policy_evaluated?

policy_evaluated/disposition is what DMARC calculated should happen based on your policy and the authentication result. The actual disposition is what the receiving server did. These differ when a server applies a local override — for example, a mailbox provider might refuse to reject mail even when your policy says p=reject if the message passed a reputation check.

Why does count matter?

Count lets you prioritize. A failure with count=1 is background noise. A failure with count=500,000 means half a million of your emails are failing DMARC and potentially being rejected. Always sort your records by count descending before investigating.

Every field in the DMARC XML format serves a specific diagnostic purpose. The fastest way to analyze them without manually reading XML is to upload your report to DMARC Labs — your file is processed entirely in your browser, never sent to a server.