How to Read DMARC Reports

You published your DMARC record with a rua tag, and now XML files are arriving in your inbox. They have names like google.com!yourdomain.com!1706140800!1706227200.xml.gz and they look incomprehensible when you open them. That is normal. DMARC reports are designed for machines to produce and humans to interpret — with a little guidance.

This guide explains what DMARC reports are, the difference between aggregate and forensic reports, what each field in the XML means, and most importantly, what you should do with the information.

The Two Types of DMARC Reports

DMARC defines two reporting mechanisms, controlled by different tags in your DMARC record.

Aggregate Reports (rua)

Aggregate reports are the ones you will see most often. They are sent by receiving mail servers (Gmail, Yahoo, Microsoft, and others) on a daily basis. Each report covers a 24-hour period and summarizes how all emails claiming to be from your domain were handled.

You receive aggregate reports when your DMARC record includes the rua tag:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;

These reports are XML files, usually compressed as .zip or .gz. They do not contain the content of any email. They contain statistics: how many messages came from each IP address, whether those messages passed or failed SPF and DKIM, and what disposition the receiving server applied.

Forensic Reports (ruf)

Forensic reports (also called failure reports) provide details about individual messages that failed DMARC. They include more specific information like the email headers, the From address, and the authentication results for that particular message.

You receive forensic reports when your DMARC record includes the ruf tag:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1;

Many large mailbox providers — including Gmail — do not send forensic reports due to privacy concerns. You will receive them from some providers, but do not rely on them as your primary data source. Aggregate reports are your main tool for DMARC analysis.

Inside an Aggregate Report

When you decompress and open an aggregate report XML file, you will see several sections. Here is what each one means.

Report Metadata

The top of the report identifies who sent it and what period it covers:

<report_metadata>
  <org_name>google.com</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <report_id>12345678901234567890</report_id>
  <date_range>
    <begin>1706140800</begin>
    <end>1706227200</end>
  </date_range>
</report_metadata>

The org_name tells you which mail provider generated the report. The date_range uses Unix timestamps — you can convert these to human-readable dates with any online converter. Each report covers exactly one reporting period, typically 24 hours.

Policy Published

This section mirrors your DMARC record as the receiving server saw it:

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

If these values do not match what you think your DMARC record says, you may have a DNS issue or a stale cached record. This is a useful sanity check.

Record Rows — The Important Part

The bulk of the report is a series of <record> entries. Each record represents a group of messages from a specific source IP with the same authentication results:

<record>
  <row>
    <source_ip>198.51.100.25</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.emailprovider.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Here is what each field tells you:

source_ip — The IP address that sent the messages. You can look this up to identify the sending service (e.g., Google, SendGrid, Mailchimp).
count — How many messages this row represents. A high count from an unrecognized IP is a red flag.
disposition — What the receiving server did: none (delivered), quarantine (sent to spam), or reject (blocked).
dkim and spf under policy_evaluated — Whether DKIM and SPF passed DMARC alignment, not just whether they passed at all.
auth_results — The raw SPF and DKIM results. Notice the SPF domain might be different from your domain. That is an alignment issue — SPF passed for the sending service's domain, but it did not align with your From domain.

How to Interpret Your Reports

Reading the XML is one thing. Knowing what to do with it is another. Here is a practical approach.

Identify every source IP

Go through each record row and look up the source IP addresses. Use a reverse DNS lookup or an IP reputation tool to figure out which service or server each one belongs to. You are building a list of everything that sends email as your domain.

Classify each sender

For each source IP, decide whether it is legitimate or unauthorized. Legitimate senders include your email marketing platform, CRM, transactional email service, helpdesk, invoicing tool, and your own mail server. Anything you do not recognize is suspicious.

Check authentication results

For each legitimate sender, check whether DKIM and SPF are passing with proper alignment. If a legitimate sender is failing, you need to fix their authentication — either by updating your SPF record, configuring DKIM signing, or both.

Assess unauthorized senders

If you see messages from IP addresses you do not recognize, check the volume and frequency. A small number of failures from unknown IPs is normal — some amount of spam will always attempt to use your domain. Large volumes from unknown sources may indicate an active spoofing campaign, which is exactly what DMARC enforcement protects against.

Decide your next action

If all your legitimate senders are passing DMARC, you are ready to move from p=none to p=quarantine. See our quarantine vs reject comparison to understand what each enforcement level means for failing messages. If some are still failing, fix the authentication issues first. Our DMARC failure troubleshooting guide covers the most common fixes.

Making Reports Easier to Read

Raw XML reports are tedious to work through manually, especially if you receive reports from dozens of mailbox providers. There are a few approaches to make this manageable.

Use a DMARC report analyzer. Services that parse your XML reports into human-readable dashboards are the most practical option. They aggregate data across all reports, show you trends over time, and highlight failures that need attention. Agencies managing client domains especially benefit from centralized report analysis across multiple accounts.

Set up a dedicated mailbox. Do not send DMARC reports to your personal inbox. Create a dedicated address like dmarc-reports@yourdomain.com so the reports do not clutter your daily email. If you use a report analyzer, point your rua tag at the address they provide.

Review weekly, not daily. Unless you are actively rolling out a policy change, checking your DMARC reports once a week is usually sufficient. Look for new senders, changes in authentication results, and any spikes in failure volume.

Set fo=1 for better data

The default failure reporting option (fo=0) only generates reports when both SPF and DKIM fail. Setting fo=1 generates reports when either one fails, giving you more visibility into partial failures. This is especially useful during the monitoring phase.

What to Watch For

Legitimate senders failing alignment. This is the most actionable finding. If your marketing platform passes DKIM but the signing domain is theirs instead of yours, DMARC alignment fails. Configure custom DKIM to fix it.

Unknown IPs with high volume. This suggests someone is actively spoofing your domain. If you are still at p=none, this is strong motivation to move toward enforcement.

Sudden changes in report data. If a sender that was passing suddenly starts failing, something changed — an expired DKIM key, an SPF record update that removed an authorized IP, or a configuration change at the sending service. Developer teams can set up automated alerts on report data to catch these regressions early.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.

Never miss a DMARC issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring

How to Read DMARC Reports: A Complete Guide to Aggregate and Forensic Reports