DMARC Reports Explained: How to Read and Analyze Aggregate and Forensic Reports

Publishing a DMARC record is only the first step. The real value of DMARC comes from the reports it generates, which give you unprecedented visibility into every server and service sending email using your domain name. Without reading and acting on these reports, your DMARC deployment is incomplete, and you cannot safely move to an enforcing policy.

This guide breaks down both types of DMARC reports, walks through the XML structure field by field, explains what to look for, and shows you how to use report data to fix authentication problems and protect your domain.

The Two Types of DMARC Reports

DMARC reporting is controlled by two tags in your DMARC DNS record: rua (aggregate reports) and ruf (forensic reports). Each serves a different purpose, and most organizations rely primarily on aggregate reports for day-to-day monitoring.

Aggregate Reports (RUA)

Aggregate reports provide a summary of authentication results for all email sent from your domain during a reporting period (usually 24 hours). They are sent by receiving mailbox providers like Gmail, Yahoo, and Microsoft to the email address specified in your rua tag. These reports arrive as compressed XML files attached to email messages.

Aggregate reports tell you:

• Which IP addresses sent email claiming to be from your domain
• How many messages each IP sent
• Whether those messages passed or failed SPF and DKIM authentication
• Whether SPF and DKIM were aligned with the From domain
• What disposition (none, quarantine, reject) was applied

Forensic Reports (RUF)

Forensic reports (also called failure reports) are generated immediately when an individual email fails DMARC authentication. They contain detailed information about the specific failed message, including header data, source IP, and sometimes a redacted copy of the message content.

Setting Up DMARC Reporting

To receive DMARC reports, your DMARC record must include a rua tag (and optionally a ruf tag) pointing to an email address that will accept the reports. Here is an example DMARC record with reporting enabled:

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

Key tags for reporting:

• rua: The email address where aggregate reports should be sent. This is essential.
• ruf: The email address for forensic failure reports. Optional but useful during initial deployment.
• fo: Failure reporting options. Setting fo=1 generates forensic reports when either SPF or DKIM fails (not just when both fail), giving you more complete failure data.
• ri: Reporting interval in seconds. The default is 86400 (24 hours). Most providers send daily reports regardless of this setting.

How to Read a DMARC Aggregate Report

Aggregate reports arrive as gzip-compressed XML files. Once extracted, the XML follows a standard structure defined in RFC 7489. Let us walk through each section.

Report Metadata

The opening section identifies the reporting organization and the time period covered:

<report_metadata>
  <org_name>google.com</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <report_id>7598769364592857643</report_id>
  <date_range>
    <begin>1710288000</begin>
    <end>1710374400</end>
  </date_range>
</report_metadata>

The org_name tells you which mailbox provider generated this report. The date_range uses Unix timestamps to indicate the 24-hour window the report covers.

Published Policy

This section reflects the DMARC policy the reporter observed in your DNS at the time of evaluation:

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

Here, adkim and aspf indicate your alignment mode (r = relaxed, s = strict). The p tag shows your domain policy, and sp shows your subdomain policy.

Record Rows (The Core Data)

Each <record> block 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>1500</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>
      <selector>s1</selector>
    </dkim>
    <spf>
      <domain>bounce.esp.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

This is where the actionable data lives. Let us break down the key fields:

What to Look For in Your Reports

Reading the raw XML is useful for understanding the format, but the real work is interpreting the data across hundreds of reports. Here is what to focus on:

Identify All Legitimate Sending Sources

The first and most important task is building a complete inventory of every service that sends email on behalf of your domain. This includes your primary ESP, transactional email provider, CRM, helpdesk system, marketing automation tools, and any other SaaS platforms that send email using your domain.

Look at each unique source_ip in your reports and determine whether it belongs to an authorized service. Use reverse DNS lookups to map IPs to organizations. Common legitimate sources include:

• Your ESP (SendGrid, Mailgun, Amazon SES, Postmark, etc.)
• Google Workspace or Microsoft 365 servers
• CRM platforms (Salesforce, HubSpot)
• Helpdesk tools (Zendesk, Intercom, Freshdesk)
• Transactional email services

Find Authentication Failures

