Why Most DMARC Aggregate Reports Are Still Not RFC Compliant (and What It Means for Operators)

If you rely on DMARC aggregate reports to monitor your domain's email authentication health, you have probably already noticed that something is off with the data. Reports arrive late, fields are empty or malformed, and some senders produce output that your parser cannot handle without workarounds.

That is not your parser being fragile. That is the underlying data violating the RFC.

A recent analysis of aggregate reports from nearly 3,500 reporting organizations found that only nine produced fully RFC-compliant reports at scale. The rest had at least one significant compliance failure. Some of the largest and most technically sophisticated senders on the internet were among the worst offenders - including Google, Microsoft, Yahoo, Amazon SES, and Mimecast.

What the RFC Actually Requires from DMARC Reports

RFC 7489 defines the specification for DMARC aggregate reports. It mandates specific fields, valid tag values, attachment naming conventions, and XML structure.

The requirements operators see violated most often:

• envelope_from: Required in every block. Tells you which domain was used in the SMTP MAIL FROM. Missing in a large proportion of real-world reports.
• SPF scope tag: When SPF results are reported, - either mfrom or pra - must be present. Without it, you cannot determine whether the SPF check was relevant to the DMARC alignment being evaluated.
• version formatting: Must be v=DMARC1 in that exact capitalization. Variants like V=DMARC1, v=dmarc1, or whitespace-padded versions are non-compliant.
• Attachment media type: Reports must arrive as message/rfc822 or text/rfc822-headers attachments. PDFs, plain text, or HTML-wrapped XML are outside the spec.

The Most Common Compliance Failures

Missing Required Fields

The most widespread problem is simply omitting required elements. The analysis found envelope_from, version, and SPF scope missing from a large proportion of reports from major senders.

The second most common issue: empty tags - an explicit tag with no value. The spec does not allow empty tag values, but some senders include or as a placeholder when no subdomain policy is defined.

Non-Standard Values

Some senders use values the RFC never defined. The analysis found:

• sampled_out as a disposition value
• unknown as an SPF result (the spec defines fail, not unknown)
• Pass with a capital P - when the spec requires lowercase pass

These values pass through lenient parsers without error but produce garbage in dashboards. An SPF result of unknown and fail mean different things, but a lenient parser treats them the same.

Attachment Format Problems

The RFC specifies reports must be MIME message attachments with a specific structure. In practice, common non-compliant formats include raw XML sent as text/plain, PDFs, and HTML-wrapped XML. Operators expecting the correct MIME structure may reject these as unreadable.

What Non-Compliant Reports Break

Three concrete problems for operators:

1. Parser breakage. Strict RFC parsers reject non-compliant records. Operators who tested their pipeline with clean data lose real production reports from large senders without warning.

2. Silent data loss. Even lenient parsers may not interpret fields correctly. A missing envelope_from means you cannot trace which domain sent the message. A missing SPF scope makes it impossible to determine the alignment context. The report arrives but signal is gone.

3. Ongoing workaround maintenance. Real DMARC data has edge cases the RFC never illustrates. Operators building resilient pipelines must maintain and update sender-specific workarounds - unglamorous maintenance that consumes time no one planned for.

How to Handle Non-Compliant Reports in Practice

You cannot force senders to produce compliant reports. But you can build your pipeline to handle the reality without losing visibility.

Use a report consumer that normalizes messy data. A parser that fails on first contact with a malformed record is too fragile for production. Look for consumers that accept non-standard values and normalize them to RFC equivalents rather than rejecting records on schema violations.

DMARCFlow processes incoming reports at scale, normalizing known non-compliant values - including capitalization variants, empty tags, and non-standard disposition values - before they reach your dashboard. Rather than maintaining parser workarounds for each large sender, operators can rely on the normalization layer to deliver consistent data regardless of what format the sender used.

Normalize values before storage. Run incoming data through a normalization step converting known non-compliant values: Pass → pass, unknown → fail, empty sp tags → none. This keeps your downstream queries consistent regardless of sender format.

Track report quality over time. Add a compliance metadata flag to each processed report. Over time, you see which senders improve, which stay broken, and which are getting worse.

Store the raw report separately. Keep the original unprocessed report even if your parser handles it gracefully. When a new failure mode surfaces, the raw source lets you update normalization rules without reprocessing from scratch.

Frequently Asked Questions

How can I check if my reports are RFC compliant?

Send a test message to an address you control and examine the raw aggregate report. Check all required fields are present, tag values use correct capitalization, XML structure is valid, and attachment MIME type matches the spec. Alternatively, use a public validation tool or a DMARC report consumer that flags RFC violations.

Does non-compliant mean the reports are useless?

Not automatically. A report with a missing optional field may still contain useful data. The critical question is whether the compliance failure causes you to lose signal you needed. A missing envelope_from is far more damaging than a capitalization variant on a secondary tag.

Is this improving?

Slowly. Comcast, Fastmail, and to a lesser extent Microsoft have improved compliance in recent years. But Google, Yahoo, Amazon SES, and Mimecast continue generating high volumes of non-compliant reports. Until the largest senders treat RFC compliance as a priority, expect to maintain resilient parsers.

Can I reject non-compliant reports from my DMARC policy?

No. Report delivery is separate from email authentication. Your p= policy governs whether receivers accept or reject mail - not how they send you reports. There is no mechanism to enforce report compliance from the receiving side. The only pressure available is public accountability, which is why the DMARC Wall of Shame exists and why operators benefit from normalizing non-compliant data at ingestion rather than hoping senders fix their output.