Monitoring and Change Alerts

21 June 2026 · 17 min read

Publishing a correct DMARC record is only the start. Email authentication is a living thing: senders come and go, DNS records get edited by colleagues who do not know what _dmarc is for, and a provider you trusted last month can start failing alignment this month. Monitoring is how you catch all of that before it turns into a deliverability incident. This guide covers the two screens that do the watching in the DMARC Engine dashboard: Analytics (/analytics), where you read what is actually happening to your mail, and Alerts (/alerts), where you tell us what should page you and through which channel.

Read this alongside Aggregate report analysis and The enforcement journey. Analytics shows you the trend; the reports screen shows you the detail; alerts make sure you do not have to keep either open to stay safe.

What "monitoring" actually means here

Two separate things are happening behind these screens, and it helps to keep them apart.

Analytics and aggregate reporting are driven by the DMARC reports that mailbox providers send back to you. When you delegate DMARC to us, those rua reports arrive at our ingestion address, get parsed, and are rolled up into the daily counts and per-source breakdowns you see on the Analytics page. This is your record of how real mail authenticated.
Alerts are evaluated continuously against those same signals plus a couple of others (such as your SPF lookup count). When a condition you defined is breached, an alert is raised in the dashboard and, if you have wired up a notification channel, a message is pushed to it. This is your record of when something needs attention.

A useful way to think about it: Analytics answers "how are we doing?", Alerts answer "is anything wrong right now?". You will use Analytics during setup and reviews, and you will lean on Alerts once you are at enforcement and want to stop watching dashboards.

The Analytics page

In the dashboard, open Analytics from the left navigation. The page header reads Analytics with the description "Email authentication analytics and performance metrics". Three controls sit directly under the header and apply to every tab:

A domain picker on the left. It defaults to All domains, which aggregates the daily counts across your whole account. Open it to pick a single domain instead. This choice matters: the org-wide view can draw the volume and pass-rate charts, but the per-source and per-method breakdowns need a single domain selected, because those numbers are computed from one domain's sending sources.
A range selector on the right with three buttons: 7d, 30d and 90d. The selected range is highlighted. It sets the window for every figure on the page, so a stat card labelled "Total Emails (30d)" is counting exactly the last thirty days. The page opens on 30d.
A Refresh button next to the range buttons. It re-fetches the current tab's data and spins while loading. Use it after you have just made a change and want to pull the latest processed reports rather than wait.

Beneath those controls is the tab bar with four tabs: Overview, Email Volume, Authentication and Sources. The page opens on Overview.

If a domain has only just been delegated, expect the charts to be empty for a while. Analytics is fed by aggregate reports, and most providers batch and send those once a day. You will typically see the first data points appear within twenty-four to forty-eight hours of real mail flowing.

Overview tab

Overview is the at-a-glance summary. At the top sit four stat cards, each with a small sparkline showing the trend across the selected range:

Total Emails: the total number of messages evaluated for SPF, DKIM and DMARC in the window. The label carries the active range, for example Total Emails (7d).
Auth Pass Rate: the percentage of evaluated messages that passed, calculated as passed divided by total evaluated. This is the single number to watch trend upward as you clean up your senders.
Active Domains: how many domains you are managing. This one is not range-dependent; it counts the domains in your account.
Failed Auth: the count of messages that did not pass DMARC in the window, shown in red. Again the label carries the range, for example Failed Auth (30d).

Below the cards are two charts side by side:

Email Volume, a line chart with two series, Passed (green) and Failed (red), plotted day by day across the range. This is where a sudden cliff or spike jumps out at you.
Authentication Results, a pie chart splitting passed against failed, with the pass-rate percentage printed in the centre.

At the bottom is a Top Sending Sources bar chart. This one is per domain: if you are on All domains it shows a "Select a domain" prompt, because we cannot meaningfully attribute sources without picking one. Choose a single domain in the picker and the chart fills with that domain's busiest senders, each bar coloured green where the source is passing DMARC and red where it is not. Bars in red are exactly the senders you need to fix or disown before you tighten your policy.