Any record where dkim and spf both show "fail" in the policy_evaluated section needs investigation. If the source IP belongs to a legitimate service, the failure likely indicates a misconfiguration, such as a missing SPF include, unsigned DKIM, or a domain alignment problem.

Spot Unauthorized Senders

Source IPs that you cannot identify as belonging to any of your authorized services may indicate domain spoofing attempts. Look for high-volume unknown senders, especially those with both SPF and DKIM failures. These are the messages that DMARC enforcement (p=quarantine or p=reject) will block.

Track Alignment Issues

Check whether your legitimate senders achieve alignment. For SPF alignment, the envelope sender (Return-Path) domain must match or be a subdomain of your From domain. For DKIM alignment, the DKIM signature domain (d= value) must match or be a subdomain of your From domain. At least one must align for DMARC to pass.

Understanding Forensic (RUF) Reports

Forensic reports provide details on individual messages that failed DMARC. They are less widely supported than aggregate reports but offer valuable diagnostic information when available.

A forensic report typically includes:

• The full email headers of the failed message
• The source IP address
• The From, To, and Subject fields (sometimes redacted)
• The specific SPF and DKIM results
• The DMARC evaluation result

Forensic reports are most useful for investigating specific authentication failures or suspected spoofing incidents. They let you see exactly which messages failed and why, which is harder to determine from aggregate data alone.

Using Reports to Reach DMARC Enforcement

The primary goal of DMARC report analysis is to prepare your domain for safe enforcement. The journey from p=none to p=reject follows a structured path that depends entirely on your report data.

Phase 1: Monitor (p=none)

Start with p=none and collect reports for at least 2 to 4 weeks. During this phase, your goal is to build a complete sender inventory and identify all authentication gaps. No messages are quarantined or rejected during this phase.

Phase 2: Fix Authentication Gaps

For each legitimate sending source that shows DMARC failures, fix the underlying issue. This usually means adding the service's IP range to your SPF record, configuring custom DKIM signing through the service, or adjusting alignment settings. Verify fixes using a DMARC checker.

Phase 3: Quarantine with Percentage Ramp

Once your reports show that all legitimate senders pass DMARC, move to p=quarantine with a low percentage. Start with pct=10 and gradually increase to 25, 50, 75, and finally 100 over several weeks. Monitor reports at each stage to catch any remaining issues.

Phase 4: Reject

After 2 to 4 weeks at p=quarantine with pct=100 and no legitimate mail being quarantined, you can confidently move to p=reject. Continue monitoring reports regularly, as your email ecosystem will change over time with new tools and services.

Tools for Analyzing DMARC Reports

Manually parsing XML reports is impractical for any domain sending meaningful volume. Use a DMARC report analyzer to aggregate, visualize, and alert on your data.

Look for tools that provide:

• Automatic XML parsing and aggregation across all reporting providers
• Sender source identification with reverse DNS and ASN lookups
• SPF, DKIM, and DMARC pass/fail dashboards
• Trend analysis over time to spot emerging issues
• Alerts when new unauthorized senders appear or failure rates spike
• Guidance for moving toward enforcement

Many providers offer free tiers for low-volume domains, making it accessible to get started with automated report analysis without any upfront investment.

Common Issues Found in DMARC Reports

Third-Party Services Missing from SPF

This is the most frequent issue. A SaaS tool sends email using your domain, but its sending IPs are not included in your SPF record. The fix is adding the appropriate include: mechanism to your SPF record for that service.

Missing DKIM Signatures

Some services send email on your behalf without DKIM signing, or they sign with their own domain instead of yours. Check each service's documentation for custom DKIM configuration options.

Email Forwarding Breaking Authentication

When recipients forward your email (especially through mailing lists or auto-forwarding rules), SPF almost always breaks because the forwarding server's IP is not in your SPF record. DKIM typically survives forwarding if the message body is not modified. ARC (Authenticated Received Chain) helps mailbox providers trust forwarded messages by preserving the original authentication results.

Subdomain Policy Gaps

If your DMARC record does not include an sp= tag, subdomains inherit the parent domain's policy. However, if you have subdomains sending email with different authentication configurations, they may need their own DMARC records. Reports will reveal authentication failures on subdomains that you may not have considered.

Frequently Asked Questions

← Back to Blog