Notification channels

22 June 2026 · 17 min read

What a notification channel is

A notification channel is a destination: the place where DMARC Engine actually delivers an alert or a report. On their own, the rules you build do nothing visible. A rule watches a condition, and when that condition trips it raises an alert; but unless that alert has somewhere to go, you would have to be staring at the dashboard to notice. A channel is that somewhere. It is the inbox, the Slack room, the shared address that receives the message and turns a silent change in your data into something a human reads.

Getting channels right is the difference between catching a problem while it is small and finding out a week later that mail has been failing. A mistyped email address or a stale Slack webhook means your alerts go nowhere, and you only discover the gap during the exact incident the channel was meant to warn you about. This guide therefore covers not just how to create email and Slack channels, but how to test them, how to connect them to your alert rules, and how to keep them healthy over time.

There are two places in the dashboard where channels appear, and they are the same underlying list shown in two locations for convenience:

• The Notification Channels tab on the Alerts page, alongside Active Alerts and Alert Rules. This is the natural home if you are thinking about alerting end to end.
• The Notifications tab in Settings, alongside Profile, Organization, Security, API Keys, Team and Billing. This is the natural home if you are working through your account configuration.

A channel you create in one place appears in the other immediately, because there is a single set of channels per organisation. Use whichever entry point you happen to be near.

If you are configuring alerting from scratch, channels come first. A rule must point at a channel, so you cannot finish a rule until at least one channel exists. The rest of this guide assumes you are starting from nothing and building up: create a channel, test it, then connect it to a rule.

Finding the Notification Channels tab

In the dashboard, open Alerts from the left-hand navigation. The Alerts page opens on the Active Alerts tab by default. Across the top of the page are three tabs:

• Active Alerts: the alerts that have fired and not yet been cleared. This is your triage queue.
• Alert Rules: the conditions you have defined that raise alerts.
• Notification Channels: the destinations those alerts are delivered to. This is the tab this guide is about.

Click Notification Channels. You will see a list of the channels already configured on your account, or an empty state inviting you to create your first one if you have none yet.

The identical list is reachable from Settings. Open Settings from the left-hand navigation and select the Notifications tab. The channel list and the Create Notification Channel button there behave exactly as they do on the Alerts page. Throughout this guide, anywhere we say "the channel list" or "the Create Notification Channel button", you can use either location.

Reading the channel list

Each channel you have created is shown as a row in the channel list. A row carries everything you need to identify a channel and act on it:

• Name: the label you gave the channel when you created it, for example "Ops Email" or "Security Slack". This is the name that appears in the Create Alert Rule modal when you connect a rule to a channel, so a clear name here saves confusion later.
• Type: which kind of channel it is. DMARC Engine supports four channel types: Email, Slack, Webhook (a generic HTTPS endpoint) and PagerDuty. The type determines what kind of destination the channel holds (an email address, a Slack webhook URL, an HTTPS webhook URL or a PagerDuty integration) and how the message is formatted when it is delivered. A Webhook channel must use an https:// URL and is protected against SSRF: it cannot point at internal, loopback or private network addresses.
• A status toggle: a switch you flip to enable or disable the channel without deleting it. A disabled channel receives nothing, even from rules that point at it. This is covered in detail below.
• A Test button: sends a sample message to the channel right now, so you can confirm it works before you depend on it.
• A Delete action: removes the channel permanently.

If you have no channels yet, the list shows an empty state rather than rows, with the Create Notification Channel button ready for you to make your first one. There is nothing wrong with an empty list on a brand-new account; it simply means you have not set up where alerts should go.

Creating an email channel

Email is the channel most people start with, because everyone already has an inbox and a team distribution address. To create one:

1. On the Notification Channels tab (or the Notifications tab in Settings), click Create Notification Channel. This opens the Create Notification Channel modal.
2. In Channel Type, choose Email. This tells the modal that the configuration you are about to enter is an email address, and it sets the expected format of the field below.
3. In Channel Name, type a clear label for the channel, for example "Ops Email" or "DMARC Alerts Inbox". This is a free-text field. Choose something you will recognise instantly when you see it in the Create Alert Rule modal at a glance, because that is where you will pick it again.
4. In Configuration, enter the email address that should receive alerts, for example alerts@example.com. This is the only place the actual destination is set, so type it carefully: a typo here means alerts go to the wrong place or nowhere at all.
5. Click the button to create the channel. The modal closes and the new channel appears as a row in the list.

A word on which address to use. A shared team or distribution address (security@, email-ops@, noc@) is almost always better than one person's personal inbox. Alerts sent to an individual are missed the moment that person is on leave, has changed roles or has left the company. A shared address means whoever is on duty sees the alert, and it survives staff changes without anyone having to remember to update the channel. If your organisation runs an on-call rotation, point the channel at the address that feeds that rotation.

You can create more than one email channel. It is common to have a general "Ops Email" for routine warnings and a separate, more closely watched address for critical alerts, then point different alert rules at each. The platform does not limit you to a single email channel.

Creating a Slack channel

A Slack channel posts alerts straight into a Slack conversation, which is ideal for teams that live in Slack and want alerts in the same place they already discuss them. Setting one up takes two parts: first you create an incoming webhook in Slack, then you paste its URL into DMARC Engine.

