DMARC Engine
Sign in Get started
Home/Documentation/Threat monitoring
Documentation

Threat monitoring

A click-by-click guide to the Threats page in the DMARC Engine dashboard: the Overview threat feed and severity, the IP Reputation checker, the per-domain Suspicious Senders view, and how to respond to what each one surfaces.

22 June 2026 · 19 min read

Aggregate reports tell you who is sending as your domain and whether it aligns. The Threats page asks a sharper question: of everything sending as you, which sources look hostile, where are they coming from, and is anyone actively abusing your name right now? This guide walks through the whole Threats page in the DMARC Engine dashboard: the Overview tab with its threat cards and severity, the IP Reputation checker, and the Suspicious Senders view, plus what to do about each thing you find.

Threat monitoring is the watchtower on top of the work you have already done. It does not replace reading your aggregate reports or moving your policy along the enforcement journey; it sits alongside them and surfaces the specific events and sources that warrant a human look. If you have not yet published a record or started receiving reports, do that first, because much of this page is fed by the same rua data your hosted DMARC record collects.

Opening the Threats page

In the dashboard, open Threats from the left-hand navigation. The page lives at https://app.dmarcengine.com/threats. At the top you will see the page heading Threat Intelligence with the helper line "Monitor and analyse email-based threats across your domains".

Directly beneath the heading is a tab bar with three tabs:

  • Overview: the threat feed. Headline counts at the top, then a searchable, filterable Recent Threats table of individual threat events with their type, severity and disposition.
  • Suspicious Senders: a per-domain view of source IPs that have failed DMARC for one of your domains over the last 30 days, ranked by how much of their mail is failing.
  • IP Reputation: an on-demand lookup tool that checks any IPv4 address against public DNS blocklists and reverse DNS, and returns a verdict and score.

Click a tab to switch between them. The page opens on Overview. The three tabs answer three different questions, so the order you use them in depends on what you are chasing. The sections below take each in turn, then close with how to respond to what you find.

The Overview tab

Overview is your threat feed: what has been detected recently, how serious it is, and what happened to it. It is the tab to glance at routinely and the first place to look when an alert tells you something is wrong.

The summary cards

Across the top of Overview are summary stat cards that give you a quick read before you touch the table:

  • Active Threats (24h) (red): the number of threat events recorded in the last 24 hours. This is your "is anything happening right now" number. A zero here, shown as "No data yet" when there is nothing to count, is the resting state you want.
  • Blocked (recent) (green): how many events in the loaded window were blocked outright. A healthy, enforcing setup converts threats into blocks, so a rising number here is not necessarily bad news; it is your defences doing their job.
  • Suspicious IPs (recent) (amber): the count of distinct source IPs across the loaded events. This tells you whether you are dealing with one noisy attacker or many.

Two things are worth understanding about these cards. First, they are a window over the most recently loaded page of threat events, not an all-time total; the labels say "recent" and "In loaded window" to make that explicit, so do not read them as lifetime figures. Second, while the data is loading or if it fails to load, the cards show a dash rather than a misleading zero, with "Loading…" or "Unavailable" underneath. A dash means "we do not know yet", not "nothing happened".

The Recent Threats table

Below the cards is the Recent Threats card. On its header sits a search box, "Search threats...", and a Severity filter. Underneath is the table itself, one row per detected threat event, with these columns:

  • Time: when the event was detected, in your local time. This column is sortable, so you can order newest or oldest first.
  • Source IP: the sending address behind the event, shown in a monospace font so it is easy to read and copy. Copy this when you move to the IP Reputation tab to investigate it.
  • Type: a badge naming the kind of threat, for example spoofing, phishing, unauthorized or brute-force. This is the nature of the event, not its severity.
  • Severity: a colour-coded badge, critical (red), high (amber), medium (grey) or low (blue). Severity is the platform's assessment of how much this event matters. It is sortable, so you can pull the worst to the top.
  • Target: the domain of yours that the event was aimed at. Sortable, so you can group everything hitting one domain together.
  • Action: the disposition badge, what actually happened to the mail: blocked (green), quarantined (amber), delivered (red) or reported (blue). Read this against severity. A critical event that was blocked is the system working as intended; a critical event that was delivered is the one that should worry you, because it reached a mailbox.
