Aggregate report analysis

21 June 2026 · 17 min read

Aggregate reports, the rua data that mailbox providers send back to you every day, are the single most useful feedback loop in email authentication. They tell you who is sending mail as your domain, how much of it passes DMARC, and what receivers are doing with the rest. This guide explains how to read that data inside the DMARC Engine dashboard: the Aggregate Reports and Source Analysis tabs on the Hosted DMARC page, the wider Analytics page, and, crucially, how to act on sources you do not recognise.

If you have not yet published a record or delegated your CNAME, start with Hosted DMARC and Delegating your DNS first. This guide assumes reports are already flowing into your hosted ingestion address.

What an aggregate report actually is

Before you open a single chart, it helps to know what you are looking at. An aggregate report is an XML document that a receiving mail provider (Google, Microsoft, Yahoo and many others) generates once per reporting period, usually daily. It does not contain message content. Instead, for every source IP that sent mail claiming to be from your domain, it records:

how many messages that IP sent,
whether those messages passed or failed SPF,
whether they passed or failed DKIM,
whether they aligned and therefore passed DMARC, and
what disposition the receiver applied (delivered, quarantined or rejected).

When you publish a DMARC record through DMARC Engine, the Aggregate Report Email (rua) field is pre-filled with a hosted ingestion address in the form r-<token>@reports.dmarcengine.com. Receivers send their reports there, we match each report back to your domain by its token, parse the XML, and aggregate it into the views described below. You never download or open an XML file. If you ever do need to inspect a raw report by hand, the free DMARC report analyzer accepts an uploaded file, but for day-to-day work the dashboard does the parsing for you.

Aggregate data is summarised, not per-message. A source either passed a check cleanly across the whole period or it did not. That distinction matters when you read the pass and fail badges later, so keep it in mind.

Where the data lives

There are two places to read aggregate data, and they answer different questions:

The Aggregate Reports and Source Analysis tabs on the Hosted DMARC page (/dmarc) are per-domain, source-level views. Use them to investigate one domain in depth: which IPs send for it, how each authenticates, and what receivers did with the mail.
The Analytics page is a trend-and-aggregate view. Use it to watch pass rates move over time, compare SPF against DKIM at a glance, and see an account-wide picture across all your domains at once.

You will move between the two constantly. The analytics page tells you whether things are getting better or worse; the source-level tabs tell you exactly which source to fix. The sections below take each in turn.

Opening the Aggregate Reports tab

In the dashboard, open Hosted DMARC from the navigation. Beneath the page header is a tab bar with four tabs: Manage Records, Record Builder, Aggregate Reports and Source Analysis. Click Aggregate Reports.

At the top of the tab is a domain picker dropdown that defaults to Select a domain. Every source, alignment and disposition breakdown on this tab is calculated for a single domain, so nothing renders until you choose one. Pick a domain from the dropdown to load its data.

Two things can happen next:

If reports have arrived, the Aggregate Report Analysis card fills with statistics and charts.
If none have arrived yet, you see "No aggregate report data has been received for this domain yet." Reports typically begin appearing within a day or two of publishing a record with the hosted rua in place, because most receivers batch and send once per day. If you published recently, this is normal; check back tomorrow.

The four summary statistics

Once data loads, the tab leads with four headline numbers. Read them left to right as a quick health check before you dig into the detail.

Emails Passed (green): the total number of messages that passed DMARC across the reporting window. This is your volume of correctly authenticated mail.
Emails Failed (red): the total number of messages that failed DMARC. Failing mail is not automatically malicious; it is very often legitimate mail from a source you have not yet aligned. The job of this whole tab is to tell those two cases apart.
DMARC Alignment (teal): the percentage of all evaluated messages that passed, calculated as passed divided by the sum of passed and failed. This is your single most important figure. Aim to push it toward 100% before you tighten policy, because every percentage point below 100 represents mail that an enforcing policy would have quarantined or rejected.
Sending Sources (amber): the number of distinct sources (IP addresses) seen sending as your domain. Read this number with suspicion the first time. Most organisations are surprised by how high it is, because it includes every newsletter tool, ticketing system, CRM and forgotten script that has ever sent mail in your name. A high count is frequently the first sign of either shadow IT or outright spoofing.

Treat DMARC Alignment and Sending Sources together. A high alignment percentage with a low, fully recognised source count means you are nearly ready to enforce. A low alignment percentage or a source count full of unknowns means you have work to do first.

The source table

Below the statistics is a paginated table, ten rows at a time, with one row per sending source. This is where investigation actually happens. The columns are:

Source IP: the sending address, shown in a monospace font so it is easy to copy.
Volume: the message count from that source over the period. This column is sortable, so you can rank your busiest senders to the top.
SPF, DKIM and DMARC: a green Pass or red Fail badge for each check.

Read the pass and fail badges carefully. A source shows Pass only when every message from it passed that check across the whole period. If even one message failed, the badge reads Fail. So these are best read as "did this source pass cleanly", not as a percentage. A source that is almost perfect but has a handful of failing messages will still show Fail, which is intentional: it flags the source for a look rather than letting a small problem hide behind a rounded number.

The fastest triage is to sort by Volume descending and scan the DMARC column from the top down. High-volume sources failing DMARC are always your priority, because they represent the largest amount of mail that an enforcing policy would block. A low-volume source failing DMARC might be a one-off test, a scanner, or a spoof attempt that never reaches anyone; a high-volume source failing DMARC is a service your business depends on that is not yet authenticated.

To diagnose what a specific source should be publishing, the free SPF checker and DKIM checker let you confirm the records that sender ought to have in place. Keep them open in another tab as you work down the list.

Pass / Fail Volume Over Time

When daily data is available, a wide bar chart titled Pass / Fail Volume Over Time plots DMARC-passing volume in green against failing volume in red, day by day across the reporting window.

This chart is about trends, not absolute numbers. A steady run of mostly green bars with a thin red sliver is healthy and stable. The things to watch for are changes:

A sudden red spike on one day usually means a new source started sending and is not aligned yet, or an existing source broke (an expired DKIM key, a changed sending IP that fell outside your SPF record). Cross-reference the date against any change you made to your sending setup.
A slow, creeping rise in red over several days often means a campaign tool or new department began sending in your name without anyone telling you.
A red spike with no matching legitimate activity can indicate a spoofing run. This is exactly the kind of event that justifies moving to enforcement, because under p=reject that red volume would be blocked instead of delivered.

Always resolve a red spike before you tighten policy. Tightening policy while red is elevated converts that failing mail from "delivered anyway" into "quarantined or rejected", and if any of it turns out to be legitimate, you have just blocked real mail.

Disposition Breakdown

Beside the trend chart is the Disposition Breakdown donut, which shows what receivers actually did with your mail. The total message count sits in the centre of the donut. The three slices are:

None / Delivered (green): messages that were delivered. This includes both DMARC-passing mail and failing mail that was not actioned, which is precisely what you expect under p=none.
Quarantine (amber): messages sent to the spam or junk folder under your quarantine policy.
Reject (red): messages blocked outright under your reject policy.

The key skill here is reading the donut against your current policy. Under p=none the donut is almost entirely green even when alignment is poor, because nothing is being enforced. That green is not a sign of health; it simply means no policy is in effect. The real health signal at this stage is the DMARC Alignment statistic above, not the disposition donut.

As you move to quarantine and then reject, the amber and red slices grow to represent mail that would previously have been delivered. Before you escalate further, confirm those slices are genuinely unwanted mail and not a legitimate source you forgot to align. The disposition donut and the source table are complementary: the donut tells you how much mail is being actioned; the table tells you which sources it came from.

Alignment Analysis: SPF vs DKIM by Source

The final chart on the tab, Alignment Analysis: SPF vs DKIM by Source, is a grouped bar chart comparing SPF alignment (green) against DKIM alignment (teal) as percentages, for your top sending sources. A legend beneath labels SPF Alignment % and DKIM Alignment %.

DMARC passes when at least one of SPF or DKIM both passes and aligns. This chart shows you which method is carrying each source, and that information changes how you fix a failing source:

A source strong on DKIM but weak on SPF is usually fine, because DKIM survives forwarding and mailing lists where SPF breaks. Do not chase the SPF bar up if DKIM is solid.
A source strong on SPF but weak on DKIM is more fragile, because forwarded copies of its mail will fail. Where you can, get the source signing with DKIM as well.
A source weak on both is your fix-it list. It will fail DMARC outright, and it must be aligned before you can safely enforce.

Getting at least one method aligned per legitimate source is the prerequisite to moving your policy past none. This chart is the clearest single view of how close you are to that goal.

Source Analysis

The Source Analysis tab is a focused view built around one question: who is sending as my domain? Where the Aggregate Reports tab mixes statistics, dispositions and alignment together, this tab strips everything back to an inventory of senders. Use it when you are building or auditing your list of legitimate sources before enforcement.

Click the Source Analysis tab. It opens with the same domain picker dropdown. Choose a domain. If none is selected you see a Select a domain prompt; if no reports have arrived you see "No source data yet."

With data loaded, the tab shows two panels side by side.

Email Volume by Source

This is a donut chart breaking total mail volume down by sending source, with the total emails count in the centre. Sources are labelled by organisation name where we can identify them, falling back to the raw IP where we cannot. This is the quickest way to see who your dominant senders are. A healthy chart is one where every large slice is a service you recognise and expect: your mail platform, your marketing tool, your transactional provider. An unfamiliar large slice is the thing to investigate first.

Sending Source Breakdown

Beneath or beside the donut is the Sending Source Breakdown table, a paginated list ten rows per page, with the same columns as the aggregate source table: Source IP, Volume (sortable), and SPF, DKIM and DMARC pass badges. Use this to work methodically through every source, ticking off the ones you recognise and chasing down the ones you do not.

The disciplined workflow on this tab is:

Sort by Volume so the biggest senders come first.
For each source, decide: is this a legitimate service I use?
For every legitimate source, confirm it aligns on SPF or DKIM (use the badges and the SPF checker and DKIM checker to verify).
For every source you cannot account for, investigate before doing anything else.

Acting on unknown sources

An unknown source, an IP sending as your domain that you cannot immediately tie to a known service, is the single most important thing aggregate reports surface. Do not ignore it, and do not rush to block it. Work through it deliberately.

First, identify it. The Email Volume by Source donut may already give you an organisation name. If it shows only an IP, look the IP up; it frequently resolves to a recognisable provider (a CRM, a help-desk tool, a payment processor sending receipts). Many "unknown" sources turn out to be a department or vendor that legitimately sends on your behalf without anyone having told the team that manages DNS.

Once you have identified it, decide which of three cases it is:

A legitimate sender you forgot about. This is the most common outcome. The fix is to authenticate it, not block it: add the provider to your SPF, set up DKIM signing for it, and confirm in the next report cycle that its DMARC badge turns to Pass. Hosted SPF and Hosted DKIM cover how to bring a new sender into alignment. Only once it aligns is it safe to enforce.
A legitimate sender you no longer use. Sometimes a source is a tool you have since stopped using, still sending the odd automated message. Decommission it properly at the source so it stops sending in your name, rather than relying on policy to suppress it.
An impersonator. If a source sends meaningful volume, fails DMARC, and matches nothing you use, you are likely looking at spoofing or a phishing run using your domain. This is the threat DMARC exists to stop. The correct response is not to block that one IP (the attacker will simply move) but to complete your journey to p=reject, at which point every unaligned source, including this one, is rejected by receivers automatically.

The golden rule is sequencing: authenticate every legitimate source first, verify it aligns in a fresh report cycle, and only then tighten policy. If you raise enforcement while a legitimate source is still failing, you will block real mail. The whole point of reading aggregate data before enforcing is to make sure that never happens. For the full step-by-step path, see The enforcement journey, and for why a permanent p=none is a trap, see why p=none is false security.

The Analytics page

The source-level tabs are for investigation. The Analytics page is for monitoring trends and seeing the whole account at once. Open Analytics from the navigation. Two controls sit at the top:

A range selector offering 7d, 30d and 90d. This sets the time window for everything on the page. Use 7d to check the effect of a recent change, and 30d or 90d to judge a real trend rather than daily noise.
A domain picker that can be set to All or to a single domain. All gives you an account-wide roll-up across every domain, which is the view to use when you manage several domains and want one number to watch. Selecting a single domain narrows everything to that domain.

The page has two tabs: Overview and Sources. If there is no data for the chosen window, both show "No analytics data for this period"; widen the range or wait for more reports to arrive.

Overview

The Overview tab leads with five stat cards:

Emails Passed: total DMARC-passing messages in the window.
Emails Failed: total DMARC-failing messages in the window.
DMARC Alignment %: the share of evaluated mail that passed DMARC. This is the same top-line figure as on the Aggregate Reports tab, here trended across your chosen range.
SPF Pass Rate %: the share of mail that passed SPF.
DKIM Pass Rate %: the share of mail that passed DKIM.

Having SPF and DKIM broken out separately at account level is genuinely useful. If DMARC Alignment % is low, these two cards tell you which underlying method is dragging it down across all your mail, before you even open a single domain.

Below the cards are three charts:

Pass / Fail Trend: a line chart of passing against failing volume across the range. This is the long-run companion to the per-domain Pass / Fail Volume Over Time bar chart. Use it to confirm that a fix you made is holding, or to catch a slow drift you would miss day to day.
Authentication Split: a pie chart showing the overall proportion of authenticated against unauthenticated mail.
Pass Rates by Method: a bar chart comparing SPF and DKIM pass rates side by side. The same lesson applies as on the per-source alignment chart: do not panic over a low SPF bar if DKIM is strong, because DKIM is what carries mail through forwarding.

Sources

The Sources tab on the Analytics page gives the account-wide or single-domain source picture across your chosen range, complementing the per-domain Source Analysis tab. Use it to spot a new sender appearing across the whole account, or to confirm that a source you authenticated has settled into passing cleanly over a longer window than a single day's report would show.

A reading routine that works

Put the pieces together into a habit rather than a one-off audit:

Open Analytics, set the range to 30d and the domain to All. Glance at DMARC Alignment %, SPF Pass Rate % and DKIM Pass Rate %. If they are stable and high, you are done for the day.
If alignment has dipped, or a domain looks off, switch the domain picker to the affected domain and check the Pass / Fail Trend for when the change began.
Move to the Hosted DMARC Aggregate Reports tab, pick that domain, and sort the source table by Volume. Find the high-volume source whose DMARC badge reads Fail.
Use Alignment Analysis: SPF vs DKIM by Source to see which method that source needs, and the SPF checker or DKIM checker to confirm what it should publish.
For anything you do not recognise, open Source Analysis, identify it, and decide whether to authenticate it, decommission it, or treat it as an impersonator to be rejected once you enforce.
Fix the source, wait a report cycle, and confirm the badge turns green and DMARC Alignment % recovers.

Only when every legitimate source aligns cleanly should you return to the Record Builder and advance your policy from none towards quarantine and reject. The reports tell you exactly when that moment has arrived.

Hosted DMARC: the full tour of the /dmarc page, including publishing and policy.
The enforcement journey: how to move from monitoring to p=reject safely.
Understanding your DMARC record: what each tag in the record means.
Why p=none is false security and none, quarantine, reject: the policy progression in depth.
The Hosted DMARC product page and the requirements page for why mailbox providers increasingly expect enforcement.
Free tools to verify a fix: DMARC checker, DMARC report analyzer, SPF checker, DKIM checker.
The glossary defines rua, alignment, disposition and every other term used above.