How to Read a DMARC Report (Without Losing Your Mind)
You turned on DMARC, added an rua= address, and now your inbox fills with XML attachments every morning. Here's how to actually read them, field by field, and turn the noise into a short list of things to fix.
Two kinds of DMARC report
DMARC can send you two things. Forensic (RUF) reports fire on individual failures with a copy of the offending message, but Gmail and Outlook don't send them for privacy reasons, so in practice you'll rarely see one.
Aggregate (RUA) reports are the ones that matter. Every major provider sends them, usually once a day, to the address in your rua= tag. Each is an XML summary of every message that provider saw claiming to be from your domain, grouped by sending IP, with the authentication results for each group. That's your window into who is sending mail as you, and whether it's passing.
What a report looks like
Unzip the attachment (reports arrive as .gz or .zip) and you'll get raw XML. The skeleton is always the same: some metadata, the policy you published, and then one <record> per sending source.
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<report_id>16688540832298…</report_id>
<date_range><begin>1751328000</begin>
<end>1751414400</end></date_range>
</report_metadata>
<policy_published>
<domain>acme.com</domain>
<adkim>r</adkim><aspf>r</aspf>
<p>none</p><sp>none</sp><pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>128</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim><spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>acme.com</header_from></identifiers>
<auth_results>
<dkim><domain>acme.com</domain>
<result>pass</result>
<selector>google</selector></dkim>
<spf><domain>acme.com</domain>
<result>pass</result></spf>
</auth_results>
</record>
</feedback>Every field, decoded
You only need to understand a dozen tags. Here's each one and why it matters:
| Tag | Section | What it tells you |
|---|---|---|
| org_name | report_metadata | Who sent you the report: the receiving provider, e.g. google.com or Enterprise Outlook. |
| date_range | report_metadata | The window the report covers, as Unix timestamps. Almost always a single day. |
| domain | policy_published | The domain the DMARC policy was found for, yours. |
| p | policy_published | Your policy: none (monitor), quarantine (spam), or reject (bounce). |
| sp | policy_published | The policy for subdomains. If unset, it inherits p. |
| pct | policy_published | The percentage of mail the policy is actually applied to. Anything below 100 leaves a gap. |
| adkim / aspf | policy_published | Alignment mode for DKIM and SPF: r (relaxed, matches the org domain) or s (strict, exact match). |
| source_ip | record › row | The IP that sent the mail. Your job is to recognize it, or not. |
| count | record › row | How many messages this row represents. Reports group identical results, so one row can be thousands of emails. |
| disposition | record › row › policy_evaluated | What the receiver actually did: none, quarantine, or reject. This can differ from your policy. |
| dkim / spf | record › row › policy_evaluated | The DMARC-aligned result for each mechanism: pass or fail. This is the number that matters. |
| header_from | record › identifiers | The domain in the visible From: address, which alignment is checked against. |
| auth_results | record | The raw SPF and DKIM results before alignment: the signing domain, selector and envelope domain. |
Alignment is the whole game
The trap in reading DMARC reports is confusing authentication with alignment. A message can pass SPF at the server level and still fail DMARC. DMARC only counts a mechanism if it also aligns: the authenticated domain has to match the domain in the visible From: address.
- SPF alignment compares the
From:domain to the envelope (return-path) domain. Forwarding usually breaks it. - DKIM alignment compares the
From:domain to the domain that signed the message (thed=in the signature). It survives forwarding, which is why aligned DKIM is the more resilient of the two. - Relaxed vs strict (
adkim/aspf): relaxed letsmail.acme.comalign withacme.com; strict requires an exact match.
DMARC passes if either aligned SPF or aligned DKIM passes. That's the pass/fail recorded in policy_evaluated, and it's the number you should be watching.
Reading between the rows
With the fields in hand, here's how to actually interpret a report:
- Weight by
count, not by row. One row withcount=5000matters far more than fifty rows of one. Compute your pass rate as passing messages ÷ total messages. - Group by
source_ip. Each IP is a sending source: your ESP, your CRM, your own mail server. Do you recognize all of them? - Recognized source failing? That's a configuration fix: add it to SPF, set up DKIM signing, or correct the alignment. Legitimate mail you simply forgot to authenticate.
- Unrecognized source failing? That may be someone spoofing your domain. It's failing DMARC, which is exactly what you want. Once you move to enforcement, it gets blocked.
- Watch the
disposition. The receiver gets the final say and can override your policy, for example delivering mail from a high-reputation source despite a failure. If disposition and your policy disagree, that's worth noting.
From reports to a policy you can enforce
The point of reading reports is to safely tighten your policy. The usual path:
- Start at
p=noneand read reports until you recognize every legitimate source and it's passing. - Move to
p=quarantine: failing mail now goes to spam. Keep watching for collateral damage. - Finish at
p=reject: spoofed mail is bounced outright. This is the goal, and it's what BIMI and inbox brand logos require.
Never jump to p=reject while legitimate sources are still failing. You'll block your own mail. The reports are how you earn the confidence to move.
Skip the XML
You don't have to parse this by hand. Emailens has a free, in-browser DMARC report reader. Paste a report and it computes your pass rate, ranks your failing sources, and tells you what to fix. Nothing is uploaded; parsing happens on your device. And if you want to keep an eye on the DNS records behind all this, the deliverability checker validates your SPF, DKIM and DMARC in one click.
Read your next DMARC report in seconds
Paste the XML, get a plain-language summary of what's passing, what's failing, and what to fix, right in your browser.
Open the DMARC report reader