toolbox-poster

Posted on Apr 12 • Originally published at toolbox.starnomina.tn

DMARC Report Analyzer: How to Read and Act on Aggregate Reports

#email #dns #devops #security

TL;DR
DMARC aggregate reports are XML files sent daily by receiving mail servers, detailing how your domain's email performed against SPF and DKIM checks. Understanding these reports is essential for identifying unauthorized senders, diagnosing authentication failures, and strengthening your email security posture. This guide walks through report structure, analysis workflows, and actionable response strategies.

📑 Table of Contents

Report Types: Aggregate vs Forensic
Aggregate Report XML Structure
Key Fields Explained
Analysis Workflow
Identifying Legitimate vs Spoofing Sources
IP Investigation
Escalation Criteria
Automated Processing
Common Report Patterns
Best Practices
Common Mistakes
Tools
References

Report Types: Aggregate vs Forensic

Feature	Aggregate (rua)	Forensic / Failure (ruf)
Format	XML (gzipped)	AFRF message (RFC 6591)
Frequency	Daily (typically)	Per-failure (real-time)
Content	Statistics: IP, count, SPF/DKIM/DMARC results	Full message headers of failing emails
Privacy	No PII—only IPs and counts	May include headers with recipient addresses
Adoption	Universally supported	Many providers refuse to send forensic reports

ℹ️ Focus on aggregate reports for ongoing monitoring. Forensic reports are useful for debugging specific failures but are rarely sent by major mailbox providers due to privacy concerns.

Aggregate Report XML Structure

Each aggregate report follows the schema defined in RFC 7489 §7. Here is an annotated example:




    google.com
    noreply-dmarc-support@google.com
    17248456789012345678

      1712880000  
      1712966400      





example.com
    r   
    r     
    reject


100     


   per unique source-IP + result combination -->


      209.85.220.41
      1524

        none   
        pass
        pass



      example.com



        example.com
        pass
        google


        example.com
        pass

Key Fields Explained

Field	Location	Meaning
`source_ip`	`row`	The IP address that sent the email. Key for identifying the sending server.
`count`	`row`	Number of messages from this IP with the same result combination.
`disposition`	`policy_evaluated`	What the receiver did: none, quarantine, or reject.
`dkim` / `spf`	`policy_evaluated`	DMARC-level pass/fail (includes alignment check).
`auth_results`	`record`	Raw SPF and DKIM authentication results before alignment evaluation.
`header_from`	`identifiers`	The domain in the From: header—must align with SPF or DKIM domain.

Analysis Workflow

1. Decompress & Parse — Reports arrive as .gz or .zip attachments. Extract and parse the XML.

2. Separate Pass vs Fail — Group records by DMARC result. Focus on failures first.

3. Identify Source IPs — For each failing source IP, determine ownership via reverse DNS and WHOIS.

4. Classify Sources — Categorize as: legitimate (forgot to update SPF), forwarded mail, or unauthorized/spoofing.

5. Take Action — Update SPF/DKIM for legitimate sources; tighten DMARC policy for spoofing sources.

Identifying Legitimate vs Spoofing Sources

💡 A failing IP that belongs to a known service you use (e.g., SendGrid, Mailchimp, your CRM) is almost certainly a configuration issue, not spoofing. An unknown IP from an unrelated network is likely unauthorized use.

Indicators of a legitimate source with a configuration problem:

IP belongs to a service you use (check the provider's published IP ranges).
DKIM passes but SPF fails (common when third-party sends on your behalf without SPF include).
Consistent, moderate volume matching expected sending patterns.

Indicators of spoofing/phishing:

IP belongs to an unknown hosting provider or residential ISP.
Both SPF and DKIM fail with no alignment.
Irregular volume spikes, especially from geographic regions you don't operate in.

IP Investigation

For each suspicious source IP, perform:

Reverse DNS — dig -x 209.85.220.41 to get the PTR record.
WHOIS — Identify the network owner (ISP, cloud provider, or hosting company).
Reputation Check — Query blocklists (Spamhaus, Barracuda) and reputation services.
Geo-location — Map the IP to a country to cross-reference against your expected sending regions.

Escalation Criteria

Escalate to your security team or email administrator when:

A single source IP sends > 1,000 messages with both SPF and DKIM failing.
Spoofing volume exceeds 10% of your total legitimate email volume.
The spoofing source IP is on a known bulletproof hosting network.
You detect spoofing patterns targeting your customers or partners.

Automated Processing

For domains receiving more than a handful of reports daily, manual parsing is impractical. Automate with:

A dedicated rua mailbox with auto-extraction and XML parsing scripts.
Third-party DMARC analytics platforms (Valimail, dmarcian, Postmark) that aggregate and visualize data.
Open-source tools like parsedmarc that ingest reports into Elasticsearch for dashboarding.

Common Report Patterns

Pattern	Likely Cause	Action
High volume, SPF pass, DKIM pass	Normal legitimate traffic	No action needed
SPF fail, DKIM pass, from known provider	Missing SPF `include:` for the provider	Add the provider to your SPF record
SPF pass, DKIM fail, from your own IP	DKIM signing not enabled or key mismatch	Verify DKIM configuration and selector
SPF fail, DKIM fail, from unknown IP	Spoofing or phishing attempt	Ensure DMARC policy is `p=reject`; investigate IP
Small volume, SPF fail, from residential IP	Auto-forwarding by a recipient	Usually benign; monitor but no action needed

Best Practices

Set up a dedicated mailbox or group alias for rua reports—don't send them to a personal inbox.
Review reports weekly during DMARC rollout; monthly once policy is at p=reject.
Correlate DMARC data with your email marketing and transactional email dashboards.
Move to p=reject only after confirming all legitimate sources pass authentication.
Keep historical reports for trend analysis—spoofing campaigns often recur.

Common Mistakes

Mistake	Impact	Fix
Ignoring aggregate reports	Spoofing goes undetected; legitimate mail silently fails	Process reports weekly minimum
Setting `p=reject` without analyzing reports	Legitimate email from third-party senders gets rejected	Start with `p=none`, analyze, then escalate
Using a personal email for `rua`	Inbox overwhelmed; reports ignored	Use a dedicated functional mailbox
Not investigating failing IPs	Misconfigured senders remain broken	Look up every failing IP and categorize
Confusing raw auth_results with DMARC evaluation	Misdiagnosing pass/fail status	DMARC pass requires alignment; raw SPF/DKIM pass alone is insufficient

Tools

DMARC Report Analyzer — Upload and parse aggregate XML reports with visual summaries.

DMARC Checker — Verify your published DMARC record syntax and policy.

IP Address Lookup — Investigate source IPs from reports: WHOIS, geolocation, and reputation.

References

📄 RFC 7489 §7 — DMARC Aggregate Reports
📄 RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
📄 DMARC.org — Overview and FAQ

🎯 Key Takeaway: 🎯 DMARC aggregate reports are your email security radar. Parse them regularly, investigate every failing source IP, fix legitimate misconfigurations, and only escalate to p=reject when you're confident all authorized senders pass authentication.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

DEV Community