How to Read a DMARC Analyzer Report

A DMARC analyzer turns the raw XML your domain receives from Gmail, Microsoft, Yahoo, and other mailbox providers into a readable table of who sent mail as your domain, whether SPF and DKIM passed, and whether that mail was aligned enough to count under DMARC. Read one correctly and you can spot spoofing, misconfigured tools, and deliverability leaks within minutes instead of digging through raw XML by hand.

This guide walks through an actual aggregate report field by field, shows a healthy row versus one that needs action, and covers the two other report types you will run into less often but still need to recognize.

Key takeaways

• A DMARC aggregate (RUA) report is an XML file, one per sending source per day, showing message counts, source IPs, SPF/DKIM results, and DMARC alignment.
• The two results that matter most are <dmarc_result> for SPF and for DKIM, not the raw pass/fail: DMARC needs at least one of them to pass and be aligned to your domain.
• Alignment fails more often than authentication: a shared platform can pass SPF or DKIM outright and still fail DMARC because the domain in the header does not match.
• The <disposition> field (none, quarantine, reject) tells you what the receiver actually did with the mail, based on your own DMARC policy tag.
• Read reports by source IP or sending platform, not by raw message count. A single unfamiliar IP sending thousands of messages a day is the signal you are looking for.
• Free analyzers like MxToolbox and dmarcian's XML converter are enough for a one-off read; ongoing monitoring across dozens of daily reports is where a dedicated dashboard earns its keep.

What a DMARC analyzer actually does

Every mailbox provider that supports DMARC (Gmail, Outlook.com, Yahoo, and most enterprise filters) sends you a daily XML file summarizing every message it received that claimed to be from your domain. That file is called an aggregate report, sent to the address in the rua tag of your DMARC DNS record. Raw, it looks like this:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </dkim>
  </auth_results>
</record>

Multiply that block by every sending source, your product's transactional sender, marketing tool, support desk, CRM, and anyone spoofing you, and a single report can run to hundreds of records. A DMARC analyzer parses that XML into a table: source, volume, pass/fail, and alignment, so you are not reading tags by eye.

If you have not set up reporting yet, start with SPF, DKIM, and DMARC explained for the DNS side, and the email deliverability guide for how these three checks fit into the bigger inbox-placement picture.

The three report types you'll see

• Aggregate reports (RUA): Daily XML summaries. This is what most people mean by "DMARC report" and what this article focuses on.
• Forensic reports (RUF): Per-message failure samples, sent in near real time. Very few providers still send these (Gmail and Yahoo stopped years ago over privacy concerns), so do not expect a steady stream even with an ruf tag configured.
• SMTP TLS reports: A separate report (RFC 8460) showing whether receivers could establish encrypted delivery to your mail servers. Related but not part of DMARC itself; most DMARC tools surface aggregate reports only.

Reading the aggregate report field by field

Here is what each field means and what to check.

Source IP and count

