Blog

How to Read DMARC Aggregate Reports (RUA): Step-by-Step Guide (2026)

Master DMARC aggregate report (RUA) XML analysis. Learn how to decode tags, evaluate SPF and DKIM alignment, identify spoofing, and safely enforce p=reject.

How to Read DMARC Aggregate Reports (RUA): Step-by-Step Guide (2026)

> TL;DR: DMARC Aggregate Reports (RUA) are daily XML documents sent by inbox providers (like Google, Microsoft, and Yahoo) showing every server sending email on behalf of your domain. They reveal source IP addresses, message counts, and pass/fail statuses for SPF and DKIM authentication. Reading these reports allows domain owners to identify unauthorized spoofing, fix misconfigured third-party email tools, and safely transition from a monitoring policy (p=none) to strict enforcement (p=quarantine or p=reject).

What Are DMARC Aggregate Reports (RUA)?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) relies on feedback loops to give domain owners full visibility into their email ecosystem. Without DMARC reporting, sending an email is a one-way operation—you transmit messages through your mail server or email service provider (ESP), but you have no native visibility into whether receiving inbox providers authenticated, accepted, quarantined, or rejected those messages.

DMARC aggregate reports, designated by the rua= tag in your DMARC DNS record (for example, rua=mailto:dmarc-reports@yourdomain.com), solve this visibility gap. Sent typically once every 24 hours by receiving mail transfer agents (MTAs), aggregate reports compile high-level statistical summaries of all traffic claiming to originate from your organizational domain or subdomains.

Aggregate (RUA) vs. Forensic (RUF) Reports

It is vital to distinguish aggregate feedback from forensic feedback:

| Feature | Aggregate Reports (RUA) | Forensic / Failure Reports (RUF) | | :--- | :--- | :--- | | Primary Focus | Daily statistical overview of all domain activity | Real-time payload sample for individual failed messages | | Data Format | Standardized XML compressed in .zip or .gz archives | Redacted email header and MIME message sample | | Privacy Compliance | Fully compliant with GDPR and HIPAA (no PII or subject lines) | Frequently suppressed by major ISPs due to privacy risks | | Primary Use Case | Inventorying senders, auditing SPF/DKIM, enforcing DMARC | Debugging specific header forgery or DKIM key signature errors | | ISP Adoption | Universally supported by Google, Yahoo, Microsoft, Apple | Restricted or unsupported by major consumer mailbox providers |

Aggregate reports do not contain sensitive message content, personal recipient information, or email body text. Instead, they provide structured metadata: which IP addresses sent mail using your domain, how many messages each IP transmitted, whether those messages passed SPF and DKIM checks, and what policy action the receiving mailbox provider applied.

Before you can analyze incoming aggregate data, your domain must publish a valid DMARC record in DNS with a designated aggregate report destination. If you have not yet generated your foundational authentication records, review our comprehensive SPF, DKIM, and DMARC setup guide to establish your base DNS framework.

Anatomy of a DMARC Aggregate XML File: Key Tags Decoded

how to read dmarc aggregate reports dmarc aggregate reports section ms95k01cf17391

When you open a raw DMARC aggregate attachment, you are greeted with a structured XML file. While raw XML looks intimidating at first glance, every RUA document follows a standardized schema defined in RFC 7489. Understanding the core XML node hierarchy allows you to manually parse or programmatically extract actionable telemetry.

An aggregate report consists of two main top-level blocks: metadata describing the report generator and publishing domain (<report_metadata> and <policy_published>), followed by one or more detailed traffic records (<record>).

1. Header Metadata Nodes

The top section of the XML file identifies who generated the report, the reporting timeframe, and the exact DMARC policy active on your domain during that period:

