Blog · Dmarc
Why Most DMARC Reports Are Failing RFC Compliance (And What It Means for Your Setup)
Your DMARC setup looks correct. Your DNS records are publishing. But when you open your aggregate report, something is wrong - the format is unpredictable, key fields are missing, or a receiving party rejected your report outright.
You may be flying blind because your DMARC reports aren't RFC compliant.
RFC 7489 defines the minimum structural requirements for DMARC reports. Most report-generating systems - especially legacy spam filters, regional mailbox providers, and in-house relay tooling - don't meet the spec. Unlike a broken SPF record or a misaligned DKIM key, there's no immediate bounce signal. Your reports arrive. They just don't parse correctly.
What RFC 7489 Requires of DMARC Aggregate Reports
A compliant aggregate report is an XML document delivered to your RUA endpoint. Every report must contain:
- A `
` block with the generating organization's name, contact email, and a unique report ID - A `
` block showing your DMARC record as the receiver understood it at evaluation time - One or more `
` blocks, each covering one sending source IP and containing: - The aligned SPF result (domain, result pass/fail, mechanism)
- The aligned DKIM result (domain, selector, result pass/fail)
- A `
` disposition - the action the receiver took based on your DMARC policy and the auth results combined
For forensic reports (RUF), the format differs and includes original message headers. Aggregate and forensic reports are structurally distinct; sending one to the wrong endpoint is non-compliant by spec.
The simplest compliance test: if your report cannot be parsed as valid XML, it does not meet RFC 7489.
Why DMARC Reports Fail Compliance
Four failure modes show up most often in practice.
1. Structural XML errors
Many generators produce malformed XML - unescaped characters in the
2. Missing or wrong metadata
The org_name, email, and a unique report_id. Small or regional receivers often omit email, use their internal domain instead of the sending domain in org_name, or reuse the same report_id across every batch - which makes deduplication impossible when you're comparing week-over-week data.
3. SPF or DKIM result misalignment in the report
The aspf=s or p=reject. For DKIM, some receivers report the selector domain rather than the signing domain - a mismatch that shows as a false alignment failure in your report even when your DKIM signature is valid.
4. Published policy and evaluated policy don't match
If your DMARC record says p=quarantine but the report shows none as the applied disposition, the receiver may not have fetched your record before processing the message. This isn't always a compliance error in the report itself - it's a propagation or enforcement gap. But it means the report is documenting a failure you can't diagnose from the data inside it.
How to Check If Your Reports Are Compliant
Parse the XML first. Open the raw report in a text editor or feed it through an XML validator. If it fails to parse, you have a structural error that needs fixing at the generating receiver's end.
Check required fields. Every record should contain:
- `org_name` and `email` in `
` - `domain` in `
` matching your DMARC `d=` - `source_ip` for the evaluated sender
- SPF result with aligned domain and pass/fail
- DKIM result with aligned domain, selector, and pass/fail
- `
` disposition matching your published policy
Validate domain alignment. For each record, the SPF domain and DKIM domain must both align with your DMARC d= if your policy is p=quarantine or p=reject. A record showing aligned SPF pass and aligned DKIM fail with disposition none tells you something is wrong with your DKIM setup - not that DMARC is broken.
Watch for report silence. Set up a monitor that alerts you when a known reporter stops sending. A mailbox provider that was sending weekly reports and goes silent may have changed how it handles your domain's mail - or silently started discarding your non-compliant reports.
What Non-Compliant Reports Cost You
Blind spots in your sending infrastructure. Non-compliant reports don't capture all sending sources. You may have dozens of legitimate third-party senders you've never identified because their report data was silently dropped. Moving to p=reject with incomplete sending source data means blocking mail you actually want.
Gmail and Microsoft can't tell you what's wrong. Both Postmaster Tools and Sender Insights ingest aggregate reports. When reports arrive malformed, the platforms may process them partially or surface generic errors without specifying which field caused the problem. You get a warning in the tool but no diagnosis.
No forensic trail when a crisis hits. If someone spoofs your domain in a BEC attack, forensic reports are the first evidence you investigate. Non-compliant forensic reports - missing headers, wrong format - may be unreadable by your SIEM or email archival system, which means your incident response starts from zero instead of from the headers.
Slower path to enforcement. Organizations that want to move from p=none to p=reject use aggregate report data to identify all legitimate sending sources first. If your report pipeline has gaps, you'll either stay at p=none longer than necessary or risk blocking a vendor you didn't know was sending for your domain.
How DMARCFlow Helps
DMARCFlow validates every incoming aggregate report against RFC 7489 on ingest. When a report has structural errors, missing fields, or alignment mismatches, DMARCFlow flags it and identifies which sending sources are affected - before you make decisions based on incomplete data.
This is different from parsing the report content. Most parsers read what they can and discard what they can't. DMARCFlow tells you which receivers are sending non-compliant reports and which fields are broken, so you can either fix the configuration at the source or adjust your expectations for that reporter's data quality.
You see a per-receiver compliance score and an alert when a major mailbox provider starts sending structurally broken reports - something you'd otherwise only discover when your Postmaster Tools dashboard goes quiet.
Checklist: Is Your DMARC Report RFC Compliant?
- XML parses without errors
- `
` has `org_name`, `email`, and a unique `report_id` - `
` domain matches your DMARC `d=` - Each `
` shows aligned SPF and DKIM domains - `
` disposition matches your published policy - All expected receivers are sending reports at their usual interval
- No duplicate `report_id` values across separate files
If you're running this checklist manually and finding problems, DMARCFlow automates the validation and gives you a continuous compliance score across every receiver that handles your mail.
FAQ
Who enforces DMARC report compliance?
No central authority does. Gmail and Microsoft validate reports internally and surface errors in their Postmaster Tools, but they don't reject reports for minor structural deviations. The enforcement that matters is whether your own monitoring stack can process and trust the reports you receive.
Can you reject reports that don't comply with RFC 7489?
Your DMARC record controls message handling, not report format. A non-compliant report is a data quality problem, not a policy violation. If you're using a third-party aggregator that forwards reports to you, the aggregator's compliance validation matters - they should be validating and fixing structural issues before forwarding, not just passing them through.
Does a compliant report mean your DMARC setup is correct?
No. A compliant report tells you the receiver generated the document correctly. It says nothing about whether your SPF, DKIM, or DMARC record is configured correctly. A report can be perfectly RFC-compliant and show 100% DKIM failures because your signing key is wrong or your selector isn't published in DNS.
Why do some receivers not send aggregate reports at all?
Not all mailbox providers implement DMARC reporting. Those that don't won't appear in your data, which means you have no visibility into mail they handle for your domain. This is a coverage gap, not a compliance error - but it's one of the most common reasons organizations feel they have incomplete data even when their DMARC setup is correct.