The colours on the Action column are deliberately counterintuitive: delivered is red, not green. On the rest of the dashboard delivered mail is good, but on the Threats page a delivered threat is the worst outcome, because it means a hostile message landed in an inbox. The colour is telling you about risk, not about delivery success.

Each row can be expanded to reveal a details line describing what was detected, for example "Attempted to spoof CEO email address with forged headers targeting finance department". Click a row to open it and read the full description before you decide how to respond.

Searching and filtering threats

The two controls in the card header narrow the table:

  • The Severity filter is a dropdown with Critical, High, Medium and Low. Choosing one restricts the table to events of that severity. This filter is applied across your whole dataset, not just the page on screen, and it resets you to the first page so you always see the most recent matching events. Use it to cut straight to Critical when you only have time to deal with the serious items.
  • The search box does a free-text match on the source IP and the threat details. It is the fastest way to pull up everything tied to one attacking IP, or every event mentioning a particular tactic.

There is one behaviour worth knowing. The severity filter works across the full set of events, but the search box filters only the rows currently loaded on screen. When a search is active you will see a small note, "search filters the loaded page only", and the pager behaves accordingly. In practice this means: filter by severity first to bound the dataset, then search within it. If a search seems to be missing results, clear it, page through, or tighten the severity filter instead.

When the feed is empty

If no threats have been recorded, the table shows a "No threats detected" empty state explaining that threats will appear here as they are detected. If your search matches nothing on the current page, you instead see "No matching threats" prompting you to clear the search or change the severity filter. An empty threat feed is a good thing: it means nothing hostile has been flagged. If the feed fails to load, an error message appears in place of the table; refresh the page to try again.

The IP Reputation tab

The IP Reputation tab is a standalone investigation tool. Where the Overview feed tells you an IP did something, this tab tells you what that IP's wider reputation is: whether it appears on public blocklists, what its reverse DNS says, and an overall score. Reach for it whenever you have an IP you do not recognise, whether you copied it from the threat feed, from your aggregate reports, or from a raw message header.

Running a check

The tab opens with an IP Reputation Check card. Its description reads "Look up an IPv4 address against public DNS blocklists (DNSBLs) and reverse DNS." Below that is a single field and a button:

  • IPv4 address: the field where you type the address to check, for example 203.0.113.10. It takes a single IPv4 address, not a hostname or a range.
  • Check: the button that runs the lookup. While it works it reads "Checking…" and the field is disabled; the results appear in a new card beneath when it finishes. You can also press Enter in the field to run the check.

If you click Check with the field empty, you are prompted to enter an IPv4 address. If the lookup itself fails, an error message appears in a card below instead of results; correct the address and try again. Until you have run a check, the tab shows a "No check run yet" placeholder inviting you to enter an address.

Reading the result

A completed check produces a result card with several parts. Read them together rather than fixating on any one.

  • The IP and its verdict: the address you checked, in monospace, next to a verdict badge. The three verdicts are Clean (green): the IP is not listed on the blocklists that responded; Caution (amber): the IP appears on some lists, enough to be wary but not damning; and High Risk (red): the IP is listed widely and should be treated as hostile. The verdict is the headline; the rest of the card is the evidence behind it.
  • Reverse DNS: the PTR record for the IP, shown in monospace, or "no PTR" in italics if the address has none. Reverse DNS is a soft signal. A legitimate mail server almost always has a sensible PTR that matches its sending domain; an IP with no PTR, or a generic residential or VPS-style PTR, sending mail as your domain, is a red flag worth weighing alongside the verdict.
  • The score: a figure out of 100, for example 30/100, with a line underneath reading "Listed on N of M reachable lists". The score summarises how many of the blocklists that actually answered have the IP listed. Read it together with that "N of M" line, because it tells you how much data the score is based on.

Below the headline is the checks table, one row per blocklist queried. Each row names the list and shows its result as a badge:

  • Clean (green): that list does not have the IP listed.
  • Listed (red): the IP is on that list. Where the list returns specific return codes, they are shown in brackets after the word, for example "Listed (127.0.0.4)", which can indicate the category of listing.
  • Resolver refused (grey): that list did not give a usable answer. Some DNSBLs refuse queries that come from large public resolvers, so they cannot be checked from here.