<feedback>
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466563</extra_contact_info>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1704067200</begin>
      <end>1704153599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</adkim>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  • <org_name>: The mailbox provider or gateway that compiled the report (e.g., Google, Microsoft, Yahoo, Comcast).
  • <date_range>: Epoch timestamps marking the start and end of the 24-hour reporting window.
  • <policy_published>: Confirms your domain’s DMARC policy at the time of evaluation. <p> reflects your main domain policy, <sp> covers subdomains, <adkim> and <aspf> show alignment strictness (r for relaxed, s for strict), and <pct> shows the enforcement percentage applied.

2. Record Nodes (Traffic Summary)

The body of the report contains <record> blocks. Each record groups email streams sharing identical source IPs, evaluation results, and header domains:

  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>
      <count>1450</count>
      <policy_evaluated>
        <disposition>none</pdisposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <result>pass</result>
        <selector>sg2026</selector>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>
  • <source_ip>: The IPv4 or IPv6 address of the server that handed off the message to the receiving MTA.
  • <count>: The total volume of messages sent from this IP address matching this exact result during the reporting window.
  • <disposition>: The action taken by the receiving MTA (none = delivered to inbox/spam based on local rules, quarantine = sent to spam/junk folder, reject = blocked at SMTP gateway).
  • <auth_results>: Raw underlying authentication verification results for SPF and DKIM.

Crucially, DMARC evaluation requires both authentication and alignment. A raw SPF or DKIM pass in <auth_results> is insufficient if the domain authenticated does not match the domain visible in the email’s From: header (<header_from>).

Step-by-Step: How to Read and Interpret DMARC XML Data

Reading raw XML directly in a text editor becomes cumbersome as message volume grows across multiple sending services. To systematically evaluate aggregate reports, practitioners follow a structured four-step triage methodology.

Step 1: Group Message Volume by Source IP

The first objective in analyzing an aggregate report is identifying all unique source_ip entries and summing their associated count values. This produces an inventory of every mail server transmitting messages under your domain name.

For instance, a daily report from Google might contain 15 distinct record blocks representing 12,000 total emails. By sorting records by source_ip, you can immediately categorize your traffic into major pools:

  1. Corporate Mail Infrastructure: Google Workspace or Microsoft 365 server blocks sending routine employee email.
  2. Authorized Third-Party ESPs: Dedicated sending IPs utilized by platforms like the Sendgrove email marketing platform for newsletter and automated campaign delivery.
  3. Transaction and Operational Services: Application gateways, web hosts, customer support tools, and e-commerce notification systems.
  4. Uncategorized or Suspicious Infrastructure: External IPs, residential ISPs, or unknown cloud servers transmitting mail with your domain in the From line.

Step 2: Perform Reverse DNS (PTR) Lookups

An isolated IP address such as 203.0.113.19 provides limited context on its own. To determine ownership, execute a reverse DNS PTR record query using command-line utilities or network diagnostics:

dig -x 203.0.113.19 +short
# Output: mail-out1.sendgrove.com.

The PTR hostname frequently reveals the operator behind the IP address. A PTR result ending in .sendgrove.com, .google.com, or .outbound.protection.outlook.com immediately validates that the traffic originates from a legitimate cloud service provider rather than a malicious actor.

Step 3: Evaluate Policy Evaluated vs Authentication Results

The core of DMARC interpretation lies in comparing what raw authentication checks yielded against how DMARC evaluated alignment.

DMARC requires that at least one authentication protocol (SPF or DKIM) passes both its raw cryptographic or record check AND aligns with the From header domain.

| Scenario | SPF Result | SPF Alignment | DKIM Result | DKIM Alignment | Overall DMARC Evaluation | Disposition | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | Fully Authenticated | Pass | Aligned | Pass | Aligned | PASS | none | | DKIM-Only Alignment | Pass | Unaligned | Pass | Aligned | PASS | none | | SPF-Only Alignment | Pass | Aligned | Fail/None | Unaligned | PASS | none | | Unaligned Third Party | Pass | Unaligned | Pass | Unaligned | FAIL | none (if p=none) | | Spoofed / Unauthorized | Fail | Unaligned | Fail | Unaligned | FAIL | quarantine / reject |

