How to Analyze Large DMARC XML Reports (100MB+) Securely and Fix Email Deliverability

You pull your DMARC aggregate report from Google Postmaster, Microsoft SNDS, or your email provider — and the XML file is 180MB. Every online DMARC tool either refuses to load it, charges you for enterprise access, or makes you upload it to their servers. This guide shows you exactly how to analyze those large files privately, for free, and what to do with the data you find.

What Is a DMARC Aggregate Report?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on SPF and DKIM. When a receiving mail server processes a message from your domain, it checks whether SPF and DKIM pass and whether they align with the From: domain. The results of every message processed during a 24-hour window are bundled into an aggregate report — an XML file — and sent to the address specified in your rua= tag.

Every major receiving provider sends these reports: Google, Microsoft, Yahoo, Apple, and hundreds of smaller providers. If your domain sends any meaningful volume of email, you are receiving dozens or hundreds of these XML files per day.

The anatomy of a DMARC aggregate report

At the top level, every DMARC XML report contains two sections: report_metadata and policy_published, followed by one or more record elements.

<feedback>
  <report_metadata>
    <org_name>Google LLC</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567</report_id>
    <date_range>
      <begin>1751241600</begin>
      <end>1751327999</end>
    </date_range>
  </report_metadata>

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

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

Each record represents a unique combination of source IP address, authentication outcomes, and policy disposition. A single report from Google can contain thousands of records if your domain sends from many different IP addresses or uses multiple third-party services.

Why Large DMARC XML Files Are a Problem

For high-volume senders — companies sending millions of emails per month through multiple platforms — DMARC aggregate reports grow fast. Here is why:

• Record explosion: Every unique source IP gets its own record. If you use five email platforms each sending from 10 different IPs, that is 50 records per report per receiving provider.
• Multiple providers: Google, Microsoft, Yahoo, and dozens of smaller providers all send separate reports. A popular domain might receive 200+ reports per day.
• Forwarding complexity: Email forwarding creates new records with different alignment outcomes, multiplying the record count.
• Attack traffic: Active phishing or spoofing campaigns add hundreds of records from attacker IPs, inflating file sizes significantly.

The result is that production DMARC deployments routinely generate 50MB–100MB+ XML files per reporting period. Most SaaS DMARC tools enforce upload limits of 10–25MB. Enterprise tiers unlock higher limits but cost hundreds of dollars per month.

How Browser-Native Parsing Solves the File Size Problem

Traditional DMARC tools send your XML file to their servers, parse it in a backend process, store the results in a database, and show you a dashboard. This architecture creates three constraints: upload bandwidth limits, server memory limits, and the privacy problem of your authentication data sitting on someone else's infrastructure.

Browser-native parsing works differently. Modern browsers expose a DOMParser API that can parse arbitrarily large XML files in-tab. The file is read directly from disk using the FileReader API — it never leaves your device.

The entire analysis pipeline runs in your browser tab:

1. File selected via drag-and-drop or file picker
2. JavaScript reads the file using FileReader.readAsText()
3. XML is parsed using the browser's native DOMParser
4. Records are extracted and aggregated
5. IPs are looked up via WHOIS API to identify sending services
6. Results are displayed as an interactive dashboard

No bytes of your DMARC report are transmitted to any third-party server during this process.

Understanding SPF and DKIM Alignment

DMARC is often misunderstood as simply “SPF + DKIM.” The critical concept that distinguishes DMARC is alignment — and it is the most common source of DMARC failures for organizations that already have SPF and DKIM configured.

SPF alignment

SPF checks the Return-Path (envelope sender) domain against your SPF record. For DMARC, the Return-Path domain must also match theFrom: header domain. If you use a third-party email service like Mailchimp, the Return-Path might be bounce.mcsv.net— which will fail SPF alignment for your domain even if Mailchimp's SPF passes.

DKIM alignment

DKIM signs the message with a private key, embedding a d= domain tag in the signature header. For DMARC alignment, this d= domain must match the From: header domain. Most email platforms allow you to configure a custom DKIM domain — this is the correct fix for DKIM alignment failures.

Relaxed vs strict alignment

Relaxed alignment means mail.example.com aligns with example.com. Strict alignment does not. Most organizations use relaxed alignment (adkim=r; aspf=r) unless they have specific security requirements for exact-match enforcement.

Reading Your DMARC Report: What Each Field Means

When you open a DMARC aggregate report in an analyzer, you will see a table of records. Here is how to read the key columns:

policy_evaluated fields

• disposition: What the receiving server did with the message —none (delivered), quarantine (sent to spam), or reject (dropped).
• dkim: Whether DKIM both passed AND aligned with the From: domain. Possible values: pass or fail.
• spf: Whether SPF both passed AND aligned. Possible values: pass or fail.

