Why am I receiving multiple DMARC reports from the same domain?
Published 23 Apr 2025
Updated 31 Jul 2026
10 min read
Summarize with
Updated on 31 Jul 2026: We updated this guide for RFC 9990 and clarified how to separate valid reports from retransmissions.
Yes, receiving multiple DMARC reports from the same domain can be normal. The key detail is that "same domain" can mean the domain in your DMARC record, the sender domain in Header From, the reporting organization, or the receiving domain that generated the aggregate report. Those are not always the same.
The fastest answer is this: compare the XML report_id, attachment filename, reporting period, and content. Different values usually mean separate reports, even if the files arrived together and show the same policy domain. Message-ID helps trace email delivery, but it is not the primary DMARC report identity.
- Normal case: Different report IDs, filenames, reporting periods, or submitters mean separate aggregate reports.
- Duplicate case: The same report ID, filename, time window, and XML data usually mean repeat delivery.
- Action case: Group by report ID first, then review source IPs and domain matches inside the XML.
The direct answer
Multiple DMARC reports from the same domain usually mean you are receiving separate aggregate reports about the same sending domain. DMARC aggregate reporting is receiver-driven. Participating mail receivers typically send daily reports, although reporting can be more frequent, and each receiver controls how it groups its data.
A single day of mail can produce reports from many receiving systems. One reporting organization can also send more than one report because separate reporting sources generated files at the same time, or because the published DMARC policy changed during the reporting period. Arrival time does not prove duplication because receivers often send reports in batches.
Quick test
- Check XML: Compare report_id and date_range inside report_metadata.
- Check filename: Compare the receiver, policy domain, timestamps, and optional unique ID.
- Check subject: Compare the policy domain, submitter, and any report ID named there.
- Check email: Use Message-ID and Received headers to trace retransmission or local forwarding.
Treat this as a grouping problem before treating it as an authentication problem. Once report identities are sorted, review source IPs and domain matching. That order prevents false alarms.
What counts as a duplicate
A duplicate carries the same logical report identity or repeats the same data for the same reporting period. Under RFC 9990, a report ID must be unique among reports sent to the same domain, and a retransmission must reuse the original filename. The reporting organization can optionally reuse the report ID in Message-ID, so a different Message-ID does not prove that the XML data is new.
|
|
|
|
|---|---|---|---|
report_id | XML | Same logical report | New report |
Filename | Attachment | Retransmission clue | Separate file |
date_range | XML | Same UTC window | Other window |
Message-ID | Header | Same transport identity | New email, not necessarily new XML |
org_name | XML | Same organization | Other organization |
Compact identity checks for repeated DMARC report emails.
Duplicate confidence
Use stable report identity before judging whether the message is repeated.
Likely normal
Different identity
Different report IDs, filenames, or periods.
Needs review
Overlapping data
Overlapping periods with different report IDs.
Likely duplicate
Same identity
Same report ID, filename, period, and data.
This is why report volume can look high for a small sender. One mailbox or one day of low volume can still produce several aggregate files. For the expected daily pattern, see daily DMARC report volume.
Why an identical report can arrive again
Exact duplicates do happen. A report generator can retry after a temporary SMTP deferral or after losing the final delivery response. Copies can also converge when separate report addresses, aliases, forwarding rules, or distribution groups deliver the same attachment to one mailbox. A local import job can create another copy without any retransmission by the reporting organization.
- Confirm identity: Match the report ID, filename, UTC period, and XML data before discarding a copy.
- Trace delivery: Compare Received headers to see where the delivery paths split or repeated.
- Inspect routing: Check every rua destination plus mailbox aliases, forwarding rules, and group membership.
- Deduplicate safely: Keep one exact copy, but retain reports with different IDs or only partially overlapping periods.
Do not merge partial overlaps blindly
RFC 9990 says reporting periods should not overlap, but overlaps can occur. If two reports contain only some of the same time window, there is no reliable row-level method to subtract the repeated portion. Keep both reports separate for review instead of guessing which counts overlap.
Where to check the report identity
Open the raw email first, then open the XML attachment. In the email, inspect the subject, Message-ID, Received headers, and attachment filename. In the XML, inspect report_metadata. These fields show whether the message contains the same file again or a new report about the same policy domain.
Current DMARC aggregate report metadataxml
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"> <version>1.0</version> <report_metadata> <org_name>Sample Reporter</org_name> <email>reports@example-reporter.com</email> <report_id>1709343990.504071</report_id> <date_range> <begin>1709251200</begin> <end>1709337599</end> </date_range> <generator>Sample DMARC Reporter</generator> </report_metadata> <policy_published> <domain>example.com</domain> <p>none</p> </policy_published> <!-- record elements follow --> </feedback>
RFC 9990 defines the current aggregate report format, including the DMARC 2.0 XML namespace. Older RFC 7489-style reports can still appear while reporting systems adopt the new format. In both formats, the policy domain repeats across reports for your domain, while report_id, date_range, submitter, and filename carry the useful identity clues.
Same report
- XML ID: The report_id value matches exactly.
- Filename: The attachment filename matches exactly.
- Content: The period, rows, and counts are identical.
Separate report
- XML ID: The report_id value differs.
- Period: The UTC reporting window differs.
- Submitter: The subject or filename names a different receiver.
A flowchart for checking whether repeated DMARC reports are duplicates.
Why SPF can look failed when it passed
A common trap is reading policy_evaluated as the raw SPF result. DMARC aggregate reports carry raw authentication results and DMARC policy results. SPF can pass authentication for the return-path domain, then fail the DMARC policy check because that domain does not match the Header From domain.
SPF pass with DMARC policy SPF failxml
<policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> <auth_results> <dkim> <domain>example.com</domain> <result>pass</result> </dkim> <spf> <domain>mail.example.net</domain> <result>pass</result> </spf> </auth_results>
In that example, SPF passed for mail.example.net, but the visible sending domain was example.com. The DMARC policy row marks SPF as failed because the domains did not match. DKIM passed for example.com, so DMARC still passed. A policy row can show spf fail without meaning the sender's SPF record is broken.
Do not fix the wrong thing
Before changing SPF, confirm whether the failing value is the raw SPF result or the DMARC policy SPF result. If DKIM passes for the Header From domain, DMARC can still pass.
For a field-by-field explanation, compare the XML against rua and ruf reports. The distinction between authentication results and policy results matters in DMARC investigations.
How to troubleshoot the reports
When a mailbox gets 10 or 15 DMARC reports at once, do not start by editing DNS. Sort the reports into identity groups, then check whether any group points to an authentication gap.
- Save copies: Keep the original emails and XML attachments until the comparison is complete.
- Compare identity: Sort by report_id, filename, UTC period, and submitter.
- Trace copies: Use Message-ID and Received headers to investigate exact repeats.
- Review sources: Inspect source IPs, message counts, DKIM domains, and SPF domains in each group.
- Fix only gaps: Change DNS only when a legitimate sender fails DMARC after both authentication methods are checked.
The DMARC record itself should be simple. One policy domain should have one DMARC TXT record. Multiple rua destinations are allowed in a single record, but multiple DMARC TXT records at the same name break evaluation. If you suspect a DNS issue, check for multiple DMARC records before changing policy.
Simple rua recorddns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Suped's public DMARC checker confirms whether the TXT record is valid and whether more than one DMARC record is published.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After the record passes validation, review verified senders, unrecognized IPs, recurring forwarders, and sources that fail DMARC. Suped's domain health checker can check the wider SPF, DKIM, and DNS configuration when the issue extends beyond repeated reports.
How Suped helps with this
Suped's product collects aggregate XML reports, deduplicates stable report identities, and groups the remaining data by sender and receiver. This replaces manual attachment comparisons while preserving the report detail needed to investigate a repeated delivery or an authentication failure.
In Suped, DMARC monitoring shows source breakdowns and authentication health without requiring teams to open every XML file. Alerts can flag a trusted sender that starts failing, while the reporting view keeps the raw identity fields available for verification.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
Manual inbox review
- Parsing: You open each attachment and compare IDs yourself.
- Grouping: You build your own view of submitters and source IPs.
- Risk: You can confuse a retransmission with a separate report.
Suped workflow
- Parsing: XML reports are normalized into one reporting view.
- Grouping: Report identity and source data are grouped separately.
- Action: Authentication issues include context and remediation steps.
Views from the trenches
Best practices
Compare report IDs and submitters before changing DNS or treating repeats as failures.
Group aggregate files by receiver first, then review source IPs and authentication rows.
Use DKIM domain matches to confirm DMARC passes when SPF policy rows appear failed.
Common pitfalls
Treating the policy SPF value as the raw SPF result leads to unnecessary DNS edits.
Assuming one organization name means one receiver hides separate receiving domains.
Counting report emails instead of report IDs can inflate perceived DMARC problems.
Expert tips
Use the email subject and attachment filename to identify the submitter quickly.
Keep strict SPF mode in mind when return-path subdomains differ from Header From.
Separate duplicate delivery checks from authentication checks to reduce false alarms.
An Email Geeks discussion recommends treating different Message-ID values as separate deliveries until the XML identity is compared.
2024-03-08 - Email Geeks
An Email Geeks discussion notes that many reports can arrive together when a large receiver sends batched files for separate receiving domains.
2024-03-08 - Email Geeks
What to do next
Multiple DMARC reports from the same domain are normal when the report IDs, filenames, reporting periods, or submitters differ. They do not mean the DMARC record is broken. They usually contain separate receiver data about the same policy domain.
Investigate delivery duplication when the report_id, attachment filename, UTC period, and XML data match. Use Message-ID and Received headers to find the delivery path, then fix only legitimate senders that fail DMARC after both authentication methods are considered.
Decision rule
Different report identities mean separate reports. The same report ID and filename mean a likely retransmission. Policy SPF failure does not automatically mean SPF is broken.
