Understanding DMARC Reports: How to Read and Use Them

DMARC reports are one of the most valuable features of DMARC, but they're also one of the most underused. These reports show you exactly who's sending email as your domain and whether those emails are passing authentication. Without them, you're flying blind.

Here's how to set up, receive, and actually use DMARC reports.

What DMARC Reports Are

When you publish a DMARC record with a reporting address, email providers that receive email claiming to be from your domain will send you reports about what they saw. These reports tell you:

• How many emails they received from your domain
• Which IP addresses sent those emails
• Whether the emails passed or failed SPF and DKIM
• What action they took based on your policy

There are two types of DMARC reports:

Aggregate reports (RUA): Summarized data about email traffic, typically sent daily. These give you the big picture of who's sending email as your domain.

Forensic reports (RUF): Detailed information about individual emails that failed authentication. These help you diagnose specific problems but are sent less frequently due to privacy concerns.

How to Receive DMARC Reports

To receive reports, you need to add reporting addresses to your DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com

rua (Reporting URI for Aggregate reports): Where aggregate reports should be sent. This is the most important one.

ruf (Reporting URI for Forensic reports): Where forensic reports should be sent. Many providers don't send these due to privacy policies.

A few important notes:

• Use a dedicated email address for reports (not your personal inbox)
• The email address can be at any domain, but if it's a different domain than your DMARC record, you'll need to set up external report verification
• Reports come as XML attachments, often compressed

Aggregate Reports Explained

Aggregate reports are XML files that summarize email traffic over a period (usually 24 hours). They're sent by email providers like Google, Microsoft, Yahoo, and others who receive email claiming to be from your domain.

What's in an Aggregate Report

Each report contains:

Report metadata: Who sent the report, what time period it covers, and your DMARC policy at the time.

Policy published: Your DMARC record as the reporter saw it.

Records: Individual entries for each source IP address, showing:

• The sending IP address
• How many messages came from that IP
• SPF result (pass, fail, none)
• DKIM result (pass, fail, none)
• DMARC result (pass or fail)
• What disposition was applied (none, quarantine, reject)

Reading Raw Aggregate Reports

Here's a simplified example of what the data looks like:

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>150</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

This tells you that 150 emails came from IP 192.0.2.1, both DKIM and SPF passed, and no action was taken (because of your policy or because it passed).

What to Look For

When reviewing aggregate reports, focus on:

Failing legitimate sources: Look for IP addresses you recognize (your email provider, marketing tools, etc.) that are showing failures. These need attention.

Unknown sources with high volume: IPs you don't recognize sending lots of email could be spoofing attempts, or they could be legitimate services you forgot about.

Alignment failures: Emails might pass SPF or DKIM individually but still fail DMARC due to alignment issues. The report shows this.

Forensic Reports Explained

Forensic reports (also called failure reports) provide details about individual emails that failed DMARC. They can include:

• Headers of the failing message
• The actual content (sometimes redacted)
• Specific failure reasons

However, many email providers don't send forensic reports due to privacy concerns. Google, for example, doesn't send them at all. Don't rely on forensic reports as your primary data source.

If you want to request forensic reports, you can adjust what triggers them using the fo tag:

• fo=0 - Generate report if all mechanisms fail (default)
• fo=1 - Generate report if any mechanism fails
• fo=d - Generate report if DKIM fails
• fo=s - Generate report if SPF fails

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1

Interpreting Your Reports

Here's how to make sense of what you're seeing:

Identify Your Legitimate Senders

First, map the IP addresses in your reports to known services:

• Your company's mail server
• Google Workspace or Microsoft 365
• Email marketing platforms (Mailchimp, SendGrid, etc.)
• CRM systems (Salesforce, HubSpot, etc.)
• Support and ticketing systems
• Custom applications

Cross-reference IPs with your SPF record. If an IP appears in your reports but isn't in your SPF record, either add it (if legitimate) or investigate (if unknown).

Diagnose Failures

When legitimate email is failing, determine why:

SPF failing, DKIM passing: The sending IP isn't in your SPF record. Add it, or ensure the service is configured to use an authorized IP.

DKIM failing, SPF passing: DKIM isn't set up for that service, or the signature is broken. Verify DKIM configuration with DKIM Test.

Both failing: The service isn't properly configured at all. You'll need to set up both SPF and DKIM for this sender.

Alignment failure: SPF or DKIM passes, but the domain doesn't match the From address. This is a configuration issue with the sending service.

Spot Spoofing Attempts

Unknown IP addresses with high failure rates are often spoofing attempts. If you see:

• IPs you don't recognize
• High volume from those IPs
• Complete SPF and DKIM failures

That's likely someone trying to send fake email as your domain. This is exactly what DMARC is designed to stop, and why moving to p=quarantine or p=reject matters.

Tools for Analyzing Reports

Reading raw XML reports is tedious. Several approaches can help:

DMARC report processors: Services that receive your reports, parse them, and show you dashboards and summaries. Many are free for low-volume domains.

Spreadsheet conversion: Some tools convert DMARC XML to CSV for analysis in Excel or Google Sheets.

Email client rules: Set up filters to organize incoming reports by sender, making them easier to review.

If you're serious about DMARC, a processing service is worth considering. The raw XML quickly becomes unmanageable for active domains.

Building Your Report Workflow

A practical workflow for DMARC reports:

1. Set up reporting: Add rua=mailto: to your DMARC record
2. Wait for data: Give it a week or two to collect reports
3. Review weekly: Check reports regularly, not just once
4. Investigate unknowns: Research any IP addresses you don't recognize
5. Fix failures: Address authentication issues for legitimate senders
6. Adjust policy: Once failures are resolved, move toward enforcement

Reports are most valuable when you actually use them. Build a habit of reviewing them regularly, especially while on p=none or transitioning to enforcement.

Monitor Your DMARC Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.