Blog · Dmarc
Why Most DMARC Reports Fail RFC Compliance (And What to Do About It)
If you run DMARC monitoring and have ever stared at a report your tool couldn't parse, you're not alone. A large portion of DMARC aggregate reports circulating on the internet are technically non-compliant with RFC 7489 - the specification that defines the report format. Some violations are minor. Some cause outright parsing failures. Most are fixable once you know what to look for.
This post covers the most common RFC 7489 violations found in real-world DMARC aggregate reports, how to validate your reports, and what to do when the sending receiver is the source of the problem.
---
Why DMARC Report Compliance Matters
DMARC aggregate reports are only useful if something can read them. When a report violates RFC 7489, parsers either reject it entirely or extract partial data and silently drop the rest. That means real authentication failures go unseen. Real spoofing attempts go unlogged. The security value of DMARC depends on complete, readable reports.
The irony is that senders and receivers both have incentives to get this right - but the ecosystem is messy. Receivers implement report generation differently. Large email providers like Google, Microsoft, and smaller regional carriers each have their own quirks. The result is that even well-run DMARC programs receive reports that fail basic schema validation.
---
The RFC 7489 Aggregate Report Format
RFC 7489 defines DMARC aggregate reports as XML documents delivered as email attachments. A compliant report has:
- A root
<feedback>element - A
<report_metadata>section with the receiver's identifier, report ID, and date range - One or more
<record>entries, each containing: <source_ip></code> - the IP address that sent the message<count></code> - number of messages matching this record<policy_evaluated></code> - the DMARC disposition (none, quarantine, reject) and any applied DKIM/SPF alignment results<identifier></code> - the RFC5322.From domain<auth_results></code> - SPF and DKIM authentication results for this message
The root element must carry the correct XML namespace (http://www.roundcube.net/ns/ is a common misattribution - the correct namespace for RFC 7489 DMARC reports is urn:ietf:params:xml:ns:dmarc). Missing or wrong namespace declarations cause schema validation to fail immediately.
---
The Most Common RFC 7489 Violations
Missing or incorrect <feedback> wrapper
The root element must be <feedback>. Some receivers wrap records directly under <dmarc> or omit the root element entirely. Without the correct root, no compliant parser will process the document.
Malformed <source_ip> values
IP addresses in <source_ip> must be valid IPv4 or IPv6 addresses. Some receivers include hostnames, FQDNs, or empty strings. Others truncate IPv6 addresses or include zone IDs (e.g., %eth0 suffixes) that violate the RFC's addressing rules.
Invalid <count> values
<count> must be a positive integer. Reports with <count>0 for every record, or non-integer values, are technically non-compliant. Some receivers generate <count>1 for every record rather than batching identical events, inflating report volume.
Broken date ranges in <report_metadata>
The <date_range> element requires <begin> and <end> as UNIX epoch timestamps. Timestamps that are in the future, in the distant past (before 2015), or missing entirely cause parsers to reject the report as invalid.
Non-UTF8 characters in text fields
<source_ip>, <from>, and policy fields must be UTF-8 encoded. Reports arriving with ISO-8859-1 encoded characters in company names or domain fields will parse partially or fail entirely depending on the parser's encoding tolerance.
Missing <auth_results> for one or both mechanisms
RFC 7489 expects both <spf> and <dkim> results inside <auth_results>. Some receivers omit <dkim> when only SPF ran, or vice versa. Missing entries are technically violations even if the authentication result was "pass."
Duplicate or out-of-order <record> entries
While not a schema violation per se, duplicate records with identical <source_ip> and <identifier> combinations inflate counts and confuse aggregate analysis. RFC 7489 does not prohibit duplicates, but well-formed reports batch identical events into a single record with a higher <count>.
---
How to Validate a DMARC Report Against RFC 7489
XSD schema validation is the most reliable method. RFC 7489 Appendix C provides the official XML schema. You can validate a report with tools like xmllint or xmlsec:
xmllint --noout --schema dmarc/schema/rfc7489-dmarcbase.xsd report.xml
If the report fails validation, the error message will typically indicate which element failed and why.
Browser-based validators also exist and are useful for one-off checks without installing tools.
Parser tolerance is worth knowing about. Not all DMARC monitoring tools fail on the same violations. DMARCFlow's parser handles minor RFC deviations - including malformed IP formats and missing optional sub-elements - gracefully, extracting meaningful data from reports that would cause stricter parsers to error out entirely. This tolerance matters in production environments where non-compliant reports are the norm, not the exception.
---
What to Do When Reports Are Non-Compliant
Identify the source
Check which receiver is sending the problematic report. If it's a major provider (Google, Microsoft, Fastmail), the violation is likely known and ongoing. If it's a smaller carrier or an internal mail gateway, the problem may be fixable with a configuration change on their end.
Contact the receiver
RFC 7489 Section 7.2 discusses aggregate report handling, and receiver implementations are expected to conform. If you have a direct relationship with the receiver's email team, a brief note pointing to the specific violation is often enough to get it fixed - especially for large volume senders.
Use a tolerant parser
If the violations are minor and the report contains useful data, a parser that handles RFC deviations gracefully is more practical than demanding perfect compliance from every receiver. DMARCFlow's parser is built to extract aggregate data from imperfect reports rather than rejecting them outright.
Log the failures
Keep a record of non-compliant reports and the specific violations they contain. This creates evidence for raising the issue with receivers and demonstrates the scope of the problem in your DMARC program.
---
How DMARCFlow Handles Non-Compliant Reports
DMARCFlow processes incoming DMARC aggregate reports on ingest. Its parser is RFC-tolerant: it reads reports that have minor structural violations, malformed IP values, or missing optional elements, and extracts the authentication data that is actually present. You still get visibility into SPF and DKIM alignment failures, policy dispositions, and sending sources - even when some fields are invalid or absent.
For teams receiving reports from multiple receivers across different implementations, this tolerance is not a workaround - it is the baseline for practical DMARC monitoring. A tool that rejects reports because of a malformed IP address is a tool that fails exactly when you need it most.
You can connect DMARCFlow to any receiver's rua reports and start seeing aggregate data within minutes, regardless of which quirks that specific receiver's report generation has accumulated over time.