Notice that as long as either SPF or DKIM is aligned and passing, the overall DMARC policy evaluation returns a PASS, protecting your legitimate mail from being rejected.

SPF Alignment vs. DKIM Alignment in Aggregate Telemetry

One of the most common points of confusion in aggregate reports is why mail from a legitimate provider like marketing software or transactional hosts fails DMARC even when the provider promises high deliverability. The culprit is almost always domain alignment.

How SPF Alignment Works in RUA Telemetry

SPF authenticates the sending server's IP address against the Return-Path domain (also known as the envelope-from domain), which receives bounce notifications.

In DMARC aggregate reports:

  • Return-Path shows the envelope domain evaluated by the receiving mail server.
  • Header From shows the domain visible to the end recipient in their email client.

If your marketing provider uses their own domain for bounces (e.g. bounces.thirdparty-esp.com), raw SPF passes because the sending server IP matches thirdparty-esp.com. However, DMARC evaluates SPF as unaligned because bounces.thirdparty-esp.com does not match yourdomain.com.

Header From:  yourdomain.com
Return-Path:  bounces.thirdparty-esp.com  --> Raw SPF PASS, but DMARC Alignment FAIL

To fix SPF alignment, configure a custom return-path CNAME record (such as bounces.yourdomain.com) pointing to your provider's infrastructure.

How DKIM Alignment Works in RUA Telemetry

DKIM attaches a cryptographic digital signature to the email header. The receiving mail server verifies this signature by fetching the public key published in your domain's DNS selector record.

In DMARC aggregate reports:

  • DKIM domain indicates the domain specified in the d= tag of the email's cryptographic signature.
  • Header From represents the recipient-facing domain.

When you sign outgoing messages using a custom DKIM selector (such as sg2026._domainkey.yourdomain.com), the d= tag matches yourdomain.com.

Header From:  yourdomain.com
DKIM d= Tag:  yourdomain.com  --> Raw DKIM PASS AND DMARC Alignment PASS

Why DKIM Alignment Is Superior for Cloud Senders

Relying solely on SPF alignment introduces severe deliverability vulnerabilities. When email is forwarded—such as through automated inbox rules, mailing lists, or security gateways—the receiving server changes the Return-Path header, causing SPF to fail authentication.

By contrast, a DKIM signature remains attached to the email headers during transit. As long as the message body and signed headers are not modified in transit, DKIM signatures survive email forwarding. For this reason, email deliverability engineers treat DKIM alignment as the gold standard for DMARC compliance.

Triaging DMARC Aggregate Data: Legitimate Sends vs. Spoofing

When analyzing daily XML reports, you will inevitably encounter records showing spf=fail and dkim=fail. Before panicking, you must distinguish between benign configuration oversights and active malicious phishing campaigns.

Case 1: Unaligned Legitimate Shadow IT or SaaS Senders

A common discovery during early DMARC monitoring is shadow IT—departmental software configured by team members without IT involvement. Examples include:

  • HR platforms sending automated job offer letters from hr@yourdomain.com.
  • Customer support ticketing systems sending ticket updates from support@yourdomain.com.
  • Finance accounting platforms issuing invoices from billing@yourdomain.com.

Telemetry Indicators: The aggregate report shows high message volume (count: 500+) originating from recognizable IP blocks (e.g. AWS, Microsoft, Salesforce, or Zendesk PTR records). Both SPF and DKIM fail alignment because no custom SPF include or DKIM selector was configured for your domain.

Remediation Action: Do not block these IP addresses. Instead, contact the platform administrator to configure custom DKIM signing keys and update your SPF TXT record to include the vendor's designated include mechanism.

Case 2: Outbound Email Forwarding and Mail Relays

When recipients set up automatic forwarding (for example, forwarding user@company.com to user@gmail.com), the intermediary mail server receives the original message and re-transmits it to Google.

