How to read a DMARC RUA report (and what it reveals)

<?xml version="1.0" ?>
<feedback>
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>3456789012345678901</report_id>
    <date_range>
      <begin>1719273600</begin>
      <end>1719359999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>40.107.1.25</source_ip>
      <count>347</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Reading a report in practice: the reading flow

When a report arrives, the reading goes in this order:

1. org_name — who is sending it (Gmail, Outlook, Yahoo…).
2. date_range — what period (yesterday? two days ago?).
3. policy_published/p — is the policy visible correctly?
4. For each <record>:
   • source_ip: is this IP a known one?
   • count: how many messages?
   • policy_evaluated/dkim and spf: does it pass or fail?
   • If it fails: why? auth_results carries the detail.

A few minutes with this flow settle both questions: whether the legitimate sources pass, and whether suspicious IPs are sending in the domain's name.

What a report reveals about the actual posture

An RUA report isn't just a list of results — it's a snapshot of the authentication posture. A careful reading, <record> block by <record> block, reconstructs a precise picture of the situation: which sources work, which are broken, and which had never been identified at all. That last point is often the most revealing: DMARC reports regularly uncover sending sources that organizations have forgotten — an old application, a vendor whose service was dropped long ago but whose DNS configuration was never cleaned up, a SaaS tool quietly sending notifications in the company's name.

To get the most out of a report, the reading has to go beyond source by source and look for patterns: are failures concentrated on a few IPs or scattered across many? Do the same IPs fail in reports from multiple ISPs or only one? Is the failure volume increasing over time? These questions transform a one-off diagnostic into a systemic understanding of the posture.

The red flags to watch for

A few configurations in a report should immediately catch the eye. A high count on an unknown IP: someone is sending large volumes of messages claiming the domain's identity, from an IP nobody recognizes. At p=none, those messages are being delivered — under the domain's brand. Sudden failures on a recognized IP: a configuration changed somewhere (poorly executed DKIM key rotation, SPF configuration change, provider switch). policy_published/p different from the declared policy: the record isn't correctly published, or an unwanted change was made. These three signals deserve immediate investigation, independent of the rest of the report.

A fourth signal deserves the same reflex: a header_from showing an unused subdomain. Reports don't only cover the main domain — when a message claims to come from a subdomain, the corresponding <record> block shows it in header_from, and it's the <sp> tag of the policy that applies there. A legitimate sender can live there (a platform configured on a dedicated subdomain), but so can a spoofer: subdomains are often watched less closely than the root, which is exactly what makes them attractive. Scanning the header_from values in each report, not just the IPs, is the habit that pays — an unexpected subdomain is a discovery in its own right, just like an unknown address.

Identifying the sources in the reports

A raw report gives an IP. A well-used report gives the owner of that IP. That conversion — IP → identified sending service — is what turns a report into an action plan. An unrecognized IP calls for a quick reverse DNS lookup (nslookup IP or dig -x IP). The result often names the hosting provider or cloud platform the IP belongs to. Cross-referencing with the list of known sending services then does the rest: a marketing platform on that cloud? A transactional email provider? An old CRM that may still be sending? An IP that resolves to nothing recognizable stays suspicious — not necessarily a threat, but not something to mark as legitimate without investigation.

Why an analysis tool makes the difference

A single Gmail report can sometimes contain dozens of <record> blocks. Multiplied by reports from Microsoft, Yahoo, Apple, and others, manual reading quickly becomes exhausting. DMARC analysis tools aggregate these reports, enrich them with IP identity (hosting providers, known platforms), and present a consolidated view. Our analyzer does exactly that: it reads the reports, identifies the sources, and shows the status of each — with no XML file ever opened by hand.

Frequently asked questions

Reports arrive as .gz or .zip. How do they open? Decompressing the file (gunzip on Mac/Linux, 7-Zip or WinRAR on Windows) yields the .xml, which any text editor or browser will display. Better yet: an analysis tool that does it automatically.

Why do several reports arrive per day? Generally they don't — it's one per sender per day (24-hour period by default). Several from the same actor may be a split, where volume is very high.

I see disposition=quarantine but my policy is p=reject. Why? The policy_evaluated/disposition reflects what the ISP actually applied, not the declared policy. Some actors have overrides (whitelists, bilateral agreements) that soften enforcement. This is not a configuration error.

No reports arrive at all. What's happening? The DMARC record has to be published and contain rua=mailto:address@example.com. The receiving address also has to be reachable, with the messages not ending up in spam. And if the rua= address sits on an external domain, that domain must carry an authorization _dmarc record.

Does every email sent generate a report? No. Reports are aggregated: one block per IP/results combination over the period. 1000 emails from the same IP with the same results = 1 <record> with count=1000.

What to do about an unrecognized IP? Resolving it via reverse DNS (nslookup IP or dig -x IP) comes first, to see which service it belongs to. A known cloud provider might point to an old VM or a forgotten service. An unknown range with no clear reverse DNS is a red flag — possibly impersonation. In any case, it stays off the "legitimate" list until its source has been identified with certainty.

Do reports include messages rejected by my own spam filter? No. RUA reports cover messages that reached the recipient server and were evaluated by DMARC. Messages rejected before DMARC evaluation (TCP connection blocked, SMTP rejection) don't appear.

Do reports reflect all my emails or only some? Only messages that arrive at recipients whose ISP sends DMARC reports. Mail sent to a domain that hasn't implemented reporting doesn't appear — even under an active policy. That's why data from major ISPs (Gmail, Outlook, Yahoo) is most representative: they cover the bulk of global traffic.

Letting Thomas decode the reports

Opening and decoding XML by hand is doable — but tedious, and potentially misleading for anyone who doesn't know where to look. Thomas, the virtual CISO, reads the reports continuously, names the sources that pass and those that deserve attention, and presents a clear diagnosis without raw XML.

Analyze a domain for free or create an account for DMARC reports readable at a glance.