How to Read DMARC Reports: A Complete Guide to RUA & RUF

You published a DMARC record, set rua= to your email address, and now reports are landing in your inbox as compressed XML files. They are hard to read, they arrive from companies you have never heard of, and it is not obvious what, if anything, you are supposed to do with them.

This guide fixes that. It explains what DMARC reports contain, how to read the XML field by field, what RUA and RUF actually mean, and, most importantly, what action to take when a sender passes, fails, or shows up unexpectedly. If you are holding your first report right now, start at the top and work down.

This blog assumes you already have a record in place. If you do not, first publish a DMARC record, then come back to interpret the reports it generates.

What Are DMARC Reports?

DMARC reports are daily summaries sent by receiving mail servers to the address in your rua= tag. Each one lists every IP address that sent an email claiming to be from your domain during a reporting period, and whether SPF and DKIM passed or failed for each source. They are the primary tool for monitoring your domain’s email authentication posture. They are your only real visibility into who is sending mail as you, legitimate or not.

Who Sends DMARC Reports?

Every mail server that receives email from your domain will send a report if you have rua= configured. That obviously includes Google, Microsoft, and Yahoo. It also includes smaller ESPs, corporate mail gateways, university systems, and international providers that your recipients happen to use. 

Receiving reports from organizations you do not recognize is normal and expected. It can simply means a server somewhere processed a message that appeared to come from your domain. However, note that a high volume of mail in those reports from an IP you don’t control still warrants investigation, since that’s a spoofing signal.

The number of reports you get per day depends on how many distinct mail servers received your email. If you send only to a handful of recipients, you might get two or three reports a day. High-volume senders can receive hundreds. None of that indicates a problem on its own. Volume of reports reflects the spread of your recipients, not the health of your domain.

When Do Reports Arrive?

Most providers send one aggregate report every 24 hours, and reports typically arrive within 24 to 48 hours of the email activity they describe. You receive a separate report from each reporting organization (Google and Microsoft send their own, independently), so a single day’s mail to mixed recipients produces several reports covering the same window.

Reports arrive as .zip or .gz compressed attachments from automated senders. Some email clients flag these as suspicious, so if you are expecting reports and seeing none, check your spam or junk folder before assuming something is broken.

Types of DMARC Reports: RUA vs RUF

There are two types of DMARC reports. For nearly all domains, you will only ever need to think about the first one.

Aggregate Reports (RUA): The Standard

DMARC Aggregate reports are a 24-hour summary of all email traffic from your domain that a given mail server processed. They arrive as compressed XML and show you sending IPs, message volumes, SPF pass/fail, DKIM pass/fail, and the DMARC disposition (the action the receiver took). Critically, they contain no email content and no personally identifiable information, just authentication metadata, which makes them safe to receive and store in every region. This is the report this guide focuses on. 

Failure Reports (RUF): Per-Message Failures

DMARC Failure reports (historically called forensic reports) are near-real-time notifications that a specific message failed authentication. RFC 9991 (May 2026) formally standardized this report type. Because a failure report can include message headers and sometimes body content (data that may contain PII), major providers, including Google, Microsoft, and Yahoo, do not send them at all. Enable ruf= only if you have a dedicated processor for the data, and do not expect reports from the big mailbox providers regardless. 

RUA vs RUF 

What’s Inside a DMARC Report: Field by Field

A DMARC aggregate report is an XML file divided into three main sections: report metadata (who sent it and when), published policy (your DMARC record as the receiver saw it), and records, one row per sending source. Understand those three blocks, and the rest is detail.

Section 1: Report Metadata (<report_metadata>)

This block tells you who sent the report and the period it covers.

• org_name: the reporting organization (e.g., google.com).
• email: the report sender’s contact address.
• report_id: a unique identifier for this specific report.
• date_range (begin + end): the reporting window, given as epoch timestamps, you will need to convert to a human-readable date.

