Analytics explained

22 June 2026 · 14 min read

The Analytics page is where the raw aggregate reports flowing into your account become something you can actually read at a glance: a small set of headline numbers and three charts that tell you, for any window of time, how much of your mail is authenticating and which method is carrying the load. Where the per-domain tabs on the Hosted DMARC page answer "which source is failing and why", Analytics answers the broader questions: "are we getting better or worse", "is SPF or DKIM letting us down", and "what share of our traffic passes DMARC right now". This guide walks the whole page from the top, naming every control, stat card and chart, and explaining exactly what each number means and how to act on it.

The Analytics page lives at https://app.dmarcengine.com/analytics. In the dashboard, open Analytics from the left-hand sidebar. If you have only just published your DMARC record, you may see an empty state at first; that is expected, and the section on empty data below explains why.

What you are looking at, and where it comes from

Everything on the Analytics page is built from your aggregate (rua) reports. These are the XML summaries that mailbox providers such as Google, Microsoft and Yahoo send back once per reporting period, usually once a day, for every source that sent mail claiming to be from your domains. DMARC Engine parses those reports, matches each one to the right domain, and rolls the results up into the counts and percentages you see here. If you want the full picture of what an aggregate report contains and how the ingestion address is set up, read Aggregate report analysis first; this page assumes reports are already arriving.

Two consequences follow from that data source, and they are worth holding in mind as you read every chart below.

The data is summarised, not live. Receivers batch their reports and send them on their own schedule, so Analytics reflects mail from roughly the last day or two onwards, not the message you sent five minutes ago. A brand-new sending source will not appear until a receiver has observed it and reported back.
The data is counted from reports, not from your outbound mail server. If a receiver does not send aggregate reports, its traffic is invisible here. The vast majority of consumer mail volume is covered by providers that do report, so the picture is representative, but it is not a literal copy of your mail logs.

The two tabs

Across the top of the page, under the Analytics heading, are two tabs:

Overview: the headline numbers and the three charts. This is the tab the page opens on and the one this guide focuses on, because it is where you will spend almost all of your time.
Sources: a breakdown by sending source, so you can see which individual senders and IPs make up the totals on the Overview tab.

Click a tab to switch between them. The two controls described next, the range selector and the domain picker, sit above the tabs and apply to whichever tab you are viewing, so the window and domain you choose carry across as you move between Overview and Sources.

Choosing a range

At the top of the page is the range selector, a set of three buttons:

7d: the last seven days.
30d: the last thirty days.
90d: the last ninety days.

The selected range governs every number and every chart on the page at once. Change it and the stat cards recalculate, the trend line redraws over the new window, and the pie and bar charts re-tally against the same period. There is no separate "apply" step; the page updates as soon as you click.

Each range answers a different question, so pick deliberately rather than leaving it on the default:

Use 7d when you have just made a change, for example you have added a new sending source to your SPF record or rotated a DKIM key, and you want to see the effect quickly without the previous fortnight's history diluting it. Seven days is also the right window for spotting a sudden problem, such as a new tool that has started sending unaligned mail this week.
Use 30d as your everyday view. A month smooths out the day-to-day wobble of report timing and weekend volume dips, so the trend line tells you about real movement rather than noise. This is the range to glance at when you simply want to know whether things are healthy.
Use 90d when you are deciding whether it is safe to tighten your DMARC policy, or when you are reporting progress to someone else. Three months is long enough to prove that a high pass rate is stable rather than a lucky week, which is exactly the evidence you want before moving from p=none to p=quarantine or on to p=reject. For the full path through those policy stages, see The enforcement journey.

A longer range is not simply "better". The wider the window, the more old data is folded in, so a fix you made three weeks ago will still be dragging your averages down on the 90d view long after the 7d view shows you are clean. When you have just fixed something and want to confirm it worked, the short range is the honest one.

Choosing a domain

Next to the range selector is the domain picker. It has two modes:

All: combine every verified domain on your account into one set of numbers. The stat cards, trend, split and method charts all reflect your whole estate at once. This is the right choice for an account-wide health check and for the kind of headline figure you would put in a status report.
A single domain: pick one domain from the dropdown and every number on the page is recalculated for that domain alone.

The distinction matters more than it first appears. An account-wide All view can hide a single misbehaving domain inside a large, healthy total: if one low-volume domain is failing badly but your main domain sends millions of clean messages, the combined alignment percentage can still look reassuring. So treat All as the starting point and the single-domain view as the place you confirm. The standard workflow is to scan All first, and the moment any headline number looks lower than you expect, switch the domain picker to each domain in turn to find which one is responsible. Once you have a suspect domain, move to its per-domain Hosted DMARC tabs to identify the exact source.

