What Are DMARC Reports and How to Read Them

What Are DMARC Reports and How to Read Them

DMARC reports are the feedback loop that makes email authentication useful. Without them, publishing a DMARC record is like locking your front door and never checking who tried the handle.

When you publish a DMARC record with an rua email address, receiving mail servers like Google, Yahoo, and Microsoft send you daily machine-readable reports showing every email that claimed to be from your domain — whether it passed or failed authentication, where it came from, and what policy was applied.

This article covers the two types of DMARC reports, what the data means, and how to make sense of the XML.

Aggregate Reports (RUA)

Aggregate reports (specified by the rua tag in your DMARC record) are daily XML summaries. They are the primary tool for monitoring your domain's email ecosystem.

Each report contains:

• Report metadata — the sender's domain (e.g., google.com), a report ID, and the date range covered.
• Policy published — your domain's DMARC policy at the time (p=none, p=quarantine, or p=reject).
• Record rows — one row per unique combination of source IP, sender domain, and authentication result. Each row includes:
  • Source IP — the IP address that sent the email.
  • DKIM result — pass, fail, or neutral.
  • SPF result — pass, fail, or neutral.
  • DMARC result — computed from DKIM and SPF alignment: pass or fail.
  • Identifier alignment — whether the Header From domain matches the envelope From (SPF) or d= domain (DKIM).
  • Count — how many messages this row represents.
• Disposition — what the receiving server did: none (delivered), quarantine (spam folder), or reject (blocked).

A typical report might show: "Google received 1,247 messages claiming to be from yourdomain.com. 1,202 passed DMARC from your legitimate senders. 45 failed from a single IP that doesn't match your SPF record."

Forensic Reports (RUF)

Forensic reports (specified by the ruf tag) contain copies of individual emails that failed DMARC — including headers and sometimes content. In theory they help you analyze specific failures; in practice they are rarely used because:

• They can contain PII and sensitive message content.
• Receiving providers often refuse to send them (Google stopped sending RUF reports years ago).
• The volume is unmanageable for high-traffic domains.

Most domain owners skip RUF entirely and rely on aggregate reports. Earning the right to enforce p=reject does not require forensic reports.

How to Enable DMARC Reports

Add an rua tag to your DMARC DNS record pointing to a mailbox that can handle the XML:

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

The mail server needs to accept mail at that address and not strip the XML attachment. A dedicated alias or a DMARC analysis service handles this better than a personal inbox.

Reports arrive as .zip or .gz attachments containing one .xml file per sending server. Most are from Google, Yahoo, Microsoft, and smaller ISPs.

How to Read the XML

Here is a simplified example of what the XML looks like — the key fields to focus on:

• <source_ip> — the IP of the sending server. Cross-reference against your known senders.
• <dkim_auth> / <spf_auth> — pass means this email authenticated correctly.
• <disposition> — none is normal for p=none; once you enforce, you'll see quarantine and reject here.
• <count> — multiplied by one row, so a single IP sending spam can show a count of hundreds.

What to Look For

Three things every domain owner should check in their first week of reports:

1. Unauthorized senders — IPs that appear with a DMARC fail and a high count. These are the spammers or phishers you need to shut down.
2. Missing SPF or DKIM — sources that pass one check but not the other. Add them to your SPF record and configure DKIM signing for them.
3. Volume patterns — a sudden spike from an unknown IP means an active attack, not a misconfiguration.

Not sure if your domain is set up to receive reports yet? Scan your domain for free to check your current DMARC record and start monitoring.

Going Beyond the Raw XML

Manually reading XML reports is practical for low-volume domains. For anything above a few thousand messages a day, a DMARC report analyzer (including our own free scanner) does the parsing for you — flagging unauthorized senders, tracking authentication pass rates over time, and identifying the sources that need SPF or DKIM configuration before you move from p=none to p=quarantine.

Understanding your DMARC reports is the step between publishing your first record and safely enforcing a reject policy. Check your reports weekly, configure every source you see, and move up the policy ladder only when legitimate traffic shows 100% authentication pass rate.