Step one: create the Slack incoming webhook

This part happens in Slack, not in DMARC Engine. An incoming webhook is a special URL that Slack gives you; anything posted to that URL appears as a message in a specific Slack channel you choose.

1. In Slack, decide which channel should receive alerts, for example #email-alerts or #security-ops. Create the channel first if it does not exist.
2. Add an Incoming Webhooks integration (sometimes called a Slack app with incoming webhooks enabled) and point it at that channel. Slack walks you through authorising it and choosing the destination channel.
3. Slack generates a webhook URL of the form https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX. Copy this URL. Treat it as a secret: anyone who has it can post into your Slack channel, so do not share it or commit it anywhere public.

If your workspace restricts who can add apps or webhooks, you may need a Slack administrator to do this part for you. The only thing DMARC Engine needs from Slack is that final webhook URL.

Step two: create the channel in DMARC Engine

1. On the Notification Channels tab, click Create Notification Channel to open the Create Notification Channel modal.
2. In Channel Type, choose Slack. The Configuration field now expects a webhook URL rather than an email address.
3. In Channel Name, type a clear label, for example "Security Slack" or "#email-alerts (Slack)". Including the Slack channel name in the label makes it obvious where alerts will land.
4. In Configuration, paste the incoming webhook URL you copied from Slack. It should begin with https://hooks.slack.com/services/.
5. Click the button to create the channel. It appears as a new row in the list, with its Type shown as Slack.

From now on, every alert delivered to this channel posts as a message into the Slack channel the webhook is tied to. If you later want alerts to go to a different Slack channel, you create a new webhook for that channel in Slack and a new notification channel here; a webhook URL is bound to one Slack channel and cannot be repointed from DMARC Engine.

Testing a channel

Always test a channel before you rely on it. Testing is the single most valuable habit in this whole area, because a channel that looks correct in the list can still be broken: an email address with a transposed letter, a Slack webhook that was revoked, a distribution list that silently drops external mail. The only way to know a channel works is to send something through it and confirm it arrives.

To test a channel, find its row in the channel list and click Test. DMARC Engine sends a sample notification to that channel's destination straight away, using exactly the same delivery path a real alert would use. Then go and check that it arrived:

• For an Email channel, open the destination inbox and confirm a test message from DMARC Engine is there. If it is not in the inbox within a minute or two, check the spam or junk folder, and check any filtering rules on a shared mailbox that might be diverting it.
• For a Slack channel, open the Slack channel the webhook points at and confirm a test message has been posted.

If the test message arrives, the channel is good and you can connect it to your rules with confidence. If nothing arrives, the destination is wrong or unreachable. For an email channel, re-check the address for typos and confirm the mailbox accepts external mail. For a Slack channel, confirm the webhook URL is current; webhooks can be revoked in Slack, and a revoked webhook silently fails. The cleanest fix for a bad destination is to delete the channel and create it again with the corrected configuration, then test once more.

Test a channel again whenever something about its destination might have changed: a mailbox is migrated, a distribution list is rebuilt, a Slack workspace is reorganised or a webhook is rotated. A two-second test now is far cheaper than a missed critical alert later.

Enabling and disabling a channel

Each channel row has a status toggle. Flip it off to disable the channel and on to enable it. A disabled channel keeps all of its settings (its name, type and configuration) but delivers nothing. Any alert rule that points at a disabled channel still fires and still raises an alert on the Active Alerts tab, but the message is not sent to that channel's destination while it is off.

Disabling is useful when you want to pause delivery temporarily without losing the configuration, for example during a planned maintenance window when you know alerts will be noisy, or while you are reorganising a Slack workspace. Because disabling a channel silences every rule that delivers to it, do so deliberately: it is easy to forget a channel is off and wonder later why no alerts arrived. If you only want to silence one specific rule rather than a whole channel, disable that rule on the Alert Rules tab instead, using its own status toggle, and leave the channel enabled for everything else.

When you are ready to resume delivery, flip the toggle back on. No re-testing is strictly required, but it is good practice to click Test after re-enabling a channel that has been off for a while, in case its destination drifted while it was disabled.

Deleting a channel

To remove a channel, use the Delete action on its row. Deletion is permanent: the channel and its configuration are gone, and any alert rule that was pointing at it will need a new destination.

Before you delete a channel, check whether any alert rules still depend on it. If a rule's only channel is the one you are about to delete, that rule would have nowhere to deliver to. The safe order is:

1. Open the Alert Rules tab and check which rules reference the channel you intend to remove.
2. For each of those rules, click Edit and point it at a different channel.
3. Return to the Notification Channels tab and Delete the now-unused channel.

Deleting a channel has no effect on alerts that have already been raised. Anything already on the Active Alerts tab stays there, and historical alerts are unaffected; Delete only removes the future delivery destination, not the record of past alerts.

Connecting channels to alert rules

A channel sitting on its own does nothing until a rule points at it. The link between the two is made when you create or edit an alert rule. This section covers the connection from the channel's point of view; for the full detail on conditions and thresholds, see setting up alerts.

