Forwarding DMARC Reports to an Aggregation Service

DMARC reports arrive in your inbox from receivers like Google, Microsoft, and Fastmail. Most of the time, you point your DMARC record at your own domain and let a dedicated service collect those reports. But what happens when your organization needs reports to pass through your own infrastructure first -- a compliance requirement, a SIEM integration, or a multi-tenant setup where one vendor manages reporting for many domains?

The question comes up regularly in DMARC communities, and the answer is more nuanced than a simple yes or no.

Why Forward DMARC Reports in the First Place?

There are three common reasons organizations want to route DMARC reports through an intermediate layer:

Compliance and data sovereignty. Regulated industries sometimes cannot send telemetry directly to a third-party SaaS. They need reports to pass through their own cloud environment first, where logging and access controls are already established.

SIEM and security operations integration. Security teams centralise logs in tools like Splunk, Elastic, or Microsoft Sentinel. Forwarding DMARC reports through their own infrastructure lets them correlate email authentication data with other security signals without a separate ingestion pipeline.

Multi-tenant managed services. Managed service providers monitoring DMARC for many clients often route all reports through a single relay they control before distributing them to per-client aggregation services.

Each of these scenarios requires forwarding DMARC reports without breaking the data inside them.

How DMARC Report Forwarding Works Under RFC 9990

RFC 9990 (the DMARC aggregate reporting standard, published in the recent DMARC RFC update) defines the format and transport of DMARC reports. The key thing it specifies for forwarding is that reports are transmitted as email attachments -- specifically, XML files compressed with gzip and MIME-encoded as application/gzip.

When you forward a DMARC report email, you are forwarding the entire email message with its gzip XML attachment intact. As long as the forwarded message preserves the original headers and attachment encoding, the report data inside remains valid.

This means DMARC report forwarding is technically possible and, when done correctly, spec-compliant.

The critical constraint is that forwarded reports must arrive at the aggregation service in the same structural form they arrived at the forwarding relay. Any transformation that strips headers, re-encodes the attachment, or changes the MIME structure can make the report unreadable by the receiving service.

Common Mistakes That Break Report Integrity

In practice, several things go wrong when organisations set up DMARC report forwarding:

SMTP rewriting by mail transfer agents. Many MTAs rewrite message headers for tracking or anti-spam purposes. This can corrupt the MIME structure of the DMARC report attachment, making it unreadable by the aggregation service on the other end.

Attachment stripping or re-encoding. Some forwarding rules re-encode attachments to scan them for malware. A gzip attachment that gets decompressed and re-compressed during this process will almost certainly arrive corrupted.

Address translation in the SMTP envelope. DMARC reports are sent to the address specified in the rua tag of your DMARC DNS record. If you forward from reports@yourdomain.com to dmarc@vendor.com, the envelope recipient changes but the report content inside does not. Most aggregation services handle this correctly, but some do not.

Losing the subject line. The subject line of a DMARC report email typically contains metadata the receiving service uses to identify the report type and source. Forwarding rules that apply a uniform subject line or auto-archive based on subject can break processing downstream.

The most reliable forwarding setups treat the DMARC report email as an opaque object -- forwarding the entire message without modification, scanning only at the network level, and preserving all original headers and MIME structure.

Correct Forwarding Architecture

There are three common patterns for forwarding DMARC reports correctly:

Pattern 1: SMTP relay passthrough. Configure your mail server to accept DMARC reports on one address and relay them unchanged to your aggregation service. The relay performs no content transformation. This is the simplest approach and the most reliable. Tools like Postfix can be configured with minimal rules to achieve this. The key setting is receive_override_options=no_header_rewrite in Postfix, which prevents the MTA from modifying message headers.

Pattern 2: S3-based ingestion pipeline. Some organisations write reports to an S3 bucket via SMTP-to-storage bridge, then have their aggregation service read from the bucket. This is common in AWS-native environments. The risk here is that the SMTP-to-storage bridge must preserve the original email structure byte-for-byte, or the gzip XML inside will be corrupted.

Pattern 3: API-based forwarding with no email relay. Some modern DMARC services expose an API that accepts report uploads directly, bypassing email forwarding entirely. This sidesteps the MIME preservation problem but requires the report sender to support API submission in addition to or instead of email-based rua delivery.

DMARCFlow supports SMTP ingestion as a primary method, which means it can receive forwarded reports directly from a properly configured relay without requiring API changes on the reporter's side. This makes it well-suited for the compliance and SIEM forwarding scenarios described above.

What to Watch for When Using Forwarded Reports

If your DMARC reports are reaching your aggregation service via a forwarder, there are three operational things to monitor:

First, verify that the report arrival rate matches your expectations. Forwarding failures or silent drops will show up as gaps in your reporting timeline. If you normally receive reports from Google every 24 hours and they suddenly stop arriving, check whether the forwarding relay had an outage.

Second, look for decoding errors in your aggregation service. Corrupted reports often manifest as XML parse failures -- your service will report that it received a file but cannot read it. When you see a spike in parse failures, inspect whether the forwarding path changed anything in the MIME structure.

Third, be aware that forwarded reports will have two sets of metadata -- the original report metadata from the receiver (Google, Microsoft, etc.) and the forwarding path headers added by your relay. Your aggregation service should use the original report metadata, not the forwarded headers, to determine the report source and time range. DMARCFlow uses the XML content inside the report to determine source and ignores forwarded headers, which prevents the forwarding path from corrupting report attribution.

Is Forwarding Right for Your Organisation?

DMARC report forwarding is a legitimate architecture used by enterprises with compliance requirements, security teams that centralise telemetry, and managed service providers. It works correctly when the forwarding path treats DMARC report emails as opaque objects and does not transform them.

If you are considering forwarding DMARC reports to a third-party aggregation service, the most important question to ask your vendor is: does your service accept forwarded reports without modifying its processing logic based on headers added by the forwarder? Services that rely on SMTP headers rather than the XML content inside the report are fragile when forwarding is involved.

DMARCFlow ingests reports via standard SMTP and parses the XML content directly, making it resilient to forwarded mail. If you need to route reports through your own infrastructure before they reach your DMARC monitoring service, DMARCFlow is designed to handle that topology without data loss or attribution errors.