Setting up alerts in DMARC Engine

25 May 2026 · The DMARC Engine Team · 16 min read

Why alerts matter

Email authentication is not a one-off task. Once your DMARC policy is enforced and your senders are aligned, the work shifts to keeping it that way. A new marketing tool starts sending from an unaligned source; an SPF record creeps towards the ten-lookup limit; a forwarding setup quietly pushes your failure rate up. None of these break anything visibly, so by the time someone notices, legitimate mail has been failing for days.

Alerts are how DMARC Engine watches for those drifts on your behalf and tells you the moment they happen, instead of waiting for you to open the dashboard and spot a problem. You define the conditions you care about as rules, point each rule at one or more notification channels (an email inbox, a Slack room), and the platform evaluates your incoming aggregate (RUA) data against those rules on a schedule. When a rule trips, an alert is raised and your channels are notified.

This guide walks through the whole Alerts page, top to bottom, in the order you will actually use it: triaging what is firing now, building the rules that fire, and wiring up the channels those rules notify. If you are setting alerts up for the first time, the natural order is reversed: create a channel first, then a rule, then watch the Active Alerts tab. We cover both directions below.

The Alerts page lives at https://app.dmarcengine.com/alerts. In the dashboard, open Alerts from the left-hand sidebar (the bell icon). The sidebar entry carries a small count badge showing how many alerts are currently active, so you can see at a glance whether anything needs attention without opening the page.

The four tabs

The Alerts page is split into four tabs across the top, under the Alerts page heading and its line of helper text, "Monitor and manage alert rules and notification channels":

Active Alerts: everything that has fired and not yet been cleared. This is your triage queue, and it is the tab the page opens on. The tab label carries a count of how many alerts are currently in the active state.
Alert Rules: the rules you have defined, shown as a table. This is where you create, edit, enable, disable and remove the conditions that raise alerts.
History: the full log of every alert ever raised, including ones you have already dealt with, with search.
Channels: your notification channels (email, Slack, and more), where alerts are delivered.

Click a tab to switch between them. The sections below take each in turn.

Active Alerts

The Active Alerts tab lists every alert that is currently in the active or acknowledged state, newest concerns at the top. Each alert is a coloured card whose tint reflects its severity: red for critical, amber for warning, blue for info. The colour and the icon on the left let you scan a long list and find the serious items first without reading every word.

Each card shows:

The alert title, in bold, for example a compliance drop or an SPF lookup warning, with a short description underneath explaining what was detected.
The time the alert was raised, shown in your local time.
A domain badge naming the affected domain, where the alert is tied to a specific domain rather than your whole account.
A status badge showing whether the alert is active (red) or acknowledged (amber).

Acknowledging and dismissing

On the right of each card are the actions you take to clear it. Which buttons appear depends on the alert's current state.

Acknowledge: shown while an alert is still active. Clicking it marks the alert as acknowledged, which is the "I have seen this and I am dealing with it" state. The card stays in the list (now with an amber status badge) so you do not lose track of work in progress, but it is visibly distinct from brand-new active alerts. Use this when you have triaged an alert but the underlying issue is not yet fixed.
Dismiss: available on both active and acknowledged alerts. Clicking it marks the alert as resolved and removes it from the Active Alerts list. Use this once the underlying problem is genuinely fixed, or if the alert was noise you do not need to act on.

Both actions take effect immediately and the list refreshes. Acknowledging does not stop the rule from firing again later: if the same condition trips on the next evaluation, a fresh alert is raised. Acknowledging and dismissing affect the individual alert, not the rule behind it. If an alert keeps coming back and you no longer want it, adjust or disable the rule on the Alert Rules tab rather than repeatedly dismissing the alert.

Dismissed alerts are not deleted. They move to the History tab with a resolved status, so there is always a record of what fired and when. Nothing on this page is ever truly lost.

When the list is empty

If nothing is firing, you will see an "All clear" empty state with the prompt to configure alert rules so the platform can monitor your domains. An empty Active Alerts tab is the goal, not a sign something is broken: it means none of your rules have tripped. If you have not built any rules yet, this is your cue to move to the Alert Rules tab. If a fetch fails, a "Failed to load" banner with a Retry button appears instead; click Retry to try again.

History

The History tab is the permanent record. Where Active Alerts shows only what is live, History shows every alert ever raised on your account, regardless of status, in a sortable table. At the top is a search box, "Search alerts...", that filters the table as you type. It matches across the alert title, description, severity, status and domain, so you can quickly pull up, for example, every critical alert, or everything that has ever fired for one domain.

Each row shows:

Time: when the alert was raised, sortable so you can order oldest or newest first.
Alert: the title of the alert.
Severity: a badge, critical (red), warning (amber) or info (blue).
Domain: the affected domain as a badge, or a dash where the alert applies account-wide.
Status: a badge showing active (red), acknowledged (amber) or resolved (green).

