DMARC aggregate reports (RUA) are the single most operationally useful thing DMARC provides. They reveal every source sending mail claiming to be from your domain, with authentication results and enforcement dispositions per source IP. This article explains what the reports contain, how to read them, how to process them at scale, and how to use them to drive your UK domain's authentication posture.
An aggregate report is an XML document summarising, for a given domain and reporting window (usually a day), every message a receiver saw claiming to be from that domain. Each entry in the report contains:
d= of each signatureCrucially, the reports do not contain message content. They are metadata, not copies of mail.
Receivers that generate reports send them to the addresses in your DMARC rua= tag. Typical cadence:
The report arrives as an email with an XML or compressed XML attachment (ZIP or GZ). Filename usually follows the pattern receivertld!yourdomain!timestamp-start!timestamp-end.xml.gz. The subject line typically says "Report Domain: yourdomain.co.uk Submitter: ..." or similar.
A trimmed example:
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>1234567890</report_id>
<date_range>
<begin>1712448000</begin>
<end>1712534400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>firm.co.uk</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>203.0.113.25</source_ip>
<count>47</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>firm.co.uk</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>firm.co.uk</domain>
<result>pass</result>
<selector>2026q2</selector>
</dkim>
<spf>
<domain>firm.co.uk</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>Each <record> element summarises one source IP's behaviour during the reporting window. Real reports typically contain many records, one per source IP.
Reading aggregate reports by hand is not recommended, but occasionally useful for spot checks. Key elements:
org_name — which receiver sent this report (Google, Microsoft, Yahoo, etc.).source_ip — the sending IP the receiver saw. The crucial identifier.count — how many messages from that IP during the window.disposition — what the receiver did (none, quarantine, reject).policy_evaluated/dkim and spf — post-alignment results.auth_results — raw authentication results, including which domain SPF/DKIM were checked against.A record showing source_ip that you do not recognise, with count above a few dozen, is either a missed sender or a spoofing attempt. Investigate.
Industrial-strength aggregate report processing requires a tool. Options:
parsedmarcPython-based. Ingests email attachments, parses XML, stores in a database (SQLite, PostgreSQL, OpenSearch). Produces dashboards via Grafana or Kibana. Free; best for teams comfortable with running their own infrastructure.
Pricing ranges from free for very small volumes to several hundred GBP per month for enterprises with many domains. For most UK SMEs, under £50/month buys a service that fully manages aggregate report processing.
For large UK organisations with multiple domains, platforms like Proofpoint Essentials, Mimecast, and Agari include DMARC processing alongside broader email security. Bundled licensing often makes these cost-effective despite higher headline prices.
dmarc=pass. If not, configuration is broken.d=.| Report signal | Likely cause | Action |
|---|---|---|
| Known IP, both SPF and DKIM pass | Normal | None |
| Known IP, SPF pass but DKIM fail | DKIM configuration or rotation problem | Investigate selector and key |
| Known IP, DKIM pass but SPF fail | Likely forwarding scenario (DKIM survived) | Check if the "known IP" is actually a forwarder |
| Known forwarder IP, both fail | Forwarder modifying content, breaking DKIM | ARC deployment at forwarder |
| Unknown IP, low volume, both fail | Spoofing attempt | Note, rely on DMARC enforcement |
| Unknown IP, high volume, both fail | Forgotten legitimate sender OR major spoofing campaign | Investigate origin |
| Unknown IP, both pass | Legitimate sender you did not know about (rare) | Add to inventory and audit |
Aggregate reports do not contain message content, but they do contain metadata that could be sensitive:
Treat the reports as internal IT data. If you use a third-party DMARC service, check their data handling policies — most UK-relevant services are GDPR-compliant and do not share data. Under UK GDPR, the processing of aggregate report data does not usually trigger DPA requirements, since the data relates to infrastructure rather than individuals.
| Service | UK presence | Pricing model |
|---|---|---|
| Mail Hardener | UK-accessible | Flexible, used across SmartXHosting infrastructure |
| Red Sift | UK-founded | Enterprise; strong financial services footprint |
| dmarcian | International with UK customers | Tiered, free for small domains |
| EasyDMARC | International | SMB-friendly tiered |
| PowerDMARC | International | Budget-friendly tiered |
| NCSC Mail Check | UK public sector | Free for accredited gov.uk domains |
A mature DMARC processing setup typically exposes several dashboard views:
For a UK SME sending a few thousand messages per day, aggregate reports total perhaps 5-15 MB per month (XML is verbose but reports are short). For a mid-size organisation with 50,000+ daily messages, 100-500 MB per month is typical. Enterprise scale can reach multi-GB. Storage and indexing are not significant costs for any setup; processing time and dashboard maintenance are the real considerations.
The policy_evaluated/disposition element shows what the receiver actually did with each message. This may differ from your published policy in several ways:
pct= effects. At pct=50, half of failing mail shows a weaker disposition than your nominal policy.policy_override_reasons explaining why the receiver chose a different action — for example "mailing list detected" or "forwarded via trusted source".Use the disposition field to understand what receivers are actually doing, not just what you asked for.
Q: How many aggregate reports should I expect per day?
A: One per major receiver that saw mail from your domain in the previous 24 hours. Typically 5-15 reports per day for a UK business sending to UK recipients.
Q: Do reports contain private data I need to protect?
A: They contain infrastructure metadata (IPs, domains, volumes). Treat as internal IT data. Under UK GDPR they do not usually contain personal data.
Q: Can I see reports from receivers I do not directly interact with?
A: You see reports from any receiver that saw mail claiming to be from your domain — even if you did not deliberately send to them. Spoofing attempts against your domain will appear in the reports of receivers the attacker targeted.
Q: What if I receive no reports after publishing DMARC?
A: Usually means no receiver has yet seen mail claiming to be from your domain during the reporting window, or the rua= address is wrong. For a low-volume domain, wait a week and check.
Q: Can I process reports on a shared mailbox or is a dedicated one better?
A: Dedicated is better. Aggregate reports arrive daily from many receivers and fill a shared mailbox quickly. A dedicated mailbox feeding a processing service is the standard pattern.
Q: How long should I retain aggregate reports?
A: 12 months is a sensible default — long enough to see annual sending patterns and recognise anomalies against them. Audit-driven organisations may retain longer.
Q: Do aggregate reports show whether messages were phishing?
A: Indirectly. They show authentication failures; phishing usually fails authentication. But a spam message with valid SPF and DKIM also shows as "pass" — reports are about authentication, not content.
Q: Can receivers choose not to send aggregate reports?
A: Yes. Receivers are not required by the spec to send them. Google, Microsoft, Yahoo, Fastmail and most large receivers do; smaller ones sometimes do not. You see a subset of the total mail claiming to be from your domain.
Q: Is there a way to force immediate report delivery rather than daily?
A: No. The ri= tag in your DMARC record requests an interval but receivers are not obliged to honour it. Plan for daily.
Q: How do I use aggregate reports to justify a DMARC policy progression decision?
A: Look at the proportion of legitimate senders (by count or by volume) passing DMARC. When this is above 99% for two consecutive weeks, you have evidence to tighten policy. Dashboard tools make this judgement a single glance.
Q: Why do some reports show dmarc=pass despite SPF fail and DKIM fail?
A: A few edge cases: the receiver's ARC validation overrode DMARC using a trusted forwarder's chain; the receiver applied a local exemption (common for mailing lists); or the report reflects an older policy that allowed the message through. Check policy_override_reasons to see why.
Q: Are there situations where a legitimate sender consistently fails DMARC and there is nothing I can do?
A: Rare but yes — a provider that cannot support custom-domain DKIM authentication at all. Options: migrate to a compliant provider (best), route through a subdomain with relaxed DMARC (workaround), or accept the deliverability cost.
Q: Can I subscribe my IT monitoring (PagerDuty, Opsgenie) to DMARC failures?
A: Yes. Most processing services offer webhook or email alerts on significant anomalies — new source IPs, authentication failure rate crossing a threshold, specific receivers reporting problems. Configure alerts proportionate to your risk appetite.
Q: Do I need to respond to the report emails themselves?
A: No. The reports are sent to a one-way mailbox. Replies go nowhere useful. Just process the attachments.
Q: Does aggregating reports across multiple domains reveal patterns I would miss per-domain?
A: Yes — especially cross-domain spoofing campaigns where an attacker targets several of your domains simultaneously. Multi-domain dashboards (every major DMARC service supports them) surface these.
Q: What if a receiver stops sending me reports I used to get?
A: Usually means something changed at their end (new spam filter, report-generation pause, policy update). A gap of a few days is normal. A gap of weeks from a major receiver like Google warrants a look at whether mail is still flowing in that direction.
Q: How granular is the per-IP data? Can I correlate to specific outbound servers?
A: Per-IP is the finest granularity the reports provide. You can correlate to your known outbound servers by IP — if your mail server is at 203.0.113.25, every legitimate report record from that IP is your own mail. IPs you do not recognise are the interesting ones.
Q: Is there a simpler way to get a summary without running infrastructure?
A: Hosted services (EasyDMARC, PowerDMARC, dmarcian free tier) will process reports for one domain with zero infrastructure setup on your side. Point your DMARC rua= at their ingest address, log into their web UI, read dashboards.
Q: Do aggregate reports reveal the list of recipients at receivers?
A: No. Individual recipients are never in aggregate reports. Only source IP and aggregate count are exposed.
Q: If I run multiple domains, can I point all their DMARC rua at the same mailbox?
A: Yes. Reports include the domain name in the report metadata, so a processing service can distinguish. Centralised processing of multiple domains is the norm for UK businesses with brand groups.
Q: How long after publishing DMARC do reports typically start arriving?
A: The first reports usually arrive 24-48 hours after publication, from the major receivers. Smaller receivers may take a week or more. If you see no reports at all after a week, re-check the DMARC record for typos in rua=.
Q: Can I share aggregate reports with third parties for audit purposes?
A: Yes. The reports do not contain personal data and sharing them with auditors, pen testers, or security consultants is unrestricted. Be cautious about publishing them publicly — the source IPs do reveal some infrastructure detail that could inform a sophisticated attacker.
Q: Can I detect a specific phishing campaign against my domain from aggregate reports?
A: Often yes. A sudden appearance of a new source IP with high volumes, authentication failing, geographically far from your expected senders, is the classic pattern. Reports do not identify the attacker directly but reveal infrastructure and volume for your investigation.
Q: How do I treat aggregate reports under ISO 27001 or similar frameworks?
A: They are operational security telemetry. Include in your information asset inventory; retain per your retention policy; access-control appropriately. Most UK auditors are familiar with DMARC aggregate reports and expect them as evidence of email authentication monitoring.
Q: Is there a minimum sample size of reports needed before decisions become reliable?
A: Informally, 7-14 days of reports from your domain's primary receivers gives a reliable picture of sender landscape. Shorter windows risk missing low-volume senders; longer is always better but diminishing returns.