On the Alert Rules tab, click Create Alert Rule to open the Create Alert Rule modal. The modal has these fields:

• Rule Name: a free-text name for the rule, for example "DMARC failure rate spike" or "SPF lookup warning". This name appears in the alerts the rule raises and in the messages delivered to your channels, so make it descriptive enough to recognise out of context.
• Condition: what the rule watches. The two conditions are DMARC failure rate, which fires when the share of your mail failing DMARC rises past your threshold, and SPF lookups, which fires when the number of DNS lookups your SPF record performs reaches your threshold. SPF has a hard limit of ten lookups, so this condition warns you before SPF breaks.
• Threshold: the trigger point as a number. For DMARC failure rate it is a percentage, for example 10 to fire when more than ten per cent of mail is failing. For SPF lookups it is a count, for example 9 to be warned one lookup before the limit.
• Domains: a set of checkboxes listing your domains. Tick one or more to scope the rule to just those domains, or leave them all unticked to apply the rule across every domain on the account.
• Enabled: a toggle that controls whether the rule is active. Leave it on for the rule to fire; turn it off to keep the rule configured but dormant.

The Domains checkboxes and the channel selection are how a rule is wired to a destination: you choose which channel receives the alert when the rule trips. Because the rule lists your channels by the Name you gave them, a clear channel name pays off here. Once you save the rule, it appears as a card on the Alert Rules tab showing its name, condition, threshold, domains and status toggle, with Edit and Delete actions. From that moment, whenever the rule's condition is met, an alert is raised on the Active Alerts tab and delivered to the connected channel.

To change which channel a rule uses later, click Edit on the rule card, change the channel, and save. To stop a rule firing entirely without deleting it, flip its status toggle off on the Alert Rules tab.

What happens when an alert fires

Putting the pieces together helps the whole flow make sense. When the platform evaluates your incoming aggregate data and a rule's condition crosses its threshold, three things happen in order:

1. An alert is raised and appears on the Active Alerts tab, with a title, a severity badge, the date it was created and a status of active.
2. The alert is delivered to the notification channel the rule is connected to, provided that channel is enabled. An email channel sends an email to its configured address; a Slack channel posts a message to its webhook's channel.
3. You triage the alert from the Active Alerts tab. Use the status filter at the top to switch between active, acknowledged and resolved alerts. Click Acknowledge to mark an alert as being worked on (it stays in the list so you do not lose track of it), and Resolve once the underlying issue is fixed, which clears it from the active view.

The channel's job is step two: carrying the alert out of the dashboard to where your team will see it. Everything else, the raising and the triaging, happens around it. This is why a tested, healthy channel matters so much: it is the only part of the chain that reaches a person who is not currently looking at the dashboard.

A first-time setup, end to end

If you are starting from nothing, this is the order that works:

1. Open Alerts from the navigation and click the Notification Channels tab (or open Settings and click Notifications).
2. Click Create Notification Channel, set Channel Type to Email, give it a Channel Name such as "Ops Email", enter your team's shared alert address in Configuration, and create it.
3. Click Test on the new channel and confirm the test email arrives in the inbox.
4. Optionally, create a webhook in Slack, then create a second channel with Channel Type set to Slack, paste the webhook URL into Configuration, and Test it too.
5. Switch to the Alert Rules tab and click Create Alert Rule.
6. Create a rule with Condition set to DMARC failure rate, a Threshold such as 10, the Domains you want it to cover, the Enabled toggle on, and connect it to your channel.
7. Create a second rule with Condition set to SPF lookups and a Threshold of 9, so you are warned before SPF reaches its ten-lookup limit.
8. Leave both rules enabled and keep an eye on the Active Alerts tab, your inbox and your Slack channel.

From then on your domains are watched continuously, and the moment something drifts you hear about it through the channels you tested.

Keeping channels healthy

Channels are not a set-and-forget item. A few habits keep them reliable:

• Re-test after any change to a destination. If a mailbox is migrated, a distribution list rebuilt, or a Slack webhook rotated, click Test to confirm the channel still works.
• Prefer shared addresses to individuals. People leave and take holidays; shared addresses and on-call rotations do not. This is the single biggest cause of missed alerts.
• Review channels when someone leaves the team. A departing colleague may have created channels pointing at their own inbox or a personal Slack webhook. Check the channel list and re-point or delete anything tied to them. The same review applies to API keys and team membership; see team and roles.
• Keep the list tidy. Delete channels you no longer use, after re-pointing any rules that referenced them, so the Create Alert Rule modal stays uncluttered and every channel in the list is one you trust.

Where to go next

• For the full detail on alert conditions, thresholds and triage, read setting up alerts and monitoring and change alerts.
• To understand the aggregate data these alerts are built on, see aggregate report analysis and understanding your DMARC record.
• To fix an SPF lookup alert for good rather than just being warned about it, see how SPF flattening works.
• To control who in your organisation can manage channels and rules, see team and roles.
• To check any domain's live posture on demand, use the free DMARC checker, SPF checker and DKIM checker, or analyse a raw report with the DMARC report analyzer.
• For plain-English definitions of any term used here, see the glossary.