DMARC aggregate vs forensic reports

2 June 2026 · 12 min read

DMARC aggregate vs forensic reports: what each one tells you

Turning on DMARC without reading its reports is like fitting a smoke alarm and then taping over the speaker. The whole point of a DMARC record is not the p= tag on its own. It is the feedback loop that the standard switches on the moment you publish a valid policy. That feedback arrives in two very different formats, and understanding the difference between them is the single most important skill for anyone trying to move a domain from p=none to p=reject safely.

The two report types are aggregate reports, requested with the rua tag, and forensic (also called failure) reports, requested with the ruf tag. They sound similar and they are often mentioned in the same breath, but they answer completely different questions, carry completely different privacy implications, and are produced by completely different sets of mailbox providers. This guide walks through exactly what each one contains, why one of them has effectively gone extinct, the privacy and legal considerations you need to weigh, and how to turn the raw data into the decisions that actually protect your domain.

If you have not yet published a record at all, start with the DMARC checker to see what (if anything) is live today, then come back here to plan what reporting to request.

A quick refresher: where reports come from

When a receiving mail server (Gmail, Microsoft 365, Yahoo, a corporate gateway and so on) accepts a message that claims to be from your domain in the visible From: header, it runs DMARC. It checks whether SPF or DKIM passed and, crucially, whether the passing mechanism is aligned with the domain in the From: header. The result of that evaluation, pass or fail, is what gets reported back to you.

Two tags in your DMARC record control where that feedback is sent:

• rua=mailto:dmarc-agg@yourdomain.com requests aggregate reports.
• ruf=mailto:dmarc-fail@yourdomain.com requests forensic / failure reports.

A minimal monitoring record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1

Both tags are optional. A record with no rua and no ruf is perfectly valid, and the receiver will still enforce your policy. It just will not tell you anything, which defeats the purpose of monitoring. The DMARC generator builds a syntactically correct record with these tags in place, and you can read the meaning of every tag on the DMARC glossary entry.

Aggregate reports (rua): the workhorse

Aggregate reports are the data you will actually live by. They are sent, by convention, once every 24 hours by participating receivers. Each report is an XML document, usually gzip-compressed, delivered as an email attachment to whatever address (or HTTPS endpoint) you put in the rua tag.

The clue is in the name. An aggregate report does not contain individual emails or anything resembling a message. It is a statistical roll-up of every message a single receiver saw from your domain during the reporting window, grouped by sending source.

What is inside an aggregate report

Each report opens with metadata that identifies the reporter and the window it covers:

• The organisation that generated the report (for example google.com or Enterprise Outlook).
• A report ID and the begin and end timestamps of the 24-hour window.
• The published policy the receiver saw in your DNS at evaluation time: your p, sp, pct, alignment modes (adkim, aspf) and so on. This is genuinely useful for catching the case where a stale or wrong record is cached somewhere.

Then comes the body: a series of records, each one a row of grouped results. For every distinct combination of sending IP address and authentication outcome, the report tells you:

• The source IP that sent the mail.
• The count of messages from that IP with that exact result.
• The DMARC disposition the receiver applied: none, quarantine or reject.
• The DKIM result and the domain/selector it was signed with.
• The SPF result and the MAIL FROM (envelope) domain it checked.
• The all-important alignment outcome for both SPF and DKIM.

A single row reads, in plain English, like this: "On the 14th, IP 203.0.113.5 sent 412 messages claiming to be from your domain. DKIM passed and was aligned. SPF passed but was not aligned. We applied a disposition of none."

Why aggregate reports are the foundation of enforcement

That structure is exactly what you need to answer the only question that matters before you tighten your policy: am I about to break legitimate mail?

Every aligned, passing source in your aggregate data is a sender you have already authenticated correctly. Every passing-but-unaligned or outright failing source is either a legitimate service you have not finished configuring or a spoofer. You cannot tell which from the IP alone, but you can investigate each one, and the message counts tell you how much traffic is at stake.

This is why the standard workflow is: publish p=none with rua, collect a few weeks of aggregate data, identify and fix every legitimate sender until it aligns, then ratchet the policy up. The aggregate reports are the map. For the deeper enforcement journey see our walkthrough on moving from p=none to p=reject and the practical requirements overview.

