Forward DMARC Reports to Your Own Infrastructure

DMARC reports contain sensitive data about your email infrastructure. They show every service, SaaS tool, and third party that sends email as your domain - which is exactly why many organizations want to keep that data in-house rather than sending it to a third-party aggregation service.

If your compliance requirements demand data residency or you simply want full control over where reports go, here's what the spec allows and how to implement a reliable forwarding pipeline at scale.

Is DMARC Report Forwarding Allowed?

Yes. The DMARC spec (RFC 7489) does not prohibit forwarding aggregate or forensic reports to infrastructure you control. The rua (aggregate report) and ruf (forensic report) destinations can point to mailbox addresses you own, and report delivery via SMTP forwarding is a valid transport mechanism.

The catch is not about forwarding itself. The reports contain potentially sensitive metadata about your email sending patterns - including third-party services, marketing platforms, and internal relays. Before setting up any forwarding, make sure the destination can handle that sensitivity appropriately for your threat model and compliance regime.

The SES Forwarding Pattern - How It Works

The straightforward setup looks like this:

DMARC reports are generated by a receiver and sent to a receiving mail server
That mail server forwards the reports via SMTP to your chosen destination

This works, but it requires either modifying the DMARC DNS record for each domain to point the rua/ruf destination to your infrastructure, or relying on a third-party forwarding service that sits in the middle - which somewhat defeats the purpose of keeping data in-house.

A more scalable approach uses Amazon SES receipt rules to intercept and route reports without changing DNS for each domain:

Configure SES receipt rules on a domain you control
SES receives the report and stores it in S3
Optionally trigger a Lambda function for processing
SES then forwards the report to your aggregation endpoint

This means adding a new sending domain to your DMARC monitoring setup does not require a DNS change - the routing happens at the SES layer.

Setting Up the Pipeline with Amazon SES and S3

Prerequisites:

A domain verified in Amazon SES
An S3 bucket for storing incoming reports
Optional: a Lambda function if you want to process reports automatically

Step 1: Create an S3 bucket

Create a bucket to receive the reports. You can use a single bucket for all domains if you structure the object key to include the domain name - for example: dmarc-reports/{domain}/report.zip.

Step 2: Configure a SES receipt rule

In the SES console, create a receipt rule for your domain. When a report arrives at the rule's designated mailbox, SES can:

Write the attachment to S3
Invoke a Lambda function for processing
Forward the report via SMTP to another address

The key advantage: the DNS MX record for your report destination points to SES, which handles the routing. Each new domain gets its own rule or gets caught by a catch-all pattern.

Step 3: Connect to your analysis pipeline

If you have a tool that processes DMARC reports (a SIEM, a custom aggregator, or DMARCFlow), you can either point SES to forward reports directly to its SMTP ingestion address, or have your Lambda function push report data to an API endpoint.

Handling Aggregate Reports (RUA) vs Forensic Reports (RUF)

Aggregate reports (RUA) are the workhorse of DMARC monitoring. They arrive as gzip-compressed XML and contain summarized sending data: source IPs, DKIM results, SPF results, and disposition outcomes. These are safe to forward and process at scale. RUA data is pseudonymous - it doesn't include message subjects or individual recipient addresses.

Forensic reports (RUF) are different. They contain a single failed message sample including the subject line and the authentication result for that specific message. They are sensitive by nature and arrive in a different format (usually a message/rfc822 attachment). Not all receivers generate them, and organizations often choose not to use RUF at all because of the sensitivity.

If you are building a forwarding pipeline, decide whether you need RUF at all. If you do, the same SES routing approach works, but treat the RUF destination with higher sensitivity controls.

How to Scale This Across Hundreds of Domains

The operational problem that kills self-hosted DMARC reporting at scale is DNS maintenance. Every time you onboard a new domain, you need to update its DMARC DNS record to include your aggregation address.

The SES approach changes this by making DNS changes optional. If you add a new domain:

Verify the domain in SES (one-time)
Create a SES receipt rule (or update a catch-all rule)
The sending domain's DMARC record can stay as-is if the receiver already forwards to a SES-verified domain - or you can point the new domain's DMARC record to your SES endpoint directly

For MSPs managing hundreds of client domains, this is the practical advantage: you route everything through one SES account and the routing rules handle new domains without case-by-case DNS changes.

Long-Term Retention with S3 Glacier

DMARC reports are useful beyond real-time monitoring. When something goes wrong - a third-party service starts sending unauthenticated email, or you discover a domain that hasn't been monitored in months - historical reports help you reconstruct what happened.

S3 Glacier provides cheap long-term storage for reports you want to keep but don't need to access daily:

S3 Standard: millisecond retrieval, ~$0.023/GB/month
S3 Glacier Instant Retrieval: 1-2 cents/GB/month, same-day access
S3 Glacier Flexible Retrieval: 1-4 cents/GB/month, minutes to hours retrieval

For most DMARC use cases, S3 Glacier Instant Retrieval balances cost and access speed adequately. Store reports in S3 Standard during the active monitoring period, then transition them to Glacier after 30-90 days using S3 lifecycle policies.

The tradeoff is retrieval speed. If you want reports immediately available during an incident, S3 Standard is the right tier. If you are storing primarily for compliance audits and don't need instant access, Glacier cuts storage costs by 80% or more.

The practical alternative: DMARCFlow handles report ingestion natively - you configure the receiving endpoint and the platform processes, stores, and presents the data without any SES, S3, or Lambda configuration on your side.

FAQ

Can I forward DMARC reports without breaking the spec?

Yes. The DMARC RFC does not prohibit SMTP forwarding or routing reports through your own infrastructure. You can point rua/ruf destinations to addresses you control.

Does forwarding DMARC reports expose sensitive data?

DMARC reports contain metadata about your email sending infrastructure, including third-party services and sending patterns. The forwarding path does not reduce that sensitivity - only the destination's access controls determine who can see the data.

What's the difference between RUA and RUF?

RUA (aggregate reports) summarize sending data across many messages - source IPs, authentication results, disposition outcomes. RUF (forensic reports) contain a single failed message sample, including subject line and authentication details. RUF is more sensitive and not universally generated by receivers.

Can I use this approach for hundreds of domains?

Yes, with SES receipt rules you can route reports from all domains through one account. Adding a new domain requires one-time SES verification and a receipt rule or rule set update - no per-domain DNS changes are strictly required if you route through an existing SES-verified domain.

How long should I keep DMARC reports?

At minimum, 30-90 days for active monitoring. For compliance or historical investigation, 12 months or longer is common. S3 with lifecycle policies lets you store reports in Standard for quick access and automatically transition older reports to Glacier for cost savings.