A footnote on the card spells out the most important caveat: lists reported as unavailable, the "Resolver refused" rows, are excluded from the score rather than counted as either clean or listed. This matters when you interpret the result. A Clean verdict built on only a handful of reachable lists is weaker evidence than a Clean verdict where most lists answered. Always glance at the "N of M reachable lists" line before you trust a clean result, and treat a high score across many reachable lists as the strong signal it is.

The IP Reputation tab is a reputation lookup, not an allow or block control. Checking an IP here does not block it, and a High Risk verdict does not by itself stop that IP from sending as you. Blocking unaligned senders is the job of your DMARC policy at p=reject, not of this tool. Use the verdict to inform a decision; enforce the decision with policy.

If you only ever use one part of this tab, make it this: when an unfamiliar IP shows up in your aggregate reports or the threat feed, paste it in here. A Clean verdict on a well-known organisation usually means a legitimate sender you forgot to align; a High Risk verdict with no PTR is almost always something to reject.

The Suspicious Senders tab

The Suspicious Senders tab answers a focused, practical question: for a given domain of mine, which source IPs are failing DMARC, and how badly? It is built directly from your aggregate report data over a rolling 30-day window, so unlike the Overview feed it is not about discrete attack events; it is about senders that are quietly failing authentication and therefore either need fixing or need stopping.

Choosing a domain and window

At the top of the tab is a domain picker dropdown. Suspicious senders are calculated per domain, so the tab shows one domain at a time. It defaults to your first domain once your domains load; change it to investigate another. Next to the picker is a fixed note: "Last 30 days · IPs with at least one DMARC failure". That sums up exactly what the tab shows: any source IP that, for the chosen domain, had at least one message fail DMARC in the past 30 days. Below the picker is a search box, "Search by IP...", that filters the table to a particular address as you type.

If you have not added any domains yet, the tab shows a "No domains yet" empty state prompting you to add a domain first; see adding your first domain. If the data fails to load, an error is shown in its place.

The source table

With a domain selected and data available, the tab shows a table of suspicious senders, sorted so the worst offenders, those with the most failing mail, come first. The columns are:

  • Source IP: the sending address, in monospace. This is the IP to copy into the IP Reputation tab to investigate further.
  • Total Volume: the total number of messages from that IP for this domain over the 30 days. Sortable, so you can rank by overall volume.
  • Failing: how many of those messages failed DMARC, shown in red. Sortable. This, not total volume, is the number that ranks the table by default, because an IP sending a million aligned messages and one failure is far less interesting than an IP whose mail fails wholesale.
  • DMARC Pass Rate: a badge showing the share of that IP's mail that passed DMARC, coloured green at 90% or above, amber from 70 to 89%, and red below 70%. A red badge here is a source that is mostly or entirely failing.

The table is paginated ten rows at a time. If no source IP failed DMARC for the chosen domain in the window, you see a "No suspicious senders" empty state explaining that suspicious senders appear once aggregate reports record DMARC failures. An empty table here is genuinely good news: it means every source sending as that domain in the last 30 days aligned cleanly.

Reading the pass rate honestly

The DMARC Pass Rate badge is the key to triage on this tab, but it needs context. A high pass rate with a small failing count is usually benign: a well-aligned sender whose mail occasionally fails because it was forwarded or sent through a mailing list, where SPF breaks even though the message is legitimate. A low pass rate with high volume is the opposite: a source that is failing at scale. That second case is either an important business sender you have not authenticated yet, or someone abusing your domain. Either way it needs action before you tighten policy, because under p=reject every one of those failing messages would be blocked.

This is why the tab ranks by failing volume rather than by pass rate alone. A source with a red badge but only a handful of failing messages is lower priority than a source with an amber badge that is failing thousands of messages. Work down the table from the top: the biggest failing volumes are where an enforcing policy would do the most damage if the sender turns out to be legitimate, and the most harm if it turns out to be hostile.

How to respond to what you find

Finding a threat or a suspicious sender is only half the job. The point of this page is to drive a decision. For any source that surfaces here, work through three questions in order.

1. Identify the source

