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

A DMARC RUA report arrives in your inbox as a .xml.gz or .xml.zip attachment. Inside, XML that at first glance looks like an airport dashboard — lots of tags, little explanation. Yet once you know where to look, an RUA report tells a very clear story: who sent mail in your name, from where, with what result. This guide decodes the structure and tells you which tags to look at first.

The general structure

An RUA report follows a standardized XML schema. Here's its skeletal form:

<?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>your-domain.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>your-domain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>your-domain.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>your-domain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

In reality, this skeleton will contain several <record> blocks, one per combination of source IP / authentication results observed.

The essential tags to read

report_metadata

• org_name: who is sending the report. Google, Microsoft, Yahoo — it's the ISP that received and evaluated your messages.
• date_range: the period covered (Unix timestamps). Convert them to find out which day the report covers.
• report_id: the report's unique identifier, useful for referencing it if you want to dig deeper with the ISP.

policy_published

What the ISP saw as policy at the time of the report. Check that <p> matches what you want to apply. If it's none when you thought you'd set quarantine, your DNS record may not have propagated yet or may be mis-published.

<record> — the heart of the report

Each <record> represents a group of identical messages (same IP, same results). This is where everything happens:

• source_ip: the IP that sent the messages. Your first question: do you recognize this IP? Your server, your sending platform?
• count: how many messages are grouped in this block. A count of 347 on a recognized IP is normal. A count of 12 on an unknown IP deserves investigation.
• policy_evaluated → disposition: what the receiver actually did with the message (none, quarantine, reject). A disposition=none with p=reject may indicate the ISP has a local override or the message is let through due to a trust agreement.
• policy_evaluated → dkim and spf: the DKIM and SPF result after alignment. This is what matters for DMARC, not the raw results in auth_results.
• header_from: the From: domain of the email. It should always be your domain.

auth_results

The raw SPF and DKIM results, before alignment evaluation. Useful for diagnosis:

• If auth_results/dkim/result=pass but policy_evaluated/dkim=fail, the DKIM signature is valid but not aligned — the domain in auth_results/dkim differs from header_from. Classic case: a platform signing with its own domain.
• If auth_results/spf/result=pass but policy_evaluated/spf=fail, same logic: SPF passes for the envelope, but the envelope isn't your domain.

Reading a report in practice: the reading flow

When a report arrives, read it 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 my policy visible correctly?
4. For each <record>:
   • source_ip: do I recognize this IP?
   • count: how many messages?
   • policy_evaluated/dkim and spf: does it pass or fail?
   • If it fails: why? Look at auth_results for the detail.

In a few minutes with this flow, you know whether your legitimate sources pass and whether suspicious IPs are sending in your name.

What a report tells you about your actual posture

An RUA report isn't just a list of results — it's a snapshot of your authentication posture. By reading each <record> block carefully, you can reconstruct a precise picture of your situation: which sources work, which are broken, and which you hadn't identified. 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 you no longer use but whose DNS configuration was never cleaned up, a SaaS tool sending notifications in your name without you knowing.

To get the most out of a report, go beyond reading 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 your posture.

The red flags to watch for

A few configurations in a report should immediately catch your attention. A high count on an unknown IP: someone is sending large volumes of messages claiming to be you from an IP you don't recognize. If your policy is p=none, those messages are being delivered — under your 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 your policy: your record isn't correctly published, or an unwanted change was made. These three signals deserve immediate investigation, independent of the rest of the report.

Identifying your sources in the reports

A raw report gives you an IP. A well-used report tells you who owns that IP. That conversion — IP → identified sending service — is what turns a report into an action plan. When you spot an IP you don't recognize, do a quick reverse DNS lookup (nslookup IP or dig -x IP). The result often tells you which hosting provider or cloud platform the IP belongs to. Cross-reference with your list of sending services: do you have a marketing platform on that cloud? A transactional email provider? An old CRM that may still be sending? If the IP resolves to nothing recognizable, treat it as 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 you with a consolidated view. Our analyzer does exactly that: it reads your reports, identifies your sources, and shows you the status of each — without you having to open a single XML file.

Frequently asked questions

My reports arrive as .gz or .zip. How do I open them? Decompress the file (gunzip on Mac/Linux, 7-Zip or WinRAR on Windows) to get the .xml, then open it in a text editor or browser. Better yet: use an analysis tool that does it automatically.

Why do I receive several reports per day? Generally no — one per sender per day (24-hour period by default). If you receive several from the same actor, it may be split if 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 your declared policy. Some actors have overrides (whitelists, bilateral agreements) that soften enforcement. This is not an error on your part.

I receive no reports. What's happening? Check that your DMARC record is published and contains rua=mailto:address@your-domain.com. Also check that the receiving address is accessible and emails aren't ending up in spam. If the rua= address is on an external domain, that domain must have an authorization _dmarc record.

Does every email I send 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 should I do when I see an IP I don't recognize? Start by resolving it via reverse DNS (nslookup IP or dig -x IP) and see which service it belongs to. If it's a known cloud provider, it might be an old VM or forgotten service. If it's an unknown range with no clear reverse DNS, it's a red flag — possibly impersonation. In any case, don't mark it as "legitimate" without having identified its source 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. If you're sending to a domain that hasn't implemented reporting, those messages don't appear — even if your policy is active. That's why data from major ISPs (Gmail, Outlook, Yahoo) is most representative: they cover the bulk of global traffic.

Let Thomas decode your reports

Opening and decoding XML by hand is doable — but tedious and potentially misleading if you don't know where to look. Thomas, your virtual CISO, reads your reports continuously, tells you which sources pass and which deserve attention, and presents a clear diagnosis without raw XML.

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