auth_results fields

The auth_results section shows the raw authentication outcome before alignment is applied. This is useful for debugging:

• SPF result: pass, fail, softfail, neutral, temperror, or permerror
• DKIM result: pass, fail, policy, neutral, temperror, or permerror

A common failure pattern is seeing spf: pass in auth_results but spf: fail in policy_evaluated — this means SPF passed technically but the domain did not align with the From: header.

IP Intelligence: Enriching Your DMARC Data with WHOIS

Every record in a DMARC report contains a source_ip — the IP address of the server that delivered the message to the receiving provider. Raw IPs alone are almost meaningless. The diagnostic value comes from IP enrichment: resolving each IP to its owner organization, hosting provider, ASN, and country.

What WHOIS enrichment reveals

• Authorized senders you forgot about:That IP block owned by “SendGrid” is your transactional email service from 3 years ago.
• Third-party platforms with broken authentication: If your CRM is sending from its own servers but not signing with your DKIM key, you will see alignment failures attributed to their IP range.
• Unauthorized senders and spoofing attempts: IPs owned by random hosting providers, VPN services, or overseas data centers that should never be sending as your domain.
• Forwarding infrastructure: IPs from university mail servers or mailing list managers that re-send your messages with broken alignment.

Reading enriched DMARC data

When you analyze a DMARC report with DMARC Labs, each IP is enriched with:

• Organization name (e.g., “Google LLC”, “Amazon.com, Inc.”)
• ASN (Autonomous System Number)
• Country
• IP range (CIDR notation)

Cross-reference this with your known sending sources. Any IP organization you don't recognize is a candidate for investigation — either an unauthorized sender or a legitimate service that needs authentication configured.

Common DMARC Failure Patterns and How to Fix Them

Pattern 1: Third-party sender with no DKIM signing

Symptoms: DMARC fail on records from an IP range belonging to your CRM, newsletter platform, or marketing automation tool. SPF passes but DKIM fails or is absent.

Fix: Log in to the third-party platform and enable custom domain DKIM signing. You will be asked to add a CNAME or TXT record to your DNS. Once added, the platform will sign messages with a key that aligns to your domain.

Pattern 2: SPF pass but alignment failure

Symptoms: auth_results/spf: pass but policy_evaluated/spf: fail. The source IP is in your SPF record but the Return-Path domain doesn't match your From: domain.

Fix: Configure the sending platform to use a custom Return-Path domain that matches your From: domain. Alternatively, ensure DKIM is aligned so DMARC passes via the DKIM mechanism instead.

Pattern 3: Forwarding failures

Symptoms: Records from university mail servers, mailing lists, or personal email forwarders showing SPF failures. These are almost always legitimate emails being forwarded.

Fix: This is a known limitation of SPF with email forwarding. The correct long-term fix is ensuring your messages are DKIM-signed (DKIM survives forwarding if the message body is not modified). You cannot fix forwarding-related SPF failures without the cooperation of the forwarding server.

Pattern 4: Spoofing or phishing traffic

Symptoms: Records from IPs in anonymous hosting providers, Eastern European or Asian data centers, or IP ranges with no obvious legitimate use. Volume is typically low but the DMARC failure rate is 100%.

Fix: This is not a configuration problem — it is attack traffic. Move your DMARC policy from p=none to p=reject. The receiving provider will drop these messages. If you are already at p=reject, these failures are expected and your policy is working.

From p=none to p=reject: A Safe Escalation Path

The biggest risk when enforcing DMARC is rejecting legitimate email. The escalation path below minimizes this risk while making progress toward full enforcement.

Phase 1: Monitor (p=none)

Publish a DMARC record with p=none and both rua (aggregate reports) and ruf (forensic reports) tags. Collect reports for 2–4 weeks. Use this period to inventory all email sending sources and identify authentication failures.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1;

Phase 2: Quarantine at low percentage

Once you have fixed authentication for all known legitimate senders, move to p=quarantine; pct=10. This applies the quarantine policy to only 10% of failing messages, giving you a safety net.

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com;

Phase 3: Quarantine at full coverage

Increase pct to 100 once you confirm the quarantine is not catching legitimate traffic. Monitor the failure rate closely.

Phase 4: Reject

Move to p=reject when your pass rate is above 95% and you are confident all legitimate senders are authenticated. This is the gold standard — receiving providers will outright reject messages that fail DMARC.

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

Once at p=reject, spoofed emails using your domain are dropped by receiving providers before they reach any inbox. This is the most effective anti-phishing control available for your domain.