Start by working out what the IP actually is. Copy the Source IP and run it through the IP Reputation tab. Look at three things together: the verdict (Clean, Caution or High Risk), the reverse DNS, and the score with its "N of M reachable lists" line. A clean, well-known organisation with a matching PTR is almost certainly a legitimate sender. A high-risk IP with no PTR, on many lists, is almost certainly hostile. Cross-reference the IP against your own records too: is it one of your providers, a tool a department signed up for, a forwarder?

2. Decide which case it is

Every source on this page falls into one of three buckets, and the right response is different for each.

  • A legitimate sender you forgot to align. This is the most common outcome on the Suspicious Senders tab. The fix is to authenticate it, not block it: bring it into your SPF and set up DKIM signing for it, then confirm in the next report cycle that its pass rate climbs. Hosted SPF and Hosted DKIM cover how. Only once it aligns is it safe to enforce against everything else.
  • A legitimate sender you no longer use. Sometimes a failing source is an old tool still sending the odd automated message. Decommission it at the source so it stops sending in your name, rather than relying on policy to suppress it forever.
  • An impersonator. A source that sends real volume, fails DMARC wholesale, scores High Risk, and matches nothing you use, is spoofing your domain. This is the threat DMARC exists to stop. The right response is not to chase that one IP, because an attacker simply moves to another, but to complete your move to p=reject, at which point receivers reject every unaligned source, including this one, automatically.

3. Enforce with policy, and watch for the next one

The golden rule is sequencing: authenticate every legitimate source first, confirm it aligns in a fresh report cycle, and only then tighten policy. If you raise enforcement while a legitimate sender on the Suspicious Senders tab is still failing, you will block real mail. The Threats page exists so that you find those senders before your policy does. For the full step-by-step path from monitoring to enforcement, see the enforcement journey, and for why a permanent p=none leaves you exposed to exactly the impersonators this page surfaces, see why p=none is false security.

Finally, make this a habit rather than a one-off. You should not have to remember to open the Threats page; let the platform tell you when something changes. Set up an alert so that a spike in DMARC failures, the kind that would populate the Suspicious Senders tab, pages you the moment it happens. See setting up alerts to wire that up. The Threats page is then where you go to investigate when an alert fires, rather than a dashboard you have to remember to check.

A routine that works

Putting the tabs together into a workflow:

  1. Glance at the Overview cards. If Active Threats (24h) is zero and nothing in the Recent Threats table is critical and delivered, you are clear for the day.
  2. If something serious shows, expand the row to read its details, then copy its Source IP into the IP Reputation tab to get a verdict, PTR and score.
  3. For ongoing authentication problems rather than one-off events, open Suspicious Senders, pick the affected domain, and work down the table from the highest failing volume.
  4. For each failing source, decide: authenticate it, decommission it, or treat it as an impersonator to be rejected once you enforce.
  5. Fix the legitimate sources, wait a report cycle, and confirm their pass rates recover on the Suspicious Senders tab and in your aggregate reports.
  6. Only when every legitimate source aligns cleanly should you advance your policy towards quarantine and reject on the Hosted DMARC page.

Where the threat data comes from

It helps to know the plumbing behind each tab so you read it correctly. The Suspicious Senders tab is computed directly from your hosted DMARC aggregate (rua) data, the same source that feeds the aggregate reports views, filtered to a 30-day window and to sources with at least one DMARC failure. That is why it only has data for domains whose reports are flowing; if a domain shows nothing, check that its hosted record is published and that reports have started arriving, as covered in Hosted DMARC and delegating your DNS. The IP Reputation tab queries public DNS blocklists and reverse DNS live each time you run a check, so its results are current at the moment you click Check and owe nothing to your own configuration. The Overview feed records discrete threat events as they are detected across your domains.

Because these sources differ, do not expect the three tabs to show the same IPs. An IP can be High Risk on IP Reputation yet absent from Suspicious Senders because it never sent as one of your domains; a sender can sit at the top of Suspicious Senders yet come back Clean on IP Reputation because it is a legitimate but unaligned provider. Reading them together is the point: reputation tells you what an IP is, suspicious senders tells you what it is doing to your domains, and the feed tells you what was caught.

Share

See where your domain stands today

Run a free DMARC scan, then let us take you to enforced p=reject with no email outage.

Scan my domainGet started