Skip to main content
Blog
Jul 18, 2026·8 min read

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.

aggregate report (trimmed)
<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:

TagSectionWhat it tells you
org_namereport_metadataWho sent you the report: the receiving provider, e.g. google.com or Enterprise Outlook.
date_rangereport_metadataThe window the report covers, as Unix timestamps. Almost always a single day.
domainpolicy_publishedThe domain the DMARC policy was found for, yours.
ppolicy_publishedYour policy: none (monitor), quarantine (spam), or reject (bounce).
sppolicy_publishedThe policy for subdomains. If unset, it inherits p.
pctpolicy_publishedThe percentage of mail the policy is actually applied to. Anything below 100 leaves a gap.
adkim / aspfpolicy_publishedAlignment mode for DKIM and SPF: r (relaxed, matches the org domain) or s (strict, exact match).
source_iprecord › rowThe IP that sent the mail. Your job is to recognize it, or not.
countrecord › rowHow many messages this row represents. Reports group identical results, so one row can be thousands of emails.
dispositionrecord › row › policy_evaluatedWhat the receiver actually did: none, quarantine, or reject. This can differ from your policy.
dkim / spfrecord › row › policy_evaluatedThe DMARC-aligned result for each mechanism: pass or fail. This is the number that matters.
header_fromrecord › identifiersThe domain in the visible From: address, which alignment is checked against.
auth_resultsrecordThe 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 (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.

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