SPF Record Best Practices for Large Organizations

SPF records have a hard limit of 10 DNS lookups. Large organizations using multiple email platforms routinely hit this limit, causing SPF permerror across all their sending sources.

• Audit your SPF record using a lookup counter. Include mechanisms like include:, a, mx each consume one lookup.
• Flatten your SPF record by replacing include: chains with explicit ip4: and ip6: ranges. Use an SPF flattening service if the IP ranges of your providers change frequently.
• Consider switching your primary DMARC pass mechanism to DKIM, which has no lookup limits. If DKIM is aligned, SPF failures don't affect your DMARC pass rate.

DKIM Configuration: What Can Go Wrong

DKIM is more reliable than SPF for DMARC alignment because it survives email forwarding and is independent of the sending IP. However, several configuration issues can cause DKIM alignment failures:

• Wrong d= domain: The platform is signing with its own domain (e.g., sendgrid.net) instead of yours. Fix: enable custom DKIM domain in the platform.
• Key rotation without DNS update: After rotating DKIM keys, the public key in DNS must be updated. A mismatch causes all DKIM signatures to fail until the DNS propagates.
• Message body modification: Some email security gateways rewrite URLs or add footers, breaking the DKIM body hash. This is typically a problem with inbound gateways re-routing outbound mail.
• Missing DKIM selector in DNS: The selector specified in thes= tag of the DKIM header must exist as a TXT record at selector._domainkey.yourdomain.com.

How to Use DMARC Labs to Analyze Your Reports

DMARC Labs is built specifically to handle the large, complex DMARC aggregate reports that other tools struggle with. Here is the complete workflow:

1. Collect your XML files. Download DMARC reports from your rua= mailbox. They arrive as ZIP or GZIP attachments. Extract the XML file inside.
2. Drop the file into DMARC Labs. No signup. No size limit. The file is read directly from your disk — nothing is uploaded.
3. Review the dashboard. The analyzer shows DMARC pass/fail rates, SPF and DKIM alignment breakdowns, top sending IPs with WHOIS enrichment, country distribution, and suspicious IP flags.
4. Identify failing senders. Focus on records where policy_evaluated/dkim and policy_evaluated/spf are both fail. These are the messages that your DMARC policy is catching.
5. Enrich the IPs. The dashboard shows the organization name and country for each source IP. Use this to identify whether failing senders are legitimate (requiring auth fixes) or unauthorized (requiring policy enforcement).
6. Export and act. Download a CSV of the enriched data. Use it to prioritize which sending platforms to configure first.

Interpreting the DMARC Pass Rate

Your DMARC pass rate is the percentage of messages where at least one of SPF or DKIM passes with alignment. Healthy email programs typically see rates above 95%.

Privacy Considerations When Analyzing DMARC Reports

DMARC aggregate reports contain more sensitive data than many organizations realize:

• Source IP addresses that reveal your sending infrastructure and the third-party services you use
• Message volume data that reveals business activity patterns
• Authentication failure patterns that reveal security weaknesses

Uploading these reports to a SaaS DMARC tool means a third party has visibility into your email infrastructure. For regulated industries (healthcare, finance, legal), this can create compliance concerns. Browser-native analysis eliminates this risk entirely — the data never leaves your device.

Frequently Asked Questions

What is a DMARC XML report?

A DMARC XML report (also called an aggregate report or RUA report) is an XML file sent by receiving mail servers to the domain owner. It summarises how many messages were received claiming to be from your domain, how many passed SPF and DKIM authentication, and how many were handled according to your DMARC policy.

Why are some DMARC XML files so large (100MB+)?

DMARC aggregate reports grow large when your domain sends a high volume of email. Each record entry represents a unique combination of source IP, authentication result, and disposition. High-volume senders — especially those using third-party email services — can accumulate millions of records per reporting period, pushing file sizes into the hundreds of megabytes.

Can I analyze a large DMARC XML file without uploading it?

Yes. DMARC Labs uses a browser-native XML parser that processes your file entirely on your device. The file is never sent to any server. This removes file-size limits — your browser can process files of any size, including 100MB+ reports that would overwhelm typical SaaS DMARC tools.

How do I move from p=none to p=reject safely?

Start with p=none, collect reports for 2–4 weeks, and identify all legitimate email sources. Fix authentication for each. Then move to p=quarantine; pct=10, gradually increasing the percentage. Once the pass rate stabilizes above 95%, move to p=reject.

Is DMARC Labs free to use?

Yes, completely free. No signup required, no file size limit, and no data is ever sent to a server. All parsing, analysis, and IP enrichment happens in your browser using client-side JavaScript.