If there is nothing to show for the chosen window, the tab displays an empty state titled No analytics data yet with the note that data appears after your domains receive traffic and reports are processed.

Email Volume tab

The Email Volume tab is the deeper view of how much mail you are sending and how it is being treated. It opens with an Email Volume Trend line chart carrying three series rather than two: Passed (green), Failed (red) and Quarantined (amber). The quarantined line is worth watching once you move to p=quarantine, because it tells you how much mail receivers are actually holding back under your policy.

Under the chart is a Daily Breakdown table, one row per day, with sortable columns for Date, Passed, Failed, Quarantined and Rejected. The rejected column only carries numbers once you are at p=reject. This table is the raw material behind the charts; sort by Failed to find your worst days, then cross-reference the Sources tab to see who was responsible.

Authentication tab

The Authentication tab breaks the headline pass rate into its three components. Because these rates are derived from a single domain's source data, the tab shows a Select a domain prompt while the picker is on All domains. Choose one domain and you get three circular gauges:

SPF Pass Rate: the share of this domain's volume that passed SPF.
DKIM Pass Rate: the share that passed DKIM.
DMARC Alignment: the share that passed DMARC overall, meaning at least one mechanism passed and was aligned.

Reading the three together is diagnostic. A high DKIM rate but a low SPF rate usually points to a sender that signs correctly but sends from IPs not in your SPF record; the reverse points to forwarding or a missing DKIM key. If you need to confirm a specific record by hand, the free SPF checker, DKIM checker and DMARC checker resolve and parse live DNS for any domain, and Authenticate your senders walks through fixing each mechanism.

Sources tab

The Sources tab is the per-sender ledger and, like the others that need attribution, requires a single domain. It opens with a search box ("Search by IP or organisation...") and a table of every source that sent on the domain's behalf in the window. Each row shows:

Source IP, in monospace, the sending address as reported.
Volume, the message count from that source, sortable so you can rank by traffic.
SPF, DKIM and DMARC, each a green Pass or red Fail badge for that source.

Type into the search box to filter by IP fragment or organisation name. This is the screen you live in while working towards enforcement: it is the definitive list of who is sending as you. Every red row is either a legitimate service you have not authorised yet (fix it) or something you do not recognise (investigate it). When you want the underlying report XML rather than the rolled-up view, the DMARC report analyzer parses a raw aggregate file, and Reading your first DMARC report explains the fields.

The Alerts page

Analytics is something you choose to look at. Alerts are what reach out to you. In the dashboard, open Alerts from the navigation. The header reads Alerts with the description "Monitor and manage alert rules and notification channels". Below it is a tab bar with four tabs: Active Alerts, Alert Rules, History and Channels. The Active Alerts tab carries a count badge showing how many alerts are currently active. The page opens on Active Alerts.

Setting up alerting properly is a three-step sequence, and the tabs are deliberately in that order: first create a Channel so there is somewhere to send notifications, then create an Alert Rule that points at that channel, then watch Active Alerts and review History. We will take them in the order you should use them.

Channels: where notifications go

Open the Channels tab. Existing channels appear as cards; if you have none yet, you will see a dashed Add Channel tile. Each channel card shows:

The channel name and its type (for example "Email" or "Slack"), with a coloured icon per type.
A status indicator reading Active or Disabled, with a toggle beside it. Flip the toggle to mute a channel without deleting it, which is handy during a noisy migration or a planned maintenance window.
A line showing when the channel was last tested, or "Not yet tested" if it never has been.
A Test button and a Remove button.

To add one, click the Add Channel tile. The Add Notification Channel modal opens with three fields:

