Why does AMAZON -SES sends DMARC aggregate reports in response to my own DMARC a...

I have a doman used for email: example.com. The DMARC record looks like:

v=DMARC1; p=reject; np=reject; aspf=r; adkim=r; pct=100; rua=mailto:[email protected]

That is to say, the address used to receive DMARC reports is on a sub-domain mta.example.com. The same email address is used as the sender of my outbound DMARC reports.

I have noticed that I receive DMARC reports from AMAZON-SES with mta.example.com as the envelope/header from domain. This domain is not used for any other purposes, so these reports can only be in response to my own outbound DMARC reports.

It seems strange that anyone would be sending DMARC reports in response to other DMARC reports. If everyone did that then we'd see endless ping-pong of reports. And I'm not receiving any records for mta.example.com in the DMARC reports I receive from other mail providers.

Is this normal? Or is there something strange about my outbound DMARC reports that causes Amazon SES to include them in its own DMARC reports?

I am using Rspamd to generate the reports. My /etc/rspamd/local.d/dmarc.conf looks like:

reporting {  
   enabled = true;  
   email = "[email protected]";
   domain = "example.com";
   org_name = "example.com";
   smtp = '::1';
} 

Is this normal?

Yes, it is. DMARC reports are ordinary email messages and are therefore subject to DMARC evaluation like any other email. However, they are evaluated based on the domain in the message's RFC 5322 From header (e.g., mta.example.com), not the domain being reported on (e.g., example.com).

Consequently, if a receiver includes such a message in its own aggregate report, it will be reporting on the sending domain (mta.example.com), not recursively reporting on example.com. There is therefore no inherent "ping-pong" loop. Likewise, the RFCs do not require the RFC 5322 From domain of a DMARC report to match the domain being reported on, so a completely separate domain (e.g., example.net) could also be used to send reports on behalf of example.com.

How to avoid receiving reports for the reporting subdomain?

If you do not wish to receive DMARC reports for the reporting subdomain, publish a DMARC record specifically for that subdomain without rua (and ruf, if desired). Otherwise, the reporting subdomain inherits the applicable DMARC policy from the RFC 7489, 3.2 Organizational Domain (or the sp policy, if present), in accordance with RFC 7489, 6.6.3 (Policy Discovery).

Without reporting enabled, I would keep a strict DMARC policy for mta.example.com to reject forged messages, while ensuring that legitimate DMARC reports authenticate correctly. Although either SPF or DKIM alignment is sufficient for DMARC, aligning both is a sensible best practice to maximize deliverability, since you will no longer receive DMARC reports that provide visibility into legitimate authentication failures.