DMARC Reporting: Analyzing Aggregate and Forensic Reports

What DMARC Reports Tell You

DMARC (Domain-based Message Authentication, Reporting, and Conformance) does two things: it tells receiving mail servers what to do with unauthenticated email from your domain, and it tells *you* what is happening to your outbound mail. The second part — the reporting — is what most senders overlook, and it is where the real value lies.

Without DMARC reports, you are flying blind. You cannot see which servers are sending mail as your domain, whether SPF and DKIM are passing, or whether recipients are quarantining your legitimate mail. DMARC reports close that gap.

DMARC Report Types

DMARC defines two report types, specified in your DMARC TXT record:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Aggregate Reports (rua)

Aggregate reports are XML files sent daily by receiving mail servers (Google, Microsoft, Yahoo, etc.). Each report covers a 24-hour window and contains:

• Source IP addresses sending mail claiming to be from your domain
• SPF and DKIM alignment results for each source IP
• Disposition — what the receiver did (none, quarantine, reject)
• Message counts per source IP

These are the reports you should focus on first. They give you a complete picture of your sending ecosystem without containing actual message content.

Forensic Reports (ruf)

Forensic reports (also called failure reports) are sent per-message whenever a DMARC check fails. They are formatted as Abuse Reporting Format (ARF) messages and may include headers from the failing email, or even the full message body.

Important caveats with ruf:

• Most major ISPs (Gmail, Microsoft) no longer send ruf reports due to privacy concerns
• Yahoo and some smaller ISPs still send them
• The fo= tag controls when forensic reports are generated:

- fo=0 — only when both SPF and DKIM fail (default)

- fo=1 — when either SPF or DKIM fails (recommended for debugging)

- fo=d — only when DKIM fails

- fo=s — only when SPF fails

Reading Aggregate Report XML

Aggregate reports are gzipped XML files attached to email. Here is a representative example:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>[email protected]</email>
    <report_id>17689345678901234567</report_id>
    <date_range>
      <begin>1708819200</begin>  <!-- 2024-02-25 00:00:00 UTC -->
      <end>1708905600</end>      <!-- 2024-02-26 00:00:00 UTC -->
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>
      <count>1247</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>
      <count>3</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

Key fields to examine:

The distinction between auth_results and policy_evaluated is critical: a message can pass SPF authentication but still fail DMARC SPF alignment if the authenticated domain does not match the From: header domain.

Analysis Tools

Parsing DMARC XML by hand is tedious. Use purpose-built tools:

SaaS Platforms

• dmarcian — industry standard, free tier for small volumes, excellent visualization
• Postmark DMARC (free) — simple weekly digest, good for getting started
• Valimail — enterprise-focused, auto-remediation suggestions
• EasyDMARC — competitive free tier, includes reputation monitoring

Google Postmaster Tools

Google Postmaster Tools (postmaster.google.com) shows domain and IP reputation, spam rate, delivery errors, and authentication rates specifically for Gmail. Register your domain there regardless of which DMARC tool you use — it provides data that aggregate reports do not.

Open-Source Parsers

# parsedmarc — Python CLI and IMAP monitor
pip install parsedmarc
parsedmarc report.xml.gz --json

# dmarc-report-parser (Go)
go install github.com/tierpod/dmarc-report-parser@latest
dmarc-report-parser -f report.xml

Policy Tightening Workflow

The standard path from no DMARC to full enforcement takes 4–8 weeks of monitoring:

Phase 1: p=none (Monitoring Only)

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

No mail is rejected. Collect reports for at least 2 weeks. Use this phase to:

• Identify all legitimate sending sources (ESP, CRM, ticketing system, etc.)
• Verify each source passes SPF and DKIM with proper alignment
• Spot unauthorized senders

Phase 2: p=quarantine pct=10 (Partial Enforcement)

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"

The pct=10 parameter applies the quarantine policy to only 10% of failing messages. Monitor for legitimate mail hitting spam folders. Ramp up: pct=25 → pct=50 → pct=100 as confidence grows.

Phase 3: p=reject (Full Enforcement)

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Unauthenticated mail is outright rejected. This is the goal — it completely prevents domain spoofing. Never jump here without going through p=none first.

Common Issues

Third-Party Senders Failing Alignment

The most common problem: a CRM or marketing platform sends as [email protected] but uses its own envelope sender, causing SPF to fail alignment. Solutions:

• Add the service to SPF: Include their SPF record in yours (watch the 10-lookup limit)
• Configure DKIM: Have the service sign with your domain's DKIM key — most major ESPs support custom DKIM
• Use a subdomain: Send marketing mail from [email protected] and set a separate DMARC record for that subdomain

Subdomain Policy (sp=)

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=none; rua=mailto:[email protected]"

The sp= tag sets policy for subdomains not covered by their own DMARC record. Use sp=none while you inventory subdomain mail traffic before enforcing on subdomains.

ARC Chain Validation

Mailing lists and forwarding services rewrite messages in ways that break DMARC. Authenticated Received Chain (ARC) was designed to solve this — it lets intermediaries vouch for the original authentication. When you see forwarded mail failing DMARC, check whether the forwarder supports ARC (Google Groups does; many legacy MLMs do not).

Summary

DMARC reporting is not optional for any domain that sends email. Start with p=none and rua reporting, use a dedicated analysis tool, fix every legitimate sender that fails alignment, then progressively tighten to p=reject. The entire process takes 4–8 weeks and permanently closes your domain to spoofing.