How to Forward DMARC Reports to a Third-Party Aggregator Using Amazon SES Rules

Amazon SES can forward DMARC reports to any email address or S3 bucket. Here's how to route them to a third-party DMARC aggregator and what commonly breaks.

Can I forward DMARC reports from Amazon SES to a third-party aggregator?

Yes. Amazon SES can route your DMARC aggregate reports (RUA) and failure reports (RUF) to any destination you specify including a third-party DMARC aggregator. DMARCFlow and similar services consume these reports to give you visibility into who is sending mail on behalf of your domain and whether that mail passes authentication.

The mechanism involves an SES receipt rule that either forwards reports by email or writes them to an S3 bucket.

The most common setup looks like this:

1. A receiving mail server gets a DMARC report generated by a recipient's mail system
2. That report arrives at the email address your domain's DNS publishes in its rua or ruf tag
3. SES receives that report through a rule you configure
4. SES either forwards it to your aggregator's address, or writes it to an S3 bucket your aggregator reads from

This is useful when you're sending from multiple domains using SES and want a single aggregation service to monitor all of them without setting up a unique report destination address per domain.

How to configure SES rules to forward DMARC reports

The exact steps depend on whether your aggregator wants reports by email or via S3. Most aggregators accept both.

Option A: Forward by email

1. In the SES console, go to Email Receiving → Rule Sets → Create Rule
2. Set the Recipients field to the email address specified in your domain's rua DMARC record (e.g., dmarc-reports@yourdomain.com)
3. Add an Email action: forward the message to your aggregator's intake address
4. Set the rule to Active and apply it to the appropriate domain

Option B: Write to S3, let the aggregator pull

1. In the SES console, create an S3 action within your receipt rule
2. Choose the S3 bucket where reports should be stored
3. Optional: add an SNS topic to notify your aggregator when a new report arrives
4. In your aggregator's settings, point it to the S3 bucket or the SNS topic

Both approaches work. Email forwarding is simpler to set up. S3 gives you a backup copy and works better with aggregators that consume via API or webhook.

What the RFC says about DMARC report destinations

DMARC reports go to the address(es) listed in your domain's rua (aggregate) and ruf (failure) DNS records. RFC 8483 defines the report format. RFC 6591 defines the ruf=mailto: redirect mechanism.

The important constraint: the address in your rua/ruf tag must either belong to the domain that sent the report, or the sending domain must explicitly redirect reports to that address using the redirect= parameter.

If you want reports from example.com forwarded to an aggregator you control, and SES handles mail for example.com, your DMARC record should look like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Then configure SES to receive mail for dmarc-reports@example.com and either forward it to your aggregator's address or write it to an S3 bucket.

If your aggregator provides a redirect domain (e.g. redirect=dmarcian.com or similar), the aggregator's documentation will tell you exactly what your DMARC record should look like. Using the wrong redirect target means reports go nowhere.

If this feels tangled, it is. Report routing is one of the most commonly misconfigured parts of DMARC deployment.

Why your forwarded reports might not arrive

Several things can go wrong between SES receiving a report and your aggregator processing it.

Wrong recipient domain. SES only receives mail sent to addresses it is configured to accept. If your rua tag points to dmarc@otherdomain.com but SES only handles mail for yourdomain.com, the reports never arrive.

RFC compliance gaps in forwarded reports. SES-forwarded reports are often reformatted by the forwarding MTA chain. Headers get rewritten, MIME structure changes, and some fields that should be present are silently dropped. Many aggregators receive malformed reports and either discard them silently or show partial data. DMARCFlow handles parsing reports with missing or reordered fields without failing.

SNS topic misconfiguration. If you're using the S3 + SNS approach and the SNS topic doesn't have a working subscription to your aggregator's endpoint, new reports pile up in S3 with no notification sent.

Aggregator doesn't support the redirect domain mechanism. Not all aggregators support redirect=. If you're relying on redirection, confirm your specific aggregator handles it before configuring your DNS.

Report sent to the wrong address. Your rua tag must match the domain SES is configured to receive mail for. A mismatch means reports go to the wrong place entirely.

How to check if your DMARC reports are well-formed

SES-forwarded reports tend to arrive with stripped headers and reordered XML fields. A quick check:

1. Find a report in your S3 bucket or inbox
2. Open the XML, it should have a feedback root element with report_metadata, policy_published, and record blocks
3. Common issues: <report_metadata> missing <org_name>, <date_range> with incorrect values, <record> entries without a valid source_ip

If your reports fail to parse in any tool, DMARCFlow handles non-compliant field ordering and missing optional elements that cause other parsers to error out. It accepts reports forwarded through SES or any other MTA chain without requiring pre-processing.

FAQ: Forwarding DMARC reports through SES

Does SES forward RUF failure reports the same way as RUA aggregate reports?

Yes, but RUF reports are typically larger and sent less frequently. Most aggregators handle both formats. Be aware that some receiving mail servers limit how often they'll send RUF reports, so don't rely on them for real-time monitoring.

Can I forward reports from multiple domains to one aggregator address?

Yes, if all the domains' DMARC records use the redirect= parameter pointing to the same aggregator domain, or if they all use the same rua address and SES is configured to receive mail for all those addresses.

What happens if SES receives a DMARC report for a domain it doesn't send mail for?

It depends on your SES receipt rule. If the envelope-recipient domain matches a rule, SES processes it. If not, it may accept the message with no action or reject it. Configure your rules to be explicit about which recipient addresses trigger report handling.

Can I route reports to different aggregators per domain?

Yes. Create separate SES receipt rules with different recipient addresses. Point each domain's rua tag at its corresponding address, and route each address to a different aggregator or endpoint.

Does SES charge for handling DMARC reports?

SES charges apply per jthousand emails received. DMARC reports are small but numerous, a high-volume sender might generate thousands of reports per day. At 10,000+ domains reporting, monthly SES receiving costs can reach tens of dollars. Check your SES receiving costs if you're at scale.

Does the redirect= DMARC tag work with any third-party aggregator?

No. The redirect= parameter (RFC 6591) tells receiving mail servers to send their DMARC reports to a different domain's address. For this to work, the target domain must publish an _report._dmarc. DNS record accepting reports for the redirecting domain. Not all aggregators implement this correctly. If your aggregator doesn't support it, set up SES to receive reports directly and forward them by email or S3.

Bottom line

Forwarding DMARC reports through SES to a third-party aggregator is straightforward in principle. The practical difficulty is that report routing involves at least three systems that all need to agree: the sending domain's DNS, the receiving mail server that generates the report, and SES as the intermediary. Any mismatch in recipient addresses or redirect domains silently breaks the pipeline.

If you're forwarding reports and finding that your aggregator shows gaps or malformed data, DMARCFlow is built to handle the non-standard formats that SES and other forwarders often produce, without requiring you to pre-process or clean the reports yourself.