What to check here: confirm the report covers the period you expect.

Section 2: Policy Published (<policy_published>)

This shows your DMARC record exactly as the receiver evaluated it at processing time.

• domain: the domain the policy applies to.
• adkim / aspf: DKIM and SPF alignment modes (relaxed or strict).
• p: your policy (none, quarantine, or reject).
• sp: your subdomain policy, if set.
• pct: a legacy percentage field. Note that pct was removed under RFC 9989 (May 2026); you may still see it in older reports, but new records should omit it.

What to check here: confirm the published policy matches what you intended. If it does not, your DNS may not have fully propagated.

Section 3: Records (<record>): The Important Part

Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.

• source_ip: the sending IP address. Look this up to identify who sent the mail.
• count: how many messages came from that IP.
• policy_evaluated/disposition: the action taken (none, quarantine, or reject).
• policy_evaluated/dkim and policy_evaluated/spf: the DMARC-aligned pass/fail result for each.
• identifiers/header_from: the visible From: domain, which is what DMARC protects.
• auth_results/spf: the SPF domain and result.
• auth_results/dkim: the DKIM domain, selector, and result.

What to check here: is every IP you recognize passing DMARC, and are there any IPs you do not recognize?

DMARC XML Report Example

Here is a realistic, anonymized aggregate report showing three sending sources: one passing legitimate sender, one failing legitimate sender, and one unknown IP. Every field carries a plain-English comment. 

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
  <report_metadata>
    <org_name>google.com</org_name>             <!-- The provider that generated this report -->
    <email>[email protected]</email>  <!-- Where the report came from -->
    <report_id>1234567890123456789</report_id>  <!-- Unique ID for this report -->
    <date_range>
      <begin>1718928000</begin>                 <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
      <end>1719014400</end>                      <!-- End of window (epoch)   = 2024-06-22 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
  <policy_published>
    <domain>example.com</domain>                <!-- The domain this report is about -->
    <adkim>r</adkim>                             <!-- DKIM alignment: r = relaxed -->
    <aspf>r</aspf>                               <!-- SPF alignment:  r = relaxed -->
    <p>none</p>                                  <!-- Your policy: monitoring only -->
    <sp>none</sp>                                <!-- Subdomain policy -->
  </policy_published>

  <!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->

  <!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>      <!-- A Google sending IP -->
      <count>150</count>                         <!-- 150 messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>          <!-- No action taken -->
        <dkim>pass</dkim>                         <!-- DKIM aligned & passed -->
        <spf>pass</spf>                           <!-- SPF aligned & passed -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Visible From: domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
       Action: ask the provider to enable DKIM signing for your domain. -->
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>      <!-- Your email service provider -->
      <count>45</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>                         <!-- DKIM not aligned / not signed -->
        <spf>pass</spf>                           <!-- SPF passes -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>esp-vendor.example.org</domain>  <!-- Signed by vendor domain, not yours -->
        <selector>s1</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
       Low volume here = monitor. High volume would signal active spoofing. -->
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>       <!-- Unrecognized IP -->
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>          <!-- Not blocked yet (p=none) -->
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Claiming to be your domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>unknown</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

</feedback>

How to Read Your DMARC Reports: Step by Step

Step 1: Open and Decompress the Report

Reports arrive attached to an email with a subject line like Report Domain: yourdomain.com Submitter: google.com Report-ID: …. Save the attachment, decompress it (your operating system’s built-in unzip tools handle .zip and .gz fine), and open the resulting .xml file in any text editor. 

For anything beyond a quick look, upload it to our DMARC Report Analyzer tool instead of reading raw XML to analyze the data in depth in a human-readable format.

Step 2: Identify the Reporting Organization

Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.

Step 3: Check Your Published Policy

Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.

Step 4: Review Each Record (Sending Source)

For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.

Step 5: Categorize Each Source

Sort every source into one of three buckets:

1. Legitimate and passing: no action needed.
2. Legitimate but failing: needs fixing (see the action framework below).
3. Unknown and sending: potential spoofing; monitor the volume and consider advancing your policy if it is high.

Reading DMARC Reports at Scale: Tools and Automation

Once reports arrive daily from multiple providers, manual XML reading becomes impractical. A domain sending to Gmail, Outlook, and Yahoo users gets at least three reports a day, every day, and reading each one by hand does not scale past the first week. Automated parsing is the industry standard for a reason.

For a quick one-off check, free tools like PowerDMARC’s DMARC Report Analyzer let you upload a raw XML file and read its contents in a human-readable format without opening a text editor.

For ongoing monitoring at scale, a dedicated platform handles everything automatically: normalizing reports from every provider into a single view, alerting you when an unknown sender appears, retaining history, and producing audit-ready exports. 

For PowerDMARC users, our reporting dashboard does all of this across single and multi-domain environments, so the analysis happens continuously rather than only when you remember to check.

• All your reports in one place: Instead of dozens of separate XML files scattered across an inbox, every report from every provider is normalized into a single view.
• Coverage across every domain: For teams managing more than one domain, that consolidation extends across the whole portfolio, so a single dashboard covers every domain you are responsible for.
• Historical data, not just snapshots: Retained history lets you track your pass rate week over week, confirm that a fix to a failing sender actually held, and spot a slow rise in suspicious activity before it becomes an incident.
• Filtering and search: Isolate a specific sending source or failure type instead of scanning every record by hand.
• Alerting on new senders: Get notified when a new unauthorized sender appears, so you are not waiting for the next manual review to catch it.
• Audit-ready export: Produce exportable reports for compliance reviews and stakeholder reporting.

What to Do With Your DMARC Reports

Reading the report is step one. Taking action is what actually protects your domain. Work through the following in order whenever you review a fresh batch of reports.

Fix Legitimate Senders That Are Failing

If a sender you recognize (your ESP, CRM, helpdesk, or newsletter platform) shows dkim=fail or spf=fail:

1. For SPF failures: add the sender’s IP range or include: mechanism to your SPF record, then re-check with our SPF Checker.
2. For DKIM failures: ask the provider to enable custom DKIM signing for your domain and publish the key they give you, then verify with our DKIM Checker.

Identify and Monitor Unknown Senders

An IP you do not recognize sending mail as your domain could be a tool a team adopted without telling anyone, a legitimate forwarding service, or an active spoofing attempt. Low volume from an unknown IP is common and low risk. High volume from an unknown IP is a strong spoofing signal, and that is the case where advancing your policy to quarantine or reject actively stops the abuse.

Track Your Pass Rate Over Time

Your DMARC pass rate is the percentage of mail that passes DMARC authentication. At p=none it does not affect delivery, but it tells you how ready you are to enforce. Aim for a pass rate above 95% across all legitimate senders, sustained, before you tighten your policy. Monitor it weekly for at least two to four weeks rather than reacting to a single day.

Decide When to Advance Your Policy

Move to p=quarantine when all three readiness checks hold:

1. All known legitimate senders show DMARC pass.
2. No unexpected high-volume senders appear in your reports.
3. The pass rate has stayed above 95% consistently.

Move to p=reject when those same conditions hold for one to two weeks at quarantine with no surprises. The full policy progression is covered in our DMARC setup guide.

PowerDMARC automates this entire analysis. Our platform tracks pass rates, identifies senders by name instead of IP, and alerts you the moment a new unauthorized sender shows up, so the readiness decision is made for you rather than reconstructed from raw XML.

Why Am I Not Receiving DMARC Reports?

If you published a record with rua= set but no reports have arrived, one of these six causes is almost always responsible.

Issue 1: No rua= tag in your DMARC record. This is the most common cause. Without rua=, you have explicitly opted out of receiving reports. Fix: add rua=mailto:[email protected] to your record and confirm with our DMARC Checker.