<source_ip> is who sent the mail. <count> is how many messages from that IP this report covers. Group by IP first: if you recognize it (your app server, your ESP's sending range, your helpdesk), move on. If you don't, that is your starting point for investigation, not the pass/fail columns.

Policy evaluated: disposition, dkim, spf

This block shows what the receiver actually did with the mail and the DMARC-level (not raw) result:

• <disposition> is the enforcement outcome: none (delivered, no DMARC action taken), quarantine (sent to spam), or reject (bounced). This reflects the policy you published in your DMARC record's p= tag at the time, not a suggestion from the receiver.
• <dkim> and <spf> inside policy_evaluated are the DMARC-aligned results: pass or fail, after alignment is checked. These can differ from the raw authentication results below them, and that gap is the most common source of confusion.

Identifiers: header_from

<header_from> is the domain your recipient's inbox actually displayed, the one alignment gets checked against. This is the domain that matters for spoofing detection: if a record shows a header_from of your domain but a source_ip you do not control, someone is sending mail claiming to be you.

Auth results: the raw SPF and DKIM checks

This is the raw, pre-alignment authentication data: did SPF find the sending IP in the domain's SPF record, and did DKIM's cryptographic signature verify. Each has its own <domain> field, and that is the one to compare against header_from.

Why alignment is the part people get wrong

DMARC does not just ask "did SPF pass" or "did DKIM pass." It asks whether the domain that passed SPF or DKIM matches (is "aligned" with) the domain in the visible From header. A message can pass SPF and DKIM individually and still fail DMARC if neither one is aligned.

This is exactly what trips people up with third-party senders. Say your support tool sends as mail.helpdeskapp.com on your behalf, using their own SPF and DKIM, but the message displays [email protected] in the From header. SPF and DKIM both pass for helpdeskapp.com, but neither is aligned to yourdomain.com, so DMARC fails unless that tool is specifically configured to send with your domain's own DKIM signature.

The practical rule: DMARC only needs SPF or DKIM to pass and be aligned, not both. That is why DKIM alignment is generally the more resilient path, since DKIM signatures survive email forwarding while SPF does not.

A worked example: reading a real row

Take this simplified record from an aggregate report:

<record>
  <row>
    <source_ip>203.0.113.55</source_ip>
    <count>187</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>marketingtool.io</domain>
      <result>pass</result>
    </dkim>
  </auth_results>
</record>

Reading it: 187 messages from 203.0.113.55, disposition none (delivered), SPF aligned and passing, DKIM passing but for marketingtool.io instead of your domain, so it is unaligned and fails at the DMARC level. Net result: this record passes DMARC because SPF alone was enough. Make sure this IP is listed in your SPF record; if it isn't, add it, since a future SPF change could flip this to a full fail.

What to do with what you find

1. Inventory every source IP and platform. Cross-reference against your known senders: product transactional email, marketing platform, helpdesk, invoicing tool, any BI or CRM that emails on your behalf.
2. Fix alignment gaps first. For any legitimate sender failing DMARC, either add its IP range to your SPF record or (better, since it survives forwarding) get it to sign with a DKIM key tied to your domain, sometimes via a CNAME the vendor provides.
3. Investigate unknown IPs. High volume from an IP you do not recognize, especially with a matching header_from, is the spoofing signal DMARC exists to catch. Persistent unauthenticated volume also drags down your sender reputation, so treat this as a deliverability issue, not just a security one.
4. Move your policy forward only once known senders are clean. Most guidance, including Google's and Microsoft's own bulk sender requirements, recommends staying at p=none (monitor only) until every legitimate source passes consistently, then moving to p=quarantine, then p=reject.
5. Recheck weekly while you're in the monitor phase. Aggregate reports arrive roughly once a day per receiver, so a single day's report is a sample, not the full picture. Watch a rolling week before making policy changes, the same way you would track any other deliverability metric over time rather than off one data point.

Choosing a DMARC analyzer

For a one-off read of a report you already have, a free XML-to-table converter is enough. For ongoing monitoring across dozens of daily reports, a dashboard that aggregates history, flags new IPs, and tracks pass-rate trends saves the manual grouping work.

Whatever you use, the fields above (source IP, disposition, the aligned dkim/spf results, and header_from) are the same across every tool. Once you can read raw XML, any analyzer's dashboard is just a faster way to see the same data.

A domain reputation checker is worth pairing with DMARC monitoring: DMARC tells you who is sending as you and whether they authenticate, while a domain reputation checker tells you how mailbox providers currently regard your sending domain overall, which is the other half of staying out of spam.

If you are setting up DMARC for the first time rather than reading existing reports, a DMARC record generator will build the DNS TXT record's v, p, rua, and alignment tags for you correctly formatted, which avoids the syntax errors that are the single most common reason a domain gets zero reports in the first place.

Getting the sending side right, not just the reading side

Reading reports well only pays off if you can act on what they show, and for a SaaS team that means having control over sender identities and domain verification in the first place. Meisa, the email platform built for SaaS founders, verifies DKIM and SPF per sending domain as part of setting up a sender identity, so the authentication half of what shows up in your DMARC reports is configured correctly from the start rather than left to guesswork. It is one piece of a deliverability setup, not a DMARC report reader itself: you will still want a dedicated DMARC analyzer for the monitoring and alignment tracking this guide walks through. See meisa.io for how sender identity and domain verification fit into the rest of the platform.

FAQ

What does it mean if my DMARC report is empty or I'm not receiving any?

Usually a DNS issue: the rua address in your DMARC TXT record is wrong, the record has a syntax error, or not enough time has passed. Reports typically start arriving within 24 to 48 hours of a correctly published record. Double-check the record with a DNS lookup tool before assuming something is broken.

How often are DMARC aggregate reports sent?

Roughly once every 24 hours per receiving provider that saw mail claiming to be from your domain. If you send to Gmail, Outlook, and Yahoo users, expect a separate daily report from each. Low-volume domains may get reports less predictably, since some receivers batch or skip reports when there is too little mail to summarize meaningfully.

Why does DKIM pass in the raw auth_results but fail in policy_evaluated?

This is an alignment failure, not an authentication failure. The DKIM signature verified correctly, but the domain that signed it does not match (is not aligned with) the domain in your visible From header. Check the <domain> under <dkim> in auth_results against <header_from>: if they differ, that sender needs to sign with your domain's DKIM key, not fix anything about the signature itself.

Can I read a DMARC report without a special tool?

Yes. The file is plain XML, so any text editor works, and the field names in this guide (source_ip, disposition, policy_evaluated, auth_results, header_from) are consistent across providers since they follow the same schema. A free analyzer just saves you from manually grouping records by sender when a report has hundreds of rows.

Do I need both SPF and DKIM to pass DMARC?

No. DMARC passes if either SPF or DKIM passes and is aligned to your header From domain. Many teams rely primarily on DKIM alignment because it survives forwarding, where SPF typically breaks, but having both configured gives you redundancy if one fails during a provider outage.

What's the difference between disposition "none" and a DMARC failure?

They answer different questions. Disposition is what the receiver did based on your published policy: none means delivered regardless of authentication outcome, because p=none tells receivers to take no enforcement action. A message can fail DMARC's authentication and alignment checks and still show disposition none, simply because your policy hasn't yet told receivers to quarantine or reject failures. Disposition only becomes consequential once you move to p=quarantine or p=reject.