Type: a dropdown offering Email, Slack, Webhook and PagerDuty.
Name: a label for your own reference, for example "Ops Email" or "Security Slack". This is what appears on the rule when you attach the channel, so name it for the team or purpose, not the address.
Destination: the actual target, and the placeholder changes to match the type you picked. For Email it is an address such as alerts@example.com; for Slack it is an incoming webhook URL of the form https://hooks.slack.com/services/...; for Webhook it is your own https:// endpoint; for PagerDuty it is the integration key.

Fill in all three and click Add Channel. The modal will not let you submit until both Name and Destination have content.

Webhook and Slack destinations must be public https URLs. The dispatcher resolves the host and refuses to post to private or internal addresses, so an endpoint behind a VPN or on a reserved IP range will be rejected rather than called. Expose a public HTTPS receiver if you want to integrate a custom system.

Once a channel exists, click its Test button. The button reads Testing... while it sends, and a real test message is delivered through the channel. Do this before you rely on it: an email channel with a typo or a Slack webhook that has been revoked will fail silently when a genuine alert fires, and the test is the only way to be sure the path works end to end. After a successful test the card updates its "Last tested" line.

Alert Rules: what counts as a problem

Open the Alert Rules tab. It opens with a Create Rule button on the right. Existing rules render in a table with these columns:

Rule Name, sortable, your label for the rule.
Condition, a human-readable description of what the rule watches.
Threshold, the limit that triggers it, shown for example as > 10% failures or >= 10 lookups.
Domains, listing the domains the rule is scoped to, or All domains when it is not narrowed.
Channels, the notification channels the rule fires through, shown as badges.
Enabled, a toggle to switch the rule on or off in place.
Actions, with Edit and Remove buttons. Remove asks you to confirm before deleting, because it cannot be undone.

Click Create Rule to open the Create Alert Rule modal. Its fields:

Rule Name: a free-text label, for example "DMARC Compliance Drop".
Condition: a dropdown of the five conditions the evaluator actually fires on. They are DMARC failure rate above threshold (dmarc_rate), Volume spike in failing or spoofed mail (volume_spike), New sending source for the domain (new_source), Published DMARC policy changed (policy_change) and SPF lookups at or above limit (spf_limit).
A threshold field whose label and hint change with the condition. For the DMARC failure-rate condition it reads Failure-rate threshold (%) and alerts when the DMARC failure rate rises above the percentage you enter. The volume-spike condition watches for a sharp rise in failing or spoofed mail volume, the new-source condition fires when a sending IP not seen before for the domain appears, and the policy-change condition fires when the published DMARC policy for the domain changes. For the SPF condition it reads Lookup threshold and alerts when SPF DNS lookups reach the count you enter; the RFC 7208 hard limit is 10, so a threshold of 10 warns you the moment you hit the ceiling that causes a permerror. See How SPF flattening works for why that limit bites and how flattening keeps you under it.
Domains: a checklist of your domains. Leave every box unchecked to apply the rule to all domains, or tick specific ones to scope it. The modal tells you which mode you are in as you select.
Notification Channel: a dropdown of your existing channels, each shown as "Name (type)". If you have not created a channel yet, the modal tells you to add one in the Channels tab first, and you cannot save the rule without one.

Fill the form and click Create Rule. The button is disabled until the rule has a name, a channel and a valid numeric threshold, so an empty or non-numeric threshold will block the save. To change an existing rule later, click Edit on its row; the same modal reopens pre-filled with the current values and the button reads Save Changes.

Two pieces of behaviour are worth knowing because they shape how you should set thresholds:

One alert per type, per domain, per hour. The evaluator applies a one-hour cooldown for each combination of organisation, domain and condition type. If a domain is failing continuously, you get one alert raised that hour, not one per report. This keeps a bad day from flooding your inbox, but it also means an alert clearing and re-breaching within the hour will not page you twice.
A threshold of 0 means "any". For the DMARC failure-rate condition, entering 0 is respected literally: it alerts on any failure at all. Most teams start higher (for example 10) while at p=none to cut noise, then tighten the threshold down as they approach p=reject.