Telemetry Indicators: The aggregate report shows small message counts (count: 1–10) from diverse, third-party mail servers (such as university or university-relay MTAs). SPF evaluation shows spf=fail (because the relaying server IP is not in your domain's SPF record), but DKIM evaluation shows dkim=pass and dkim=aligned (because the original signature remained intact).

Remediation Action: No action required. Because DKIM passed alignment, DMARC evaluates the overall record as a PASS. This highlights why DKIM signature alignment is essential for keeping emails out of spam folders when messages traverse complex forwarding relays.

Case 3: Malicious Phishing and Domain Spoofing

True domain spoofing occurs when cybercriminals attempt to launch BEC (Business Email Compromise) or consumer phishing attacks using your exact domain name.

Telemetry Indicators: The aggregate report shows low-to-moderate message spikes (count: 50–5,000) from suspicious IP ranges with generic or non-existent PTR records (e.g., residential broadband networks or unverified hosting providers). Both SPF and DKIM fail raw verification and fail alignment completely (disposition=none while p=none is active).

<record>
  <row>
    <source_ip>198.51.100.99</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>phisher.com</domain><result>fail</result></dkim>
    <spf><domain>phisher.com</domain><result>fail</result></spf>
  </auth_results>
</record>

Remediation Action: This telemetry confirms active domain abuse. While you cannot stop bad actors from sending mail from their own servers, upgrading your DMARC policy to p=quarantine or p=reject forces receiving mailbox providers to automatically drop these spoofed messages before they reach recipient inboxes.

Before moving to strict enforcement, ensure your lists are authenticated and scrubbed so legitimate notification sequences aren't disrupted. Utilizing built-in email validation during list acquisition ensures invalid or toxic contact records do not generate artificial bounces or cloud your deliverability telemetry.

How to Use RUA Telemetry to Move from p=none to p=reject Safely

The ultimate goal of analyzing DMARC aggregate reports is establishing total domain enforcement (p=reject). However, publishing p=reject prematurely without inspecting RUA reports risks blocking legitimate business emails. Follow this four-stage transition timeline guided by report telemetry.

Stage 1: p=none (Monitoring)  -->  Stage 2: p=quarantine; pct=25  -->  Stage 3: p=quarantine; pct=100  -->  Stage 4: p=reject

Stage 1: Initial Discovery Phase (p=none)

Publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; and monitor reports for 2 to 4 weeks.

  • Aggregate report goal: Achieve >99% DMARC pass rate for all legitimate sending sources.
  • Actions: Inventory every IP address sending as your domain. Authenticate all secondary tools (CRMs, helpdesks, marketing automation) with DKIM signatures and SPF includes.

Stage 2: Initial Enforcement Ramp-Up (p=quarantine; pct=25)

Once legitimate sources show zero unaligned traffic in RUA reports, update your record to apply quarantine enforcement to a 25% sample of failing mail:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com;
  • Aggregate report goal: Review reports daily for 7 days to verify that zero legitimate traffic is assigned disposition=quarantine.
  • If an legitimate source was missed, its failed messages will only affect 25% of its volume, giving you time to correct DKIM/SPF alignment without a total delivery outage.

Stage 3: Full Quarantine Enforcement (p=quarantine; pct=100)

Increase pct incrementally to 50%, 75%, and finally 100%:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com;

At p=quarantine; pct=100;, receiving mailbox providers automatically redirect unaligned spoofed emails into the spam or junk folder. Monitor RUA reports for 14 days at this level to ensure no legitimate mail streams are trapped in junk folders.

Stage 4: Full Rejection Enforcement (p=reject)

When RUA reports confirm that 100% of legitimate sending sources pass DMARC alignment, update your DMARC policy to full rejection:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com;

At p=reject, mailbox providers like Gmail, Yahoo, and Outlook reject unauthenticated emails at the SMTP connection layer. Spoofed phishing messages are dropped instantly, protecting your brand reputation and shielding customers from phishing.

Common DMARC Reporting Pitfalls and Edge Cases

Even experienced email administrators encounter unexpected anomalies when reviewing DMARC aggregate reports. Understanding these edge cases prevents false alarms and improper configuration changes.

1. The 10-DNS-Lookup Limit for SPF

RFC 7208 limits SPF evaluation to a maximum of 10 mechanisms that trigger DNS queries (such as include, a, mx, ptr, and exists). If your SPF record exceeds 10 DNS lookups, receiving mail servers return a PermError (spf=permerror).

In DMARC aggregate reports, an SPF PermError results in spf=fail. If you notice that adding a new vendor's SPF include suddenly causes all SPF checks to fail in RUA reports, audit your SPF record for DNS mechanism limits. To resolve this, transition to DKIM signing for third-party tools or implement SPF macros / flattening.

2. Subdomain Policy Inheritance (sp= Tag)

By default, an organizational domain's DMARC policy (p=) automatically applies to all subdomains unless a explicit subdomain policy (sp=) is defined.

If attackers spoof news.yourdomain.com or mail.yourdomain.com while your main policy is p=reject, receiving MTAs check for an sp= tag. If no sp= tag is present, they enforce p=reject on the subdomain. However, if you explicitly published p=reject; sp=none; during testing, subdomains remain unprotected against spoofing.

3. Multi-CDN and Third-Party Host Routing Differences

Large enterprise environments that route email through cloud security gateways (such as Proofpoint, Mimecast, or Cisco IronPort) before external delivery may see reports generated by internal or intermediary hop MTAs. Always verify whether a failing IP belongs to an outbound security proxy before removing it from your allowed infrastructure list.

For teams scaling outbound campaign volume across multiple domains, reviewing Sendgrove pricing plans provides transparent access to dedicated sending IPs and automated domain authentication setup tools that simplify DMARC telemetry management.

FAQ

What is the difference between RUA and RUF in DMARC?

RUA provides daily aggregate statistical summaries of all email volume sent under your domain, detailing source IPs, message counts, and SPF/DKIM alignment results without containing private message content. RUF provides real-time forensic failure reports containing redacted headers and sample message data for individual failed emails. Most major ISPs support RUA while restricting RUF due to privacy regulations like GDPR.

How often are DMARC aggregate reports sent?

Receiving mailbox providers typically generate and transmit aggregate reports once every 24 hours. The reporting window is defined by the <date_range> node in the XML file, usually covering midnight-to-midnight UTC. Some providers may send reports more frequently or split large report files into multiple daily archives.

Do I need a paid tool to read DMARC aggregate XML reports?

While you can unzip .xml.gz files and inspect them manually using a text editor or custom Python scripts, processing hundreds of daily XML files across multiple domains becomes time-consuming. Using a DMARC report visualizer or monitoring dashboard automatically parses XML files, resolves IP PTR records, and generates graphical trend charts.

Why do legitimate marketing emails fail SPF alignment in DMARC reports?

Legitimate marketing emails fail SPF alignment when the email service provider uses their own domain in the Return-Path header (e.g. bounces.esp-provider.com) while displaying your domain in the recipient-facing From: header. Although raw SPF passes for the provider's domain, DMARC requires the Return-Path domain to match the From: domain.

What should I do if I see spoofed IP addresses in my DMARC aggregate report?

If you see unauthorized IP addresses attempting to send email using your domain, check your current DMARC policy status. If your policy is p=none, receiving mail servers deliver those messages to recipients. To stop unauthorized spoofing, verify that all legitimate email sources are fully authenticated with DKIM and SPF, then upgrade your DMARC policy to p=quarantine or p=reject.

Will setting DMARC to p=reject affect my outgoing marketing emails?

Setting DMARC to p=reject will not affect your outgoing marketing emails as long as your sending service is properly configured with aligned SPF or DKIM signatures. If your marketing platform signs emails with a DKIM key matching your domain (e.g., d=yourdomain.com), your messages pass DMARC alignment and will be delivered to recipient inboxes without disruption.