The catch is volume and format. A busy domain receives dozens of these XML files a day from dozens of reporters, and reading raw XML by hand is miserable. That is exactly what a parser is for. You can paste a single report into the DMARC report analyzer to decode it instantly, or use ongoing monitoring to ingest every report automatically and chart sources over time.

Forensic / failure reports (ruf): the rare close-up

Where aggregate reports are a statistical summary, forensic reports are the opposite: a detailed, near-real-time copy of an individual message that failed DMARC. They are defined in RFC 6591 using the AFRF (Authentication Failure Reporting Format), which wraps the failing message in a structured report.

A forensic report is generated at the moment of failure, not batched once a day, and it typically includes:

• The message headers: From, To, Subject, Date, Message-ID, Received chains and the authentication results.
• The source IP and the SMTP transaction details.
• Often the message body, or at least a redacted version of it.
• The specific reason the message failed: SPF failure, DKIM failure, or alignment failure.

If aggregate reports tell you 412 messages from this IP failed, a forensic report shows you one of those exact messages, headers and all. For diagnosing a single confusing failure (a particular newsletter that will not align, a one-off bounce pattern) that close-up can be genuinely helpful.

The fo tag: controlling when forensics fire

The fo tag governs what triggers a forensic report, assuming the receiver sends them at all:

• fo=0 (the default): generate a report only if both SPF and DKIM fail to produce an aligned pass.
• fo=1: generate a report if either SPF or DKIM fails to produce an aligned pass. This is the most useful and most common choice.
• fo=d: generate a report on any DKIM failure, regardless of alignment.
• fo=s: generate a report on any SPF failure, regardless of alignment.

You can combine the letter values, for example fo=1 is what most operators set when they want forensic visibility. But there is a very large asterisk on all of this.

The elephant in the room: forensic reports barely exist any more

Here is the honest, practical truth that a lot of older guides skate over. The overwhelming majority of mailbox providers do not send forensic reports at all. Google, Microsoft, Yahoo and most other major receivers have either never sent them or stopped years ago. If you publish a ruf tag today, you should expect a trickle of reports from a handful of smaller or regional providers, and on many domains, none whatsoever.

The reason is privacy, which we will come to next. A forensic report can contain the full content of a real person's email, including the recipient address and the subject line. Sending that to a third party, even the legitimate domain owner, is a data-protection minefield. Faced with the choice between a privacy liability and an aggregate report that carries no personal content, providers overwhelmingly chose to keep aggregate reporting and quietly drop forensics.

So the realistic expectation is:

• Aggregate reports (rua): universal. Essentially every meaningful receiver sends them. This is your real data source.
• Forensic reports (ruf): mostly dead. Nice to receive when you do, but you cannot build a process around them and you must never treat their absence as a problem.

Do not panic if you publish ruf and never see a single report. That is the normal, expected outcome in 2026. Your enforcement decisions should rest entirely on aggregate data.

Privacy and legal considerations

The privacy gap between the two report types is the whole story, and it cuts in two directions: what you receive, and what you send.

Receiving forensic reports puts data in your lap

If you do publish ruf and reports start arriving, you are now receiving copies of email messages, potentially including personal data belonging to third parties (the recipients, the senders being impersonated, anyone named in a subject line). Under the UK GDPR and the EU GDPR, that is personal data you are now processing, and you need a lawful basis, a retention policy, and appropriate security around the mailbox that receives it. A forensic mailbox quietly filling up with copies of real emails is a quiet liability nobody signed off on.

Mitigations exist. The ruf standard allows for redaction, and some senders hash or strip the local part of addresses. But you cannot rely on every reporter redacting, so if you collect forensic reports you should treat that mailbox as containing sensitive data and lock it down accordingly.

Aggregate reports are far safer, but not content-free

Aggregate reports contain no message bodies and no subjects, which is exactly why they survived. They do still contain IP addresses, which can be personal data in some contexts (a self-employed sender on a static IP, for instance). In practice the risk is low and the operational value is high, so essentially everyone collects them. Just be aware that "aggregate" does not mean "anonymous"; it means "no message content".

A note on where you point your reports

Both rua and ruf can point to an address on a domain you do not own, which is how third-party platforms ingest your data. The DMARC standard guards against abuse here: if you send reports to a different domain, that external domain must publish a small authorisation record (a TXT record at yourdomain.com._report._dmarc.theirdomain.com containing v=DMARC1) confirming it is willing to receive them. If that record is missing, conforming receivers will refuse to send reports to the external address. It is a common, silent reason that reports never arrive, so it is worth verifying whenever you delegate reporting.

How to actually put the reports to use

Collecting reports is step one. Turning them into action is the part that protects your domain. Here is a concrete workflow built around aggregate data, with forensics as an optional bonus.

1. Start in monitoring mode

Publish p=none with a working rua address and fo=1. Confirm the record is valid with the DMARC checker and confirm any external reporting destination is authorised. At this stage you are deliberately enforcing nothing; you are only listening.

2. Build an inventory of your legitimate senders

Over the first one to two weeks, your aggregate reports will reveal every IP and service sending mail as your domain. You will almost always find more than you expected: your marketing platform, your CRM, your helpdesk, your invoicing tool, a forgotten server in a branch office. For each source, decide: is this us, and is it aligned?

• If it is legitimate and already passing aligned DKIM or SPF, it is safe.
• If it is legitimate but failing or unaligned, you have configuration work to do.
• If you do not recognise it, it is either shadow IT or a spoofer.

3. Fix alignment, source by source

For each legitimate-but-failing sender, get it to produce an aligned pass. That usually means adding the sender to your SPF record (watch the ten-lookup limit, which the SPF checker flags) and, far more durably, setting up DKIM signing on your own domain so the d= value aligns. Use the DKIM checker to confirm each selector resolves and signs correctly. Read the alignment mechanics on the DMARC alignment glossary entry if any of this is fuzzy.

DKIM alignment is the one to prioritise, because it survives forwarding where SPF alignment does not.

4. Watch the aligned percentage climb

As you fix each source, the proportion of your aggregate traffic showing an aligned pass should rise toward 100%. When the only remaining failures are sources you have confirmed are not you (in other words, genuine spoof attempts), you are ready to enforce.

5. Ratchet the policy up

Move to p=quarantine, optionally with pct= to phase it in, and keep reading the aggregate reports. When that stays clean, move to p=reject. At that point every spoofed message claiming to be your domain is rejected outright, and your aggregate reports become an ongoing intrusion log: every failure line is now an attacker who just bounced off your domain. See the DMARC policy and pct entries for the staging details.

6. Keep forensics on, but expect little

Leaving ruf= and fo=1 in your record costs nothing and occasionally yields a useful close-up of a specific failure from one of the few providers that still send them. Just secure that mailbox, set a short retention period, and never block on forensic data you may never receive. Your decisions come from aggregate reports; forensics are a nice-to-have.

Reading a real aggregate row, end to end

To make this concrete, here is how to interpret one record from an aggregate report when you are staring at the XML:

<record>
  <row>
    <source_ip>198.51.100.22</source_ip>
    <count>87</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>yourdomain.com</header_from></identifiers>
  <auth_results>
    <spf><domain>mail.vendor.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Decode it like this. Eighty-seven messages came from 198.51.100.22 claiming to be from yourdomain.com. SPF passed, but it passed for mail.vendor.net, not your domain, so SPF is not aligned. There is no aligned DKIM either. Under DMARC this message fails overall, and the only reason it was not quarantined is that your policy is still none. The fix is clear: this is a vendor sending on your behalf, so you either get them to DKIM-sign as your domain or you accept that, under enforcement, their mail will be rejected. That single decision, repeated across every source, is the entire enforcement project. The DMARC report analyzer does this decoding for you on every row.

The practical takeaway

Aggregate (rua) and forensic (ruf) reports are not two flavours of the same thing. Aggregate reports are a daily statistical summary with no message content, sent by essentially every receiver, and they are the data you will use to take your domain safely to p=reject. Forensic reports are detailed copies of individual failing messages, governed by the fo tag, valuable in theory but almost extinct in practice because of the privacy risk of shipping real email content to a third party. Publish both tags, secure your forensic mailbox if anything ever lands in it, but build your entire enforcement process on the aggregate data.

If reading XML by hand is not how you want to spend your week, decode a single report with the free DMARC report analyzer, or let our hosted monitoring ingest every report automatically, track every sending source over time, and alert you when something changes. And if you would rather skip the whole exercise, our done-for-you DMARC service collects and reads the reports for you and walks your domain from p=none to p=reject with no email outage along the way.