Demystifying DMARC: How to Parse RFC 7489 XML Reports Without Third-Party SaaS

The anatomy of an RFC 7489 aggregate feedback report

When you publish a DMARC record with a reporting URI (e.g., v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com), major mailbox providers (Google, Microsoft, Yahoo) collect 24-hour transmission telemetry and dispatch an aggregate XML report back to your designated address.

These reports arrive as Gzip or Zip compressed MIME attachments. Underneath the compression lies a standardized RFC 7489 XML document containing complete forensic data on every IP address that attempted to send mail using your domain identity.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>89234871920391203</report_id>
    <date_range><begin>1729814400</begin><end>1729900799</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p><sp>none</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.24</source_ip>
      <count>142</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><result>pass</result><selector>sada</selector></dkim>
      <spf><domain>yourdomain.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Neutralizing XML entity expansion (XXE) vulnerabilities

Because DMARC aggregate reports are generated by external mail systems and received via unauthenticated inbound MX routing, parsing raw XML represents a serious attack vector if not hardened.

Attackers can send crafted synthetic DMARC reports containing XML Entity Expansion payloads (such as "Billion Laughs" denial of service) or external entity inclusions seeking to read local server files.

A secure DMARC parser must enforce strict ingestion controls:

• Disable External DTDs: Completely forbid document type definitions and external general entities during XML parser initialization.
• Decompression Bomb Protection: Limit uncompressed Gzip/Zip byte expansion to a maximum ceiling (e.g., 10 megabytes) before streaming into memory.
• Strict Schema Validation: Validate all nodes against the RFC 7489 XML Schema Definition before storing records in database tables.

Evaluating relaxed vs. strict authentication alignment

A common misconception in email deliverability is that having SPF and DKIM pass is sufficient for DMARC. DMARC requires alignment between the visible From: header and the authenticated envelope identities:

The automated 4-phase rollout path to strict rejection

Jumping immediately to a strict DMARC rejection policy (p=reject) will break legitimate transactional emails from forgotten services such as billing systems, transactional ticket portals, or marketing tools.

SadaSend automates the migration journey through four controlled phases:

• Phase 1 (Audit & Discovery · p=none): Ingest aggregate reports for 14 days to catalog all authorized and shadow sending infrastructure.
• Phase 2 (Alignment Remediation): Correct missing SPF includes and dual-DKIM selectors for every verified application service.
• Phase 3 (Quarantine Enforcement · p=quarantine; pct=25 → pct=100): Direct mailbox providers to send unauthorized emails to the spam folder while monitoring false positives.
• Phase 4 (Strict Rejection · p=reject): Enforce complete spoofing defense where unaligned emails are dropped at the connection level before reaching user mailboxes.