Reading DMARC XML Reports: What Every Field Means and How to Spot Problems

DMARC aggregate reports are XML files most people never open — here's how to read them

DMARC reports are powerful diagnostic tools dressed up in one of the least accessible formats possible. An aggregate report is a gzipped XML file that arrives by email, containing detailed authentication results from every major ISP. Opening the raw XML is feasible; interpreting it correctly requires knowing what each field means.

What aggregate reports contain

A DMARC aggregate report (sent to the address in your rua= tag) covers a 24-hour period of email sent from your domain as observed by the receiving server. For each observed sending source, the report shows:

• The source IP address
• The number of messages sent from that IP
• Whether SPF passed or failed, and whether it aligned
• Whether DKIM passed or failed, and whether it aligned
• The disposition applied (none/quarantine/reject)
• The policy requested by your DMARC record

The XML structure

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678</report_id>
    <date_range>
      <begin>1718064000</begin>    <!-- Unix timestamp -->
      <end>1718150400</end>
    </date_range>
  </report_metadata>
  
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.128.100</source_ip>
      <count>1247</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  
  <!-- additional records... -->
  
</feedback>

Reading each field

source_ip: the IP address that sent the email. Look this up to identify the sending service. Use the IP in the reverse DNS lookup or WHOIS to identify the ESP.

count: number of messages from this IP during the reporting period. High counts from known services are expected. Unexpected counts from unfamiliar IPs need investigation.

disposition: what the receiving server actually did with failing messages:

• none — no action taken (either everything passed, or policy is p=none)
• quarantine — sent to spam/junk
• reject — rejected

dkim and spf in policy_evaluated: the DMARC alignment result — did DKIM and SPF pass AND align with the From: domain? This is the DMARC outcome, separate from whether the raw authentication passed.

auth_results section: the raw authentication results — what actually happened with SPF and DKIM independently, including which domain the DKIM was signed with and which SPF domain matched.

Common patterns and what they mean

Everything passing (expected state)

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>pass</spf>
</policy_evaluated>

This IP is correctly authenticated. No action needed.

SPF fail, DKIM pass — still passes DMARC

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

DMARC only requires one of SPF or DKIM to pass and align. This is common for forwarded email (SPF breaks on forwarding; DKIM survives). As long as DKIM passes, DMARC passes.

DKIM pass but SPF and DKIM both fail DMARC

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
<auth_results>
  <dkim>
    <domain>mailprovider.com</domain>   <!-- Provider's domain, not yours -->
    <result>pass</result>
  </dkim>
</auth_results>

DKIM physically passes — the signature is valid — but the d= domain in the signature is mailprovider.com, not yourdomain.com. DMARC requires the DKIM domain to align with the From: header domain. This service needs to be configured to sign with your domain.

Unknown IP sending your domain

<row>
  <source_ip>45.123.67.89</source_ip>   <!-- Unrecognised IP -->
  <count>3</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>

An IP you don't recognise is sending email claiming to be from your domain. This could be:

• A forgotten service (forgotten ESP, old automation)
• A misconfiguration somewhere
• Spoofing (someone trying to impersonate your domain)

If at p=reject, this would be rejected. At p=none, it's passing. Investigate the IP (reverse DNS, WHOIS).

Tools that make DMARC reports readable

Reading raw XML works for occasional troubleshooting. For ongoing monitoring, these tools parse and visualise the reports:

Free options:

• Postmark DMARC Digests (free, email digest): sends weekly human-readable summaries
• DMARC Analyzer free tier: limited volume, basic visualisation
• dmarcdigests.com: free basic processing

Paid options (for high volume or detailed analysis):

• dmarcian: the most widely used professional tool
• Valimail: enterprise-focused
• EasyDMARC: strong dashboard

Self-hosted options:

• parsedmarc: Python tool that parses reports and pushes to Elasticsearch for custom dashboards

Interpreting the policy_published section

<policy_published>
  <domain>yourdomain.com</domain>
  <p>none</p>     <!-- Current policy -->
  <sp>none</sp>   <!-- Subdomain policy -->
  <pct>100</pct>
</policy_published>

This section shows what policy your DMARC record specifies. It's a sanity check — if this shows p=none but you thought you'd moved to p=reject, your DNS change hasn't propagated or was applied to the wrong record.

How to use the DMARC Lookup on sadiqbd.com

1. Enter your domain — queries _dmarc.yourdomain.com
2. Read the current policy — confirms what receiving servers will use
3. Check the rua= address — confirms where aggregate reports are being sent

Frequently Asked Questions

How long does it take to receive the first DMARC aggregate report? Reports are sent daily, typically within 24–48 hours of adding the rua= tag to your DMARC record. Major providers (Gmail, Outlook, Yahoo) send reports consistently. Smaller ISPs may send reports less frequently or not at all.

My DMARC report shows thousands of failures from the same IP. What does that mean? Check whose IP it is. If it's a legitimate sending service, configure that service to sign DKIM with your domain. If it's unrecognised, someone may be attempting to impersonate your domain — this is exactly the problem DMARC p=reject addresses.

Is the DMARC Lookup free? Yes — completely free, no sign-up required.

DMARC aggregate reports contain the ground truth about your email authentication: who is sending email as your domain, whether authentication is working, and what receiving servers are doing about failures. Reading them correctly transforms them from opaque XML into actionable intelligence.

Try the DMARC Lookup free at sadiqbd.com — check your domain's current DMARC policy, rua address, and enforcement level instantly.