Issue 2: Wrong or invalid email address. A typo, a non-existent inbox, or a full mailbox will silently drop reports. Fix: verify the rua= address can actually receive mail by sending it a test message.

Issue 3: External reporting destination not authorized. If your rua= points to an address on a different domain than your DMARC record (your domain is company.com but rua= points to [email protected]), the external domain must publish an authorization record at _report._dmarc.reportingservice.com containing v=DMARC1. Without it, reports are dropped. Most DMARC platforms handle this for you automatically.

Issue 4: You have published a new record, but the DNS has not propagated yet. Reports start arriving 24 to 48 hours after your record goes live globally, so to fix this, confirm propagation with our DNS Propagation Checker.

Issue 5: Reports are landing in spam. Reports come as compressed attachments from automated senders and often get filtered. To fix this, check your spam folder and whitelist the report senders ([email protected], [email protected]).

Issue 6: No email has been sent yet. Reports only exist when your domain has actually sent mail that reached a provider. If nothing has gone out since you published the record, there is nothing to report yet.

RFC 9990: The 2026 Aggregate Report Standard

As of May 2026, RFC 9990 governs the format and delivery of DMARC aggregate reports, taking over the reporting role that used to live inside RFC 7489. The XML schema is backward-compatible (existing parsers and the reports you already receive continue to work), and the main change is formal standardization of the reporting format and daily cadence. 

For a full breakdown of the latest updates, you can refer to our DMARC RFC 9989/9990/9991 guide. 

Frequently Asked Questions

What is a DMARC report?

A DMARC report is a daily XML file sent by receiving mail servers to the address in your rua= tag, summarizing every IP that sent email from your domain and whether SPF and DKIM passed or failed for each. Providers like Google, Microsoft, and Yahoo generate them whenever they receive mail claiming to come from your domain. They are the primary tool for monitoring your domain’s email authentication status.

What is the difference between RUA and RUF in DMARC?

RUA (aggregate) reports are daily XML summaries covering all email activity from your domain. RUF (failure) reports are per-message failure notifications that can contain individual email header data. Most major providers, including Google, Microsoft, and Yahoo, no longer send failure reports due to privacy constraints, so aggregate reports are more common and globally supported.

How often are DMARC reports sent?

Most providers send one aggregate report every 24 hours. Because each receiving mail server sends its own report, you get one from every provider whose users received your mail, so a domain sending to Gmail, Outlook, and Yahoo users should expect at least three reports per day.

How do I read a DMARC XML report?

A DMARC XML report has three main sections: report_metadata (who sent it and the time period), policy_published (your DMARC record as evaluated), and records (one entry per sending IP with its SPF and DKIM results). For a practical walk-through, you can see the XML example earlier in this guide. However, most IT teams use an automated analyzer that identifies senders by name rather than reading raw XML.

Why am I getting DMARC reports from organizations I don’t recognize?

Any mail server that receives email claiming to come from your domain sends a report if you have rua= configured. That includes small ISPs, corporate mail gateways, and international providers your recipients use, not just Google and Microsoft. Receiving reports from unfamiliar organizations is normal and simply means those servers handled mail that appeared to come from your domain.

• About
• Latest Posts

Maitham Al Lawati

Cybersecurity Expert, CEO at PowerDMARC

Maitham is a tech entrepreneur, cybersecurity expert, CEO and Founder of PowerDMARC with 15+ years of industry experience. Maitham holds a Global MBA from the University of Manchester and various professional certifications including CISSP, CISM, CRISC, and ISC2 CCSP.

Latest posts by Maitham Al Lawati (see all)

• How to Read DMARC Reports: A Complete Guide to RUA & RUF - June 10, 2026
• What Is DMARC? Definition, How It Works, and Why It Matters - April 28, 2026
• Email Phishing and DMARC Statistics: 2026 Email Security Trends - January 6, 2026