Home / Blog / Reading DMARC Aggregate Reports: What the XML Is Actually Telling You

Reading DMARC Aggregate Reports: What the XML Is Actually Telling You

Email Security By Jordan Martinez 9 min read

You published a DMARC record with p=none and a rua address. Reports started arriving. You opened one, saw a wall of XML, and closed it. This is the most common DMARC implementation pattern.

The aggregate reports are telling you something useful: which sources are sending mail claiming to be from your domain, whether those messages pass SPF and DKIM, and whether they align with your domain. That data is how you safely move from p=none (monitor only) to p=quarantine or p=reject (enforce).

Here's how to read the XML and what it's telling you.

What DMARC Aggregate Reports Are

DMARC aggregate reports (RUA, "reports of aggregate data") are daily XML documents sent by receiving mail servers to the address you specify in your DMARC record. Each report covers a 24-hour window and summarizes authentication results for all messages claiming to be from your domain.

The report comes from the recipient's mail system (Gmail, Outlook, Yahoo, etc.), not from your own infrastructure. It tells you what they saw when mail claiming to be from your domain arrived at their servers.

Reports don't contain message content or subject lines. They contain authentication data: IP address, volume, SPF result, DKIM result, alignment status.

The Structure of an Aggregate Report

A typical report has three sections: report metadata, policy published, and per-source records.

Report Metadata

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1714521600</begin>
      <end>1714607999</end>
    </date_range>
  </report_metadata>

org_name tells you who sent the report. date_range gives you the reporting window in Unix timestamps. The begin and end times usually cover a rolling 24-hour period, though some senders use UTC midnight to midnight.

Policy Published

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

This is the DMARC policy the receiving server saw when it queried your DNS. adkim and aspf are alignment modes: r for relaxed (subdomain alignment allowed), s for strict (exact domain match required). p is your policy for the organizational domain, sp is your subdomain policy.

If the policy shown here doesn't match what you think you published, either the report is old or your DNS isn't propagating correctly.

Per-Source Records

  <record>
    <row>
      <source_ip>203.0.113.45</source_ip>
      <count>237</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>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

This is the actionable data. Each <record> block represents a unique combination of source IP and authentication results.

  • source_ip: The IP address that sent the messages.
  • count: How many messages came from this IP with these results.
  • policy_evaluated: Whether the message passed DMARC. dkim and spf here mean "did this message pass DMARC via DKIM or SPF?" (not just "did DKIM/SPF pass?").
  • disposition: What the receiver did with the message. none means no action (your policy is p=none). quarantine or reject means the message was subject to policy enforcement.
  • auth_results: The raw SPF and DKIM results. result can be pass, fail, neutral, softfail, etc.

What Each Field Means

DMARC pass requires two things:

  1. Authentication pass: The message must pass either SPF or DKIM (or both).
  2. Alignment: The domain that passed authentication must align with the From: header domain (the domain in <header_from>).

A message can pass SPF and DKIM but still fail DMARC if neither domain aligns with the From: header.

SPF alignment:

The <domain> in the <spf> section is the domain from the SMTP MAIL FROM (envelope sender). For SPF to align, this domain must match the <header_from> domain (in relaxed mode, organizational domain match is sufficient).

If you see <spf><result>pass</result> but <policy_evaluated><spf>fail</spf>, that means SPF passed but didn't align.

DKIM alignment:

The <domain> in the <dkim> section is the d= domain from the DKIM signature. For DKIM to align, this domain must match the <header_from> domain.

If you see <dkim><result>pass</result> but <policy_evaluated><dkim>fail</dkim>, that means the DKIM signature validated but the signing domain didn't align.

Spotting Sources That Are Failing Alignment

Look for records where <spf> and <dkim> in <policy_evaluated> are both fail. These are sources sending mail with your domain in the From: header but failing DMARC.

Common patterns:

Legitimate service with wrong configuration:

<source_ip>198.51.100.10</source_ip>
<count>42</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
<auth_results>
  <dkim>
    <domain>sendgrid.net</domain>
    <result>pass</result>
  </dkim>
  <spf>
    <domain>sendgrid.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

This is a third-party sender (SendGrid) that passed its own SPF/DKIM but didn't align with your domain. The fix: configure the service to DKIM-sign with your domain, or update your SPF record and configure the service to use your domain in the envelope sender.

Forwarded mail:

<source_ip>203.0.113.99</source_ip>
<count>3</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>
<auth_results>
  <dkim>
    <domain>example.com</domain>
    <result>pass</result>
  </dkim>
  <spf>
    <domain>forwarder.example.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

DKIM passed and aligned, SPF failed because the envelope sender changed during forwarding. DMARC still passed (only one mechanism needs to align). This is fine.

Spoofed mail:

<source_ip>198.51.100.200</source_ip>
<count>87</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
<auth_results>
  <spf>
    <domain>example.com</domain>
    <result>fail</result>
  </spf>
</auth_results>

SPF failed, no DKIM signature. The IP isn't in your SPF record and there's no valid DKIM signature. This is unauthorized mail. When you move to p=quarantine or p=reject, this traffic will be blocked.

Using the Data to Tighten Your Policy

Start with p=none and collect reports for at least two weeks. A month is better. You want to see all your legitimate sending sources.

  1. Identify all source IPs with passing DMARC. These are already compliant. No action needed.
  2. Identify sources that are failing alignment. Look up the IPs (WHOIS, reverse DNS). Correlate with known services (marketing platform, support ticketing system, HR system, etc.).
  3. Fix or authorize failing sources. Either update SPF, configure DKIM signing with your domain, or accept that the source can't align and migrate to a service that can.
  4. Watch the failure volume drop. As you fix sources, the number of records with <spf>fail</spf><dkim>fail</dkim> should decrease.
  5. When failure volume is low and all legitimate sources pass, move to p=quarantine. This tells receivers to treat unauthenticated mail as suspicious.
  6. Monitor quarantine policy for a few weeks. Watch for complaints from users about missing mail.
  7. Move to p=reject. This tells receivers to block unauthenticated mail entirely.

Don't skip steps. Going from p=none to p=reject without analysis will break legitimate mail if you have misconfigured services.

Parsing the XML

Most people don't read the raw XML. They parse it with a script or use a DMARC reporting service.

If you're parsing it yourself:

  • Extract all <record> blocks.
  • Filter for records where both <spf> and <dkim> in <policy_evaluated> are fail.
  • Reverse-lookup the <source_ip> to get a hostname.
  • Aggregate by IP or by ASN to identify patterns.

mrdns.com provides free tools for email authentication: SPF checker, DKIM checker, DMARC checker, and an email health check that grades your overall SPF+DMARC configuration. There are also SPF and DMARC generators for building records.

If you're already monitoring your infrastructure with RBL Monitoring, adding DMARC report analysis to your workflow is a logical next step.

What Good Reports Look Like

When your DMARC implementation is mature, reports show high pass rates, low failure counts, and no unknown source IPs. A well-configured domain will have 98%+ of mail passing DMARC, with failures limited to forwarded mail and low-volume spoofing attempts.

The goal isn't zero failures. The goal is 100% of your legitimate mail passing and all unauthenticated mail blocked at p=reject.

Start reading your reports. The data is there, and it's more useful than you think.

Back to Blog