A sensible starter set is one DMARC failure-rate rule per important domain at a threshold that suits your current policy stage, plus one SPF lookup rule at 10 to catch the day your SPF record grows past the limit. Setting up alerts covers recommended rules per enforcement stage in more depth.

Active Alerts: the live queue

Open the Active Alerts tab to see what is currently firing. Each alert is a card showing:

A severity icon and tint: critical alerts are red, warnings amber and informational ones blue.
The alert title and a short description of what triggered it.
A timestamp of when it was raised, a domain badge naming the affected domain, and a status badge reading active or acknowledged.

Each card carries up to two buttons:

Acknowledge: marks the alert as acknowledged. Use this to signal "seen, working on it" so a teammate does not duplicate your effort. The status badge changes and the Acknowledge button disappears, leaving only Dismiss.
Dismiss: resolves the alert and removes it from the active queue. Use it once the underlying issue is fixed.

When nothing is firing, the tab shows an All clear empty state titled No active alerts, which is exactly where you want to live.

History: the audit trail

The History tab is the full record of every alert ever raised, resolved ones included. It opens with a search box and a paginated table with columns for Time, Alert, Severity, Domain and Status, where status is a coloured badge (green for resolved, amber for acknowledged, red for active). Search filters across the title, description, severity, status and domain at once. Use this tab for the after-the-fact questions: when did this domain last breach, how often does this provider trip us up, did the acknowledged alert from last week ever actually get resolved.

Change alerts: catching DNS drift and new senders

The most valuable thing monitoring does is catch changes you did not make on purpose. Two kinds are worth calling out specifically.

DNS drift. Because your DMARC, SPF, DKIM, MTA-STS and BIMI records are delegated to us by CNAME, the authoritative content lives on our side and cannot be silently edited away in your DNS without breaking the delegation outright, which is itself visible. A background verification job re-resolves public DNS for your domains on a schedule, independently of whether anyone has the dashboard open, and advances a domain's state when its records resolve correctly. It is deliberately one-directional: it only upgrades a domain (from unverified to verified, or a pending service to active), so a brief DNS blip can never quietly downgrade a working domain. The practical effect is that a delegation that was working and then breaks shows up against the live state on the relevant product page, and the DNS record reference lists the exact CNAME targets each record should point to if you need to confirm one by hand.

New sources. Every sending IP that appears in your aggregate reports shows up on the Sources tab of Analytics, coloured by whether it passes. A source you have never seen, sending volume as your domain and failing alignment, is the signal that either a new legitimate service has come online without being authorised or someone is spoofing you. The DMARC checker and the wider Hosted DMARC workflow exist precisely so you can react to that, and The enforcement journey explains how to fold a newly discovered sender into your policy safely rather than blocking it by accident.

For both, the alerting in the previous sections is what turns "visible if you look" into "told without looking". A DMARC failure-rate rule will fire when a new failing source pushes your failure rate over the line, and an SPF lookup rule will fire when adding that source's include tips your SPF record past ten lookups. That is the loop monitoring is built around: Analytics shows you the change, the rule decides whether it matters, and the channel makes sure the right person hears about it.

A recommended monitoring routine

Putting it together, a workable rhythm looks like this:

At setup, add a notification channel and test it. Create a DMARC failure-rate rule and an SPF lookup rule for each important domain. Confirm both rules show Enabled in the table.
Daily, while moving to enforcement, open Analytics on the affected domain, scan the Overview pass-rate trend, then drop into Sources to clear any new red rows.
Weekly, once enforced, glance at the Authentication gauges per domain and skim History for anything acknowledged but never resolved.
Whenever an alert fires, acknowledge it so the team knows it is owned, fix the underlying sender or record, confirm the fix on the relevant product page and in the free checker tools, then dismiss the alert.

Follow that and the dashboard does the watching for you. For the surrounding setup, see Getting started, Delegating your DNS and Setting up alerts; for the records themselves, the requirements overview and the glossary define every term used above.

Monitoring and change alerts