Blog · Dmarc
Why Your DMARC Report Parser Keeps Breaking (And What the Major Providers Get Wrong)
If you have ever built a DMARC aggregate report parser and watched it die on a file from Google or Yahoo, you are not alone. A recent analysis by URIports looked at DMARC reports from nearly 3,500 reporting organizations and found that only nine sent fully RFC-compliant reports. The rest had at least one problem. Most major senders - including some of the organizations that helped shape the standard - had multiple issues.
This is not a theoretical problem. Broken reports mean missing data, failed integrations, and silent data loss in security monitoring pipelines. Here is what the RFC actually requires, what providers routinely get wrong, and how to build a parser that survives real-world DMARC reports.
What RFC 7489 Actually Requires in a DMARC Aggregate Report
RFC 7489 defines the schema for DMARC aggregate reports sent over email. A valid report is a ZIP or gzip attachment with an XML body conforming to a specific structure. The critical fields are:
version- must be present and set to "1"envelope_from- the RFC5321.MailFrom domain used in the SMTP transactionSPFscope - eithersp(sending domain) orhr(host domain, deprecated)disposition-none,quarantine, orrejectdkimresult -pass,fail,none,policy,neutral,failspfresult -pass,fail,none,softfail,policy,neutral
The XML also uses a
That is the expected shape. Now here is what actually arrives in your inbox.
The Most Common RFC Violations in Real-World Reports
Missing or invalid version tag
The version attribute is mandatory. Some providers omit it entirely. Others send a value that is not "1". Both cases will cause schema validation to fail if your parser is strict.
Missing envelope_from field
The envelope_from field tells you which domain appeared in the SMTP MAIL FROM command. Several major providers omit it from their aggregate reports. Without it, correlating a DMARC failure to a specific sending source becomes a manual process.
Empty or misnamed SPF scope values
The SPF element accepts sp or hr as valid scope values. Real-world reports contain unknown, sampled_out, hardfail, and occasionally Pass with a capital P. None of these are valid according to RFC 7489. Any of them will cause a strict validator to reject the record.
Empty `
Some providers send an empty
Invalid attachment media types
DMARC reports must arrive as gzip compressed files. The filename must end in .gz and the Content-Type should be application/gzip or application/zip. Some providers send reports as plain .xml.gz but declare the wrong media type. Others send .xml files without gzip compression and hope for the best. Both confuse parsers that expect correctly typed gzip attachments.
Which Providers Send Non-Compliant Reports (And What They Get Wrong)
The URIports analysis found a pattern by provider:
Comcast, Microsoft, and Fastmail were close to compliant but still had edge case issues - typically one or two of the violations listed above. Their reports parse most of the time but fail intermittently.
Yahoo, Google, Amazon SES, and Mimecast generated large volumes of non-compliant reports. The most common problems were missing envelope_from fields, invalid SPF scope values, and malformed attachment filenames or media types. If your parser handles a high volume of reports from any of these providers, you have almost certainly encountered silent data loss.
Most smaller providers had at least one of the common violations, which is why a parser that works fine for one provider can break completely for another.
A practical note: the nine fully compliant organizations in the URIports sample were not the largest or most sophisticated senders. Compliance was not correlated with organization size.
How to Build a DMARC Parser That Handles Real-World Messiness
Use lenient field validation
Treat missing or invalid fields as warnings, not fatal errors. If envelope_from is absent, note that the field is missing and continue parsing the rest of the record. Do not abort the entire parse for a missing optional field.
Normalize values before validation
Before checking whether an SPF result is valid, normalize it: strip whitespace, lowercase the value, and map known aliases to their canonical RFC values. Pass with a capital P becomes pass. hardfail becomes hardfail. Unknown values should be logged and flagged but not cause the record to be discarded.
Handle attachment type variation gracefully
Accept .gz and .zip filenames. Accept application/gzip, application/zip, and application/octet-stream media types. If the attachment is uncompressed and the filename suggests it should be compressed, decompress nothing and parse the XML directly.
Validate schema structure, not content values
Validate that the XML has the right element hierarchy and that required elements are present. Do not validate that the values inside those elements conform to a strict enumerated list until after you have extracted the data. Separate extraction from validation.
Log every non-compliant event
When a report fails validation, log it with the provider name, the violation type, and the timestamp. This data is useful for identifying which providers need monitoring and for demonstrating the scope of the compliance problem to your security team.
When to Accept Partial Data vs. Reject the Report Entirely
A broken report still contains useful data. If a report from Yahoo has a missing envelope_from field but contains three valid
Reject a report only if it is so malformed that no records can be extracted at all - for example, if the XML is not valid UTF-8 or the gzip decompression fails entirely. Even then, log the failure with the raw error so you can investigate.
Accept partial data when you can extract at least one valid record. Flag the missing fields in your processing logs so you know what you did not receive.
FAQ
Can I still use reports with invalid XML?
Usually, yes. Most DMARC tools are lenient. If you are building your own parser and you are seeing silent data loss - records that should be in your dashboard but are not - the most likely cause is a strict validator rejecting non-compliant records that actually contain useful data. Try relaxing your field validation and parsing what you can.
How do I report a provider's non-compliance?
You can report non-compliant DMARC reports to the provider, but the process is informal. The RFC does not define a reporting mechanism for bad report data. In practice, large providers are more responsive to issues filed through their postmaster tools or security contact pages. For Yahoo, use the Yahoo postmaster site. For Google, use the Google postmaster tools. For Amazon SES, use the AWS support console.
Which DMARC tools handle non-compliant reports gracefully?
Most commercial DMARC aggregation services handle non-compliant reports by design - they have had to, because the problem is widespread. Tools that build strict validators from the RFC schema tend to break on real-world reports. If you are using a DMARC monitoring tool and you notice gaps in your data from specific providers, check whether your tool's parser is too strict.
Does DMARC report non-compliance affect my domain's security?
No. Report non-compliance is a problem with the receiving side (the organization sending you their aggregate reports), not your domain's DMARC policy. Your domain's email authentication is working exactly as configured regardless of whether the reports generated are RFC compliant. The problem is that you may not be seeing the full picture of who is sending email from your domain.
How does DMARCFlow handle non-compliant reports?
DMARCFlow parses and normalizes reports even when providers send malformed XML, so you do not lose visibility into your domain's email authentication data. Rather than rejecting a record with a missing envelope_from field, DMARCFlow logs the gap and continues processing the rest of the record. This means you see the data that is there instead of losing an entire report because one field is invalid.
---
The RFC compliance problem in DMARC reports is real, widespread, and unlikely to be fixed across all providers soon. The practical answer is to build parsers that expect real-world messiness, log what they cannot parse, and keep the data they can. Waiting for perfect compliance from Google and Microsoft is not a strategy.