Blog · Dmarc
Why DMARC Reports Are Often Not RFC Compliant (And How to Fix Yours)
If you are running DMARC and feeling like your reports are harder to parse than they should be, you are not imagining it. Most DMARC reports are not fully RFC compliant. That is not a theoretical problem - it breaks parsers, fills your logs with errors, and means you are probably missing data about who is sending email on your behalf.
This post explains why RFC compliance matters for DMARC reports, what the most common violations look like in practice, and how to validate whether your own reports are well-formed.
What RFC 6591 Requires of DMARC Reports
RFC 6591 defines the expected format for DMARC feedback reports - both aggregate reports ( Feedback-Type: auth-failure) and forensic reports ( Feedback-Type: failure). The spec covers three areas: XML structure, required fields, and character encoding.
A valid DMARC aggregate report must include:
- A
- A
- Each record must have a
- Each record must also have a
Forensic reports follow a similar structure but are formatted as a single message per failure incident.
Required character encoding is UTF-8. The report must be gzip-compressed when delivered over SMTP.
Why So Many Reports Fail Compliance
The most common violations fall into four categories.
Missing or malformed
Report metadata fields dropped. The
Non-standard XML namespaces. RFC 6591 specifies the DMARC namespace as urn:ietf:params:xml:ns:dmarc. Some receivers use a different namespace URI or omit it entirely. A report with an incorrect namespace may parse fine in a lenient XML parser but silently fail in stricter tools.
Character encoding violations. Reports sent with ISO-8859-1 encoding instead of UTF-8 cause field truncation when the receiver's parser expects multi-byte characters. This is especially common with non-ASCII domain names in the
Record count mismatches. Some receivers double-count messages that trigger both SPF and DKIM failures in the same
What Non-Compliant Reports Actually Break
The impact is not hypothetical.
DMARC aggregation tools that enforce strict XML parsing will drop entire records or skip the report entirely when they encounter unexpected elements. Teams relying on these tools end up with gaps in their sender visibility - sometimes for weeks before they notice.
Forensic report parsers are particularly fragile. A single malformed element can cause the parser to discard the entire report, leaving you with no record of a spoofing incident that the sending domain could have used to fix the problem.
Non-compliant reports also break interop between aggregate and forensic tooling. If you are using separate tools for report collection and forensic analysis, mismatched field names mean the tools cannot correlate findings.
The practical consequence: operators who do not validate report format have systematically incomplete sender data. They think they have full visibility when they actually have a blind spot where malformed reports live.
How to Validate Your DMARC Reports
Validate your reports against RFC 6591 before feeding them into any tool. You can do this in two steps.
Step 1: Decompress and check the XML structure
DMARC reports arrive gzip-compressed. Decompress the attachment and open the XML in a text editor. Check:
- The root element is
-
-
- Each
Step 2: Validate field content
Check each record for:
- UTF-8 encoding (no garbled characters on non-ASCII domain names)
- Consistent
- Valid IP addresses in
-
If you find violations, document them and open a ticket with the receiver. DMARC report quality is a receiver-side obligation, but documenting non-compliance is how you push for fixes.
Tools for DMARC Report Validation
A few options exist for automated validation:
- DMARC Report Parser (open source) - validates XML structure and flags missing fields
- MXToolbox DMARC Report Analyzer - provides a free web interface for aggregate report upload
- Dmarcian - offers report validation as part of their reporting dashboard (free tier has limits)
For ongoing monitoring, most professional DMARC aggregation services normalize reports before storing them, which means they handle the messy receivers gracefully on your behalf.
DMARCFlow Mention
If you are dealing with a mixed feed of compliant and non-compliant reports from different receivers, DMARCFlow normalizes incoming DMARC data before storing it, so you get consistent visibility regardless of which receiver sent the report. This is useful when you have not yet negotiated better report quality with every receiving provider.
FAQ
Can I force receivers to send compliant reports?
No - report format is a receiver-side responsibility. You can request improvements and point receivers to RFC 6591, but you cannot compel them to fix their report generation.
How do I know if my reports are being silently dropped?
If you are receiving reports but your aggregation tool shows lower record counts than you expect from your sending volume, check the tool's error logs for XML parsing failures. That is the most common symptom of a format violation.
Do forensic reports have different compliance requirements?
Yes. Forensic reports are formatted as RFC 5962 (message/global) types, not plain XML attachments. The structure requirements differ slightly from aggregate reports. Most forensic report parsers are more sensitive to format violations than aggregate parsers.
How often should I validate my reports?
Validate any time you switch receivers, add a new sending domain, or notice gaps in your sender data. If your receivers have been stable for a long time, quarterly validation is reasonable for catching drift.