InboxRatio
Check your domain

Glossary term

DMARC aggregate reports: the daily census of your domain's mail

What DMARC aggregate reports are

DMARC aggregate reports are the feedback half of the DMARC protocol: XML documents that participating mailbox providers send you, typically once a day, summarizing every message they received claiming to be from your domain. Each report says which IPs sent the mail, how much, whether SPF and DKIM passed, whether the passes were aligned, and what the receiver did with the message.

You request them with the rua tag in your DMARC record:

_dmarc.yourbrand.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com"

Defined in RFC 7489 alongside the rest of DMARC, aggregate reporting is the protocol's answer to an otherwise impossible question: who is sending mail as your domain, worldwide, right now? Your own platforms are only part of the answer. Forgotten vendors, shadow-IT tools, forwarders and outright spoofers make up the rest, and aggregate reports are the only census that covers them all — because the data comes from the receivers, not from anything the sender controls.

The reports contain no message content and no recipient addresses. They are counts and verdicts, grouped by source, which is what makes providers willing to send them broadly.

How aggregate reports differ from forensic reports

RFC 7489 defines two report types, and they diverge in almost every dimension.

Aggregate reports (rua) are periodic summaries: one XML file per receiver per interval covering all observed traffic, passing and failing alike. No content, minimal privacy exposure, near-universal support — Google, Microsoft and Yahoo all send them. They answer fleet questions: what sources exist, what fraction aligns, what enforcement would break.

Forensic reports (ruf) are per-message failure samples: individual redacted copies sent at failure time. High privacy exposure, and consequently near-extinct support among major providers.

The operational rule of thumb: aggregate reports are the tool you build your DMARC rollout on; forensic reports are an occasional bonus you must not depend on. If you configure only one tag, it is rua.

How DMARC aggregate reports work

Requesting. Add one or more mailto: URIs to the rua tag. The optional ri tag requests a reporting interval, with 86400 seconds (one day) the default and the granularity most receivers honor regardless. Validate the record with a DMARC checker or build it with the DMARC generator.

External destinations. If reports should go to a different domain than the one being reported on (your monitoring vendor, say), RFC 7489 requires the destination to consent, by publishing a record at yourbrand.com._report._dmarc.vendor.com. Vendors do this for you; missing consent records are a classic reason reports silently never arrive.

Delivery. Each participating receiver mails you a gzip-compressed XML attachment. The filename and body identify the reporter, the domain and the interval covered.

Contents. Inside, each <record> groups traffic by source IP and result combination: message count, the envelope and header domains observed, raw SPF and DKIM verdicts, the aligned verdicts DMARC computed from them, and the disposition applied (none, quarantine or reject), including whether a local policy override (such as a trusted forwarder or a validated ARC chain) changed the outcome.

Interpretation at scale. One domain at modest volume collects reports from dozens of receivers; reading raw XML stops scaling within a week. Standard practice pipes rua to a parsing service and works from its dashboards. The blog guide to DMARC reports walks through the XML fields in detail.

Aggregate reports and your deliverability

Aggregate reports are the instrument panel for every authentication decision that affects placement.

Enforcement without breakage. Moving from p=none to p=quarantine or p=reject blind is how legitimate mail gets destroyed. The reports show, before any policy bites, exactly which sources would fail: the ESP whose return-path was never customized, the billing tool nobody remembered, the forwarding tail. The standard rollout is monitor at p=none, fix each legitimate source's SPF alignment or DKIM alignment, then enforce — with the reports as the checklist and the proof.

Compliance evidence. The Gmail and Yahoo bulk-sender requirements mandate a DMARC record; the reports are how you verify the mandate is doing what you think. A domain can "have DMARC" while its highest-volume source fails both aligned mechanisms, and only the reports say so.

Abuse visibility. Spoofing volume shows up as unaligned traffic from IPs you cannot attribute. Watching it appear, then watching dispositions turn to reject as you enforce, is DMARC's core value made visible — and a direct protection for the domain reputation your legitimate mail depends on.

Limitations and failure modes

The unread pile. The dominant failure: rua points at a mailbox nobody opens. The census runs, the evidence accumulates, and the enforcement-day surprise arrives anyway. Reports only work as a monitoring practice, not as a checkbox.

Attribution guesswork. Reports identify sources by IP, and shared ESP infrastructure means an IP maps to a platform, not to your account on it. Custom bounce domains and per-platform DKIM selectors are what make report rows attributable to specific vendors; set them up before you need the forensics.

Coverage is participation. Only receivers that implement DMARC reporting send reports. The large consumer providers do; plenty of smaller and corporate systems do not. The census is broad, never total, and small-receiver breakage can hide below its resolution.

Latency. Daily intervals mean a misconfiguration ships a day of damage before the reports say so. Aggregate data is a trend instrument; pair it with a pre-send check through the email authentication checker rather than using reports as your only alarm.

Volume mismatch on the receiving mailbox. Aggregate report traffic scales with your sending footprint. Pointing rua at a human inbox works for a hobby domain and buries a business one; a dedicated address feeding a parser is the durable setup.

Forwarding noise misread as attack. Unaligned traffic from university relays, alias services and mailing lists is the normal background of indirect mail flow, partially rescued by ARC at large receivers. Treating every unaligned row as spoofing leads to false alarms; source volume and disposition patterns tell the two apart.

Related terms

DMARC, DMARC forensic reports, SPF alignment, DKIM alignment, SPF record, DKIM, ARC, bounce domain, domain reputation.

Frequently asked questions

How do I start receiving DMARC aggregate reports? Publish a DMARC record with a rua tag pointing at a mailbox you control, even at p=none. Reports from major receivers typically begin arriving within a day or two of the record propagating.

How often do aggregate reports arrive? The default interval is daily per reporting receiver, and most providers send on that cadence regardless of the ri value you request. Busy domains receive many files per day, one per reporter.

Do aggregate reports contain personal data? No message content and no recipient addresses — only source IPs, counts, domains and authentication verdicts. This is why rua is broadly supported while its forensic sibling is not.

Can I send reports to a third-party monitoring service? Yes, and most teams should. The vendor publishes the external destination verification record RFC 7489 requires; your rua simply lists their address. Reports failing to arrive at a vendor usually trace to that verification record.

What should I look for first in my reports? Sources. List every IP block sending as your domain, attribute each to a platform or mark it unknown, then check alignment per source. Legitimate but unaligned sources are your fix list; unattributable volume is your spoofing picture.

My reports show failures but my mail delivers — why? Dispositions depend on your policy. At p=none failures carry no consequence yet, and even under enforcement receivers apply local overrides for trusted forwarders and validated ARC chains. The report's disposition column shows exactly which rule decided.

Publish rua today if you have not, and open one actual report this week: gunzip the attachment and read the source list raw once before handing the stream to tooling. Then keep the DMARC checker result and the report trends in the same weekly review — the record is the promise, the reports are the audit.

Sources