The table is paginated, so older entries sit on later pages. Use History to audit what has happened over time, to confirm an alert you fixed has not recurred, or to gather evidence for a compliance or incident review. It is read-only: to act on an alert, use the Active Alerts tab.

Alert Rules

The Alert Rules tab is where the real configuration happens. A rule is a standing instruction: "watch this condition, against this threshold, on these domains, and when it trips, notify this channel." Rules are listed in a table, with a Create Rule button in the top right.

Each rule occupies one row, with these columns:

Rule Name: the name you gave the rule. This is sortable, and it is what appears in the resulting alerts and notifications, so make it descriptive.
Condition: the kind of thing being watched, in plain language, for example "DMARC failure rate above threshold" or "SPF lookups at or above limit".
Threshold: the trigger point, rendered for quick reading, for example > 10% failures or ≥ 10 lookups.
Domains: which domains the rule covers. If you scoped it to specific domains, they are listed here; if you left it unscoped, this reads All domains.
Channels: the notification channels the rule fires to, shown as badges.
Enabled: a toggle. Flip it off to pause a rule without deleting it, and on to resume. A disabled rule keeps all its settings but never fires. This is useful during a planned change (a migration, a new sender being onboarded) when you expect failures and do not want to be paged for them.
Actions: an Edit button and a Remove button on the right.

Edit reopens the rule in the same modal used to create it, pre-filled with the current settings, so you can adjust a threshold or change the channel. Remove deletes the rule permanently; you are asked to confirm first, because this cannot be undone. Removing a rule does not touch any alerts it has already raised; those remain in History.

If you have no rules yet, the tab shows a "No alert rules yet" empty state with its own Create Rule button to get you started.

Creating an alert rule

Before you create a rule, make sure you have at least one notification channel, because a rule must point at one. If you have not added a channel, do that first (see Channels below); the rule modal will tell you if none exist.

Click Create Rule to open the Create Alert Rule modal. It has the following fields:

Rule Name: a free-text name, for example "DMARC Compliance Drop" or "SPF lookup warning". Choose something you will recognise in a notification at 2am.
Condition: a dropdown choosing what to watch. Five conditions are available, and each maps to a real signal the platform evaluates:
- DMARC failure rate above threshold: fires when the share of your mail that fails DMARC (fails both SPF and DKIM alignment) rises above a percentage you set. This is the headline "something is wrong with my authentication" alert.
- Volume spike: fires when there is a sudden spike in the volume of failing or spoofed mail for the domain, catching a burst of abuse or a misconfiguration that a steady-state rate threshold might miss.
- New sending source: fires when a sending IP not seen before starts sending mail for the domain, so you can spot a new legitimate sender to align, or an unauthorised one to investigate.
- DMARC policy change: fires when the published DMARC policy for the domain changes, so an accidental or unauthorised edit to your record does not go unnoticed.
- SPF lookups at or above limit: fires when the number of DNS lookups your SPF record performs reaches a count you set. SPF has a hard limit of ten lookups (RFC 7208); exceed it and SPF returns a permanent error and stops working. This rule warns you before you hit the wall.
Threshold: a number, whose label changes to match the chosen condition.
- For DMARC failure rate, the field is Failure-rate threshold (%) with a hint that the alert fires when the DMARC failure rate rises above this percentage. A value of 10 means "tell me when more than 10% of my mail is failing." Pick a number above your normal baseline so you are alerted to real regressions, not everyday noise.
- For SPF lookups, the field is Lookup threshold with a hint that the alert fires when SPF DNS lookups reach this count, and a reminder that the RFC hard limit is ten. Setting this to 9 or 10 gives you a warning with room to act before SPF breaks. If your SPF is creeping up, see how SPF flattening works, which is the permanent fix.
- The volume spike, new sending source and DMARC policy change conditions do not need a threshold you set: they fire on the event itself, so the threshold field does not apply to them.
Domains: a checklist of your domains. Tick one or more to scope the rule to just those domains; leave all boxes unticked to apply the rule to every domain on the account. The helper text confirms which way it is set: "Applies to all domains" when nothing is selected, or "Applies to the selected domains only" once you tick something. If you have no domains yet, the rule simply applies to all of them.
Notification Channel: a dropdown listing your existing channels by name and type, for example "Ops Email (email)". This is where alerts from this rule are delivered. If you have not created any channels, this field is replaced by a note telling you to add one in the Channels tab first.

Click Create Rule to save. The button stays disabled until you have given the rule a name, entered a valid numeric threshold, and have at least one channel to point at; this prevents half-configured rules that would never fire or never notify. A confirmation appears and the new rule shows up in the table, enabled by default.

To change a rule later, click Edit on its row, adjust the fields, and click Save Changes.

Choosing sensible thresholds

A rule that fires constantly is as useless as no rule at all, because you learn to ignore it. A few guidelines:

For DMARC failure rate, look at your current pass/fail trend on the dashboard first and set the threshold a comfortable margin above your normal failure rate. If you typically sit at 2 to 3% failures from forwarding, a threshold of 10% catches a real regression without crying wolf. Tighten it as your alignment improves.
For SPF lookups, set the threshold at 9 so you get a warning one lookup before the limit, with time to flatten or consolidate includes before SPF returns a permanent error.
Scope rules to specific domains when their senders differ. A single account-wide rule is fine to start, but a high-volume marketing domain and a quiet internal one rarely warrant the same threshold.

For background on what these numbers mean, see understanding your DMARC record and the enforcement journey. You can also sanity-check any domain's live posture at any time with the free DMARC checker and SPF checker.

Channels

A notification channel is a destination: where alerts are actually delivered. Rules raise alerts; channels carry them to you. The Channels tab shows your channels as a grid of cards, with an Add Channel tile at the end.

Each channel card shows:

An icon and type label: an email icon for email, a different icon and colour for Slack, Webhook and PagerDuty, so you can tell channel types apart at a glance.
The channel name you gave it.
A status label, Active or Disabled, next to a toggle. Flip the toggle to pause or resume delivery to that channel without deleting it. A disabled channel receives nothing, even from rules that point at it, so disabling a channel quietly silences every rule that uses it. Prefer disabling individual rules if you want finer control.
A line showing when the channel was last tested, or "Not yet tested" if you never have.
A Test button and a Remove button.

Adding a channel

Click the Add Channel tile (the dashed box with a plus) to open the Add Notification Channel modal. It has three fields:

Type: a dropdown choosing the kind of channel. The options are Email, Slack, Webhook and PagerDuty. The two you will use most are Email and Slack.
Name: a free-text label, for example "Ops Email" or "Security Slack". This is the name that appears on the card and in the rule modal's channel dropdown, so make it clear who or where it reaches.
Destination: where the alert is actually sent. The placeholder changes to match the type you chose, to show you the expected format:
- For Email, enter the recipient address, for example alerts@example.com. A shared team or distribution address is usually better than one person's inbox, so alerts are not missed when someone is away.
- For Slack, paste an incoming webhook URL, which looks like https://hooks.slack.com/services/.... You create this in Slack: add an Incoming Webhooks integration to the channel you want alerts posted to, and copy the webhook URL Slack gives you into this field. Every alert fired to this channel will then post into that Slack channel.
- For Webhook, enter the HTTPS endpoint that should receive the alert, for example https://example.com/webhook, if you want to route alerts into your own tooling.
- For PagerDuty, enter your PagerDuty integration key, to raise incidents in an on-call rotation.

Click Add Channel to save. The button stays disabled until both the name and the destination are filled in. The new channel appears in the grid and immediately becomes selectable in the Create Alert Rule modal.

Testing a channel

Always test a new channel before you rely on it. A typo in an email address or a stale Slack webhook means your alerts go nowhere, and you only find out during the incident you were trying to catch.

On the channel card, click Test. The button shows "Testing…" while it works, then a confirmation that the test was sent, and the card updates its "Last tested" timestamp. Check that the test message actually arrived: a test email in the inbox, or a test post in the Slack channel. If nothing arrives, the destination is wrong: click Remove, recreate the channel with the corrected destination, and test again. The "Last tested" line on each card is a quick way to confirm at a glance that your channels are known-good.

Removing a channel

Click Remove on a channel card to delete it. If any rules still point at that channel, update those rules to a different channel first, so they continue to notify someone. Removing a channel does not affect alerts already raised; they remain in History.

A first-time setup, end to end

Putting the pieces together, here is the order to follow when you are starting from nothing:

Open Alerts from the sidebar and go to the Channels tab.
Click Add Channel, choose Email, name it (for example "Ops Email"), enter your team's alert address as the Destination, and click Add Channel.
Click Test on the new card and confirm the test email arrives.
Optionally repeat for a Slack channel using an incoming webhook URL, then test it too.
Switch to the Alert Rules tab and click Create Rule.
Create a DMARC failure rate above threshold rule with a sensible threshold (for example 10%), scoped to all domains or to specific ones, pointing at the channel you just made. Click Create Rule.
Create a second rule for SPF lookups at or above limit with a threshold of 9, so you are warned before SPF breaks.
Leave both rules Enabled. From now on, watch the Active Alerts tab (and your email or Slack) for anything that trips.

That is the whole loop: channels carry alerts, rules raise them, Active Alerts and History let you triage and audit. Once it is in place, your domains are watched continuously and you hear about problems while they are still small.

Where to go next

To understand the data these rules watch, read understanding your DMARC record and the enforcement journey.
To fix an SPF lookup alert for good, see how SPF flattening works.
To start protecting a new domain, see adding your first domain.
To check any domain's live records on demand, use the free DMARC checker, SPF checker and DKIM checker.
For definitions of any term used here, see the glossary.

Setting up alerts