How to Read a DMARC Report (Without Losing Your Mind)

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:

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 (the d= in the signature). It survives forwarding, which is why aligned DKIM is the more resilient of the two.
• Relaxed vs strict (adkim/aspf): relaxed lets mail.acme.com align with acme.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:

1. Weight by count, not by row. One row with count=5000 matters far more than fifty rows of one. Compute your pass rate as passing messages ÷ total messages.
2. Group by source_ip. Each IP is a sending source: your ESP, your CRM, your own mail server. Do you recognize all of them?
3. 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.
4. 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.
5. 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:

1. Start at p=none and read reports until you recognize every legitimate source and it's passing.
2. Move to p=quarantine: failing mail now goes to spam. Keep watching for collateral damage.
3. 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. Review our guide to DMARC policy modes (p=none vs quarantine vs reject), protect unmonitored branches with DMARC subdomain enforcement, and build full authentication foundations with our SPF, DKIM & DMARC guide.

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.