Understanding DMARC Aggregate Reports

What Aggregate Reports Contain

A DMARC aggregate report is a summary of authentication results for email sent using your domain over a reporting period — typically 24 hours.

Each report tells you:

• which IP addresses sent email claiming to be from your domain
• how many messages each IP sent
• whether SPF passed or failed for each source
• whether DKIM passed or failed for each source
• whether DMARC alignment passed or failed
• what policy the receiver applied (none, quarantine, or reject)

What aggregate reports do not contain: message bodies, subject lines, recipient addresses, headers, or any message content. The data is purely about authentication results at the infrastructure level. You will not see who sent what to whom — only whether the sending infrastructure was properly configured.

This distinction matters for privacy and for understanding what the reports are useful for. Aggregate reports are a diagnostic tool for your sending infrastructure. They are not a mail archive.

Who Sends Reports and When

Any mailbox provider that processes email using your domain can send DMARC aggregate reports. In practice, the major contributors are Google (Gmail and Google Workspace), Microsoft (Outlook.com and Microsoft 365), Yahoo, and a handful of other large providers.

Reports are sent to the address in your DMARC record's rua= tag. The reporting frequency is typically once per 24 hours, covering the previous day's traffic. The exact timing varies by provider — some send at midnight UTC, others at other times. You have no control over the schedule.

Low-volume senders may not send reports at all, or may send infrequently. This is expected behavior and does not indicate a problem with your DMARC configuration.

XML Structure Walkthrough

Aggregate reports are XML files, often delivered as gzip-compressed .xml.gz attachments. Here is a minimal example showing the structure:

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

  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1743984000</begin>
      <end>1744070400</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>847</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>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

</feedback>

<report_metadata>

Identifies the reporting organization and the time period covered.

• org_name — who sent this report (e.g., google.com, microsoft.com, yahoo.com)
• report_id — unique identifier for this report, used for deduplication
• date_range — Unix timestamps for the start and end of the reporting period

<policy_published>

Your DMARC record as the receiver saw it when processing these messages. If this does not match what you published, there may be a DNS propagation delay or a caching issue.

• p — the policy for the organizational domain (none, quarantine, or reject)
• sp — the subdomain policy, if specified
• adkim / aspf — alignment mode: r (relaxed) or s (strict)
• pct — the percentage of failing messages the policy applies to

<record>

One record per unique combination of source IP, authentication results, and disposition. A single report may contain dozens of records.

<row>

• source_ip — the IP address that sent the email
• count — number of messages from this IP during the reporting period
• policy_evaluated — what the receiver decided based on DMARC:
  • disposition — the action taken: none, quarantine, or reject
  • dkim — DMARC DKIM alignment result: pass or fail
  • spf — DMARC SPF alignment result: pass or fail

<auth_results>

The raw authentication results before alignment is considered:

• <dkim> — which domain signed the message (domain), which selector was used (selector), and whether the signature verified (result)
• <spf> — which domain was used in the envelope sender (domain) and whether SPF passed (result)

The key distinction: auth_results shows the raw pass/fail for each mechanism. policy_evaluated shows whether those results aligned with your From: domain. You can have SPF pass in auth_results and SPF fail in policy_evaluated — that happens when SPF authenticates a different domain than your From: header.

Reading Source IPs

The source_ip field is an IP address, not a service name. To identify what is behind an IP, use two lookups:

Reverse DNS (PTR record): Look up the PTR record for the IP. A Google Workspace server might resolve to something like mail-qv1-f68.google.com. A SendGrid server might resolve to smtp.sendgrid.net. A hostname often makes the service obvious.

ASN lookup: If the PTR record is not helpful, look up the Autonomous System Number for the IP. Most major ESPs and cloud providers have their own ASNs. AS15169 is Google. AS8075 is Microsoft. AS11377 is SendGrid. An ASN lookup tells you who owns the network block even if the hostname is not informative.

The mxio DMARC Report Viewer and the DMARC Reporting dashboard both do this automatically — source IPs are matched against known ESP infrastructure and resolved to provider names where possible.

What Alignment Means in Context

DMARC passes or fails based on alignment, not just on whether SPF or DKIM passed.

For DMARC to pass, at least one of the following must be true:

1. SPF passed AND the SPF-authenticated domain aligns with the From: header domain
2. DKIM passed AND the DKIM d= domain aligns with the From: header domain

Relaxed alignment (the default, adkim=r, aspf=r): The authenticated domain and the From: domain must share the same organizational domain. mail.example.com aligns with example.com.

Strict alignment (adkim=s, aspf=s): The authenticated domain must exactly match the From: domain. mail.example.com does not align with example.com under strict mode.

The most common alignment failure is a third-party sender that passes SPF for its own domain (sendgrid.net) but not for yours (example.com). SPF passes in auth_results, DMARC SPF alignment fails in policy_evaluated. The fix is to configure the service to use a custom return-path under your domain, or to configure DKIM signing with your domain in the d= tag.

For a detailed breakdown of alignment failures and how to fix them, see DMARC Alignment Failure: Why SPF/DKIM Pass But DMARC Fails.

Common Patterns to Recognize

Authorized sender passing cleanly

source_ip: 209.85.220.41
count: 847
policy_evaluated: disposition=none, dkim=pass, spf=pass
auth_results: dkim domain=example.com result=pass, spf domain=example.com result=pass

This is what a correctly configured sender looks like. The IP is a Google server, DKIM is signing with d=example.com, SPF passes for example.com, both align. No action needed.

Authorized sender with misconfigured DKIM

source_ip: 167.89.101.45
count: 312
policy_evaluated: disposition=none, dkim=fail, spf=pass
auth_results: dkim domain=sendgrid.net result=pass, spf domain=example.com result=pass

DKIM passes but for sendgrid.net, not example.com — so DKIM alignment fails. SPF passes and aligns, so DMARC still passes overall. But this sender is one SPF change or forwarding hop away from failing entirely. The fix: configure DKIM domain authentication in SendGrid so it signs with d=example.com.

Forwarded mail failing SPF

source_ip: 8.8.8.4
count: 23
policy_evaluated: disposition=none, dkim=pass, spf=fail
auth_results: dkim domain=example.com result=pass, spf domain=forwarder.example.org result=fail

A forwarding server is relaying messages sent from your domain. Its IP is not in your SPF record, so SPF fails. But the original DKIM signature is intact and aligns with example.com, so DMARC passes. This is the expected behavior for forwarded mail — SPF breaks at the forwarding hop, DKIM survives if the message body is not modified.

Unknown / suspicious sender

source_ip: 185.234.219.12
count: 4821
policy_evaluated: disposition=none, dkim=fail, spf=fail
auth_results: dkim result=fail, spf domain=spammer.net result=fail

A high-volume source with no passing authentication, authenticating as an unrelated domain. This is likely spoofing or a phishing campaign using your domain in the From: header. At p=none, these messages were delivered. At p=reject, they would be blocked. This is exactly the traffic DMARC enforcement is designed to stop.

How mxio DMARC Reporting Handles This

Reading aggregate report XML manually is slow and error-prone. mxio does it automatically.

The DMARC Reporting dashboard ingests reports as they arrive, resolves source IPs to provider names using reverse DNS and ASN data, classifies sources into authorized/failing/forwarded/unknown/misconfigured buckets, tracks alignment rates over time, and surfaces anomalies when traffic patterns change unexpectedly.

The free DMARC Report Viewer lets you upload a single XML report and get a parsed, readable breakdown without a paid account.

For ongoing monitoring, the dashboard replaces the manual process entirely — you get the output without handling the XML.

Related Articles

• DMARC Reporting in mxio: Setup, First Data, and What To Do Next — how to connect mxio to your DMARC record
• DMARC Deployment Guide: From p=none to p=reject — the full deployment process
• Moving from p=none to p=reject — the enforcement decision
• DMARC Alignment Failure: Why SPF/DKIM Pass But DMARC Fails — alignment explained in depth
• Why Is DMARC Failing? — diagnosing failures