The Overview tab: the five stat cards

At the top of the Overview tab is a row of stat cards. Each shows a single number for the chosen range and domain. Read them left to right as a quick verdict before you study the charts.

Emails Passed

The total count of messages, across the selected range and domain, that passed DMARC. A message passes DMARC when it is authenticated and aligned: either SPF passed and the SPF domain aligns with the visible From domain, or DKIM passed and the signing domain aligns, or both. This is your "good mail" number, the volume that receivers can trust came from you.

On its own the count is just context; you cannot tell from a raw number alone whether it is good. A million passing messages sounds healthy until you learn that another two hundred thousand failed. Read Emails Passed alongside Emails Failed and, more usefully, alongside the DMARC Alignment % card, which expresses the same idea as a proportion.

Emails Failed

The total count of messages, over the same range and domain, that failed DMARC: neither an aligned SPF pass nor an aligned DKIM pass was present. This is the number to care about, but with an important caveat about what it actually contains.

A failing message is not automatically a blocked message. Whether a DMARC failure leads to the message being delivered, quarantined or rejected depends on the policy in your published DMARC record. While you are at p=none, failures are reported but still delivered, so a high Emails Failed figure at this stage is a diagnosis, not damage: it is telling you what would be blocked if you enforced today. Failures fall into two very different groups, and the rest of the page exists to help you tell them apart:

Legitimate mail from a source you have not yet authenticated. This is what you want to find and fix, by adding the source to your SPF record or setting up DKIM signing for it, before you enforce.
Unauthenticated mail from sources that are not you, including spoofing and forwarding artefacts. This is precisely the traffic a p=reject policy is meant to stop.

A non-zero Emails Failed is therefore normal and even expected before enforcement. The goal is not to drive it to zero by luck, but to understand every contributing source so that what remains is only mail you are content to have blocked.

DMARC Alignment %

The percentage of your total reported mail that passed DMARC: in effect Emails Passed divided by the sum of passed and failed, expressed as a percentage. This is the single most important number on the page, because it normalises for volume. A busy week and a quiet week become directly comparable, and you can set a concrete target.

As a rule of thumb, you want this figure sitting consistently in the high nineties before you tighten your policy. A stable reading at or above roughly 98 per cent over a 90d window, with every remaining failure understood and accounted for, is the practical signal that it is safe to move towards p=quarantine and then p=reject. A figure that bounces around, or that sits lower than you can explain, means there is still a legitimate source you have not aligned; find it before you enforce.

SPF Pass Rate %

The percentage of reported mail that passed SPF with alignment. SPF authorises the sending IP: a message passes SPF when the IP that sent it appears in the SPF record of the domain in the message envelope, and that domain aligns with the visible From domain. A low or sliding SPF pass rate usually points to one of a few familiar causes:

A sending source whose IP ranges are not listed in your SPF record, often a newly added marketing or transactional provider.
An SPF record that has quietly exceeded the ten-lookup limit, which causes a permerror and SPF failures, and which is exactly what SPF flattening is designed to prevent.
Forwarding, which changes the sending IP in transit and breaks SPF by design. This is normal and is the main reason you should never rely on SPF alone.

To investigate a specific record, the free SPF checker shows you the lookup count and resolved mechanisms for any domain.

DKIM Pass Rate %

The percentage of reported mail that passed DKIM with alignment. DKIM is a cryptographic signature: the sending system signs the message with a private key, and the receiver verifies it against the public key published in your DNS. A message passes DKIM here when that signature validates and the signing domain aligns with the From domain. DKIM survives forwarding where SPF does not, so it is usually the more robust of the two methods and the one you most want to see high. A low DKIM pass rate typically means a sending source is not signing at all, or is signing with a selector or domain that does not align with your From address. You can confirm that a given selector is published and valid with the free DKIM checker.

How the three percentages relate

The two method percentages are not meant to add up to the alignment figure. DMARC passes if either SPF or DKIM passes with alignment, so it is entirely normal, and in fact healthy, for DMARC Alignment % to be higher than either SPF Pass Rate % or DKIM Pass Rate % on its own. A source that fails SPF because of forwarding but still carries a valid aligned DKIM signature passes DMARC. That redundancy is the whole point of authenticating with both methods: each covers a case the other misses. If your alignment is high while both method rates are middling, that is the system working as designed, not a contradiction.

Pass/Fail Trend

Below the stat cards is the Pass/Fail Trend, a line chart plotting your passing and failing mail over the selected range, one point per day. It turns the static stat cards into a story over time, and it is the chart that tells you whether a change you made actually worked.

Read it for shape, not just height:

A passing line climbing while the failing line drops is the picture you want after authenticating a new source. The gap widening in your favour is direct evidence the fix landed.
A sudden spike in the failing line on a particular day points to a discrete event: a new tool switched on, a misconfigured campaign, or a burst of spoofing. Note the date, then switch to the Sources tab or the per-domain Source Analysis view to find what started sending then.
A failing line that creeps upwards gradually is the classic sign of authentication drift, often an SPF record sliding past the lookup limit or a sending provider that has changed its IPs. This slow kind of regression is easy to miss on the stat cards alone, which is exactly why the trend is worth a regular glance. Configuring an alert rule, covered in Setting up alerts, means you do not have to catch it by eye.

Because report timing is uneven, do not over-read a single day, especially the most recent one, which may still be filling in as receivers send their batches. The trend's value is in the slope across several days, not in any one point.

Authentication Split

Next is the Authentication Split, a pie chart showing the proportion of your reported mail that passed versus failed DMARC over the range. It is the DMARC Alignment % card rendered as a shape: a single glance tells you whether passing mail dominates, as it should, or whether the failing slice is larger than you are comfortable with.

Use it as a sanity check rather than a precise measurement. A pie that is almost entirely the passing colour, with only a thin failing sliver, is the healthy end state and a reasonable visual cue that you are ready to consider enforcement. A meaningful failing slice is your prompt to go and find out what is in it: not every failure is bad, but every failure should be explained before you tighten policy. When the failing slice surprises you, the next move is the same as always: narrow the domain picker to find the responsible domain, then drill into its sources.

Pass Rates by Method

The final chart is Pass Rates by Method, a bar chart comparing your SPF and DKIM pass rates side by side for the selected range. It presents the same two numbers as the corresponding stat cards, but putting them next to each other as bars makes the comparison immediate and tells you where to focus your effort.

If the DKIM bar is markedly taller than SPF, your DKIM signing is in good shape and your SPF coverage is the weaker link. That is a common and not especially worrying pattern, because forwarding breaks SPF while leaving DKIM intact. Still, low SPF coverage is worth closing: review your SPF record and add any missing legitimate sources.
If the SPF bar is taller than DKIM, some of your sending sources are not signing with DKIM, or are signing with a non-aligned selector. Because DKIM is the more durable method, this is usually the more valuable gap to close. Work through each unsigned source and set up signing.
If both bars are low, you have sources that authenticate with neither method, which is the highest priority of all. These are the messages most likely to be blocked the moment you enforce, so identify and fix them first.

The aim over time is to lift both bars and keep them high, so that the loss of either method, through a forwarding hop or a temporary DNS issue, still leaves the other carrying the message to a DMARC pass.

When there is no data

If the chosen range and domain contain no reported mail, the page shows "No analytics data for this period" in place of the charts. This is informational, not an error, and it has a small number of ordinary causes:

Your record was published recently. Receivers send aggregate reports on their own schedule, typically once a day, so it is normal to see nothing for a day or two after you publish a DMARC record with the hosted rua address in place. Check back tomorrow.
The range is too narrow. If you are looking at 7d for a domain that has only just started reporting, widen the selector to 30d or 90d to pull in whatever data exists.
You have selected a single low-volume domain that simply did not send mail in the window. Switch the domain picker to All, or to a busier domain, to confirm that data is flowing elsewhere on the account.
The record or delegation is not yet correct, so no reports are being matched to the domain. Confirm your DMARC record is published and pointing at the hosted ingestion address: the free DMARC checker shows you the live record, and Hosted DMARC walks through publishing it.

If you have published correctly and still see nothing after several days, that itself is useful information: it can mean the domain is sending little or no mail that reaches reporting receivers, which is worth confirming before you rely on the silence.

Putting it together: a working routine

The Analytics page rewards a short, regular habit more than an occasional deep dive. A practical routine is:

Open Analytics, set the domain picker to All and the range to 30d, and read the five stat cards as a verdict. DMARC Alignment % is your headline; the rest is context.
Glance at the Pass/Fail Trend for shape. If the failing line is climbing, something has changed and you want to know what.
If anything looks off, switch the domain picker through each domain in turn to find the one responsible, and drop the range to 7d if you are checking whether a recent fix has taken effect.
Use Pass Rates by Method to decide whether SPF or DKIM is the weaker link for that domain, then go to the per-domain Source Analysis view, or the Sources tab here, to identify the exact sending source to fix.
When DMARC Alignment % sits stably high on a 90d view and every remaining failure is accounted for, you have the evidence you need to tighten policy. Continue with The enforcement journey.

For the terms used throughout this page, the glossary defines alignment, disposition, rua, selector and the rest. To learn what each underlying record does, see Hosted SPF, Hosted DKIM and Hosted DMARC.