How ShieldMarc Threat Detection Works

The noise problem

A typical DMARC report for an active domain contains dozens or hundreds of rows. Each row represents a source that sent email claiming to be from your domain during that reporting period. Some of those sources are your own infrastructure. Some are third-party services you have authorised. Some represent forwarded mail that broke authentication in transit. And some represent someone actively attempting to spoof your domain.

A report lists these rows without saying what they mean. If authentication failed, it shows as failed. Whether that failure is a misconfiguration you need to fix, a forwarder you need to accommodate or an attacker you need to act on takes manual investigation, which few teams have time for across many domains.

The result is either alert fatigue (every failure fires a notification, most of which are noise) or under-alerting (notifications are turned off because they are too noisy to be useful). Neither outcome serves the purpose of DMARC monitoring.

A multi-signal scoring approach

Every row in every DMARC report processed by ShieldMarc is evaluated by a scoring engine before it reaches your dashboard. The engine does not make binary pass/fail decisions. It builds a weighted threat score from multiple independent signals, then uses that score to classify the sending source.

The signals the engine evaluates include:

• IP reputation data. The sending IP of a failing source is cross-referenced against an IP reputation database that collects reports of abuse. An IP with a history of spam, phishing, or abuse campaigns scores differently from a clean commercial sending IP. A cloud infrastructure IP with no prior reputation is treated differently again.
• Reverse DNS and ASN context. The hostname that resolves from the sending IP, and the autonomous system that owns it, provide strong contextual signals. A legitimate sending service typically has a consistent, branded reverse DNS record. An attacker spinning up a VPS to send spoofed mail typically does not. The ASN tells us whether the traffic originates from a known email provider, a cloud platform, a residential ISP, or a hosting provider commonly associated with abuse.
• SPF and DKIM alignment patterns. How a source fails authentication matters as much as the failure itself. A source that passes DKIM but fails SPF alignment looks very different from a source that fails both with no DKIM signature at all. Spoofing attempts typically show consistent patterns: failed SPF, no DKIM, high message volume, and a sending IP with no relationship to the domain being claimed.
• Volume and velocity. A single failed message from an unfamiliar IP is a different risk profile from ten thousand failed messages from the same IP in a 24-hour window. The engine weights volume and rate-of-change, so a sudden spike from a new source is treated with higher suspicion than a consistent low-volume pattern from a known forwarder.
• History on your domain. Each row is compared with your domain's recent reports. A source sending as your domain for the first time is a signal in its own right, and it weighs more when the source also fails DKIM alignment. A DKIM selector your domain has not used before counts too, when it fails verification.

AI explanations, on request

Raw signal scores are good at catching clear-cut cases. A known-bad IP sending thousands of unauthenticated messages as your domain does not need AI to classify. The score is high, the classification is straightforward.

The harder cases are in the middle: sources with mixed signals, ambiguous infrastructure, or unusual-but-potentially-legitimate sending patterns. This is where AI adds the most value, and it runs only when you ask. On paid plans and during the trial, Ask AI on the Email page starts from the sources our deterministic classifier has already sorted for your domain and reasons about the combination of factors together, the way an experienced security analyst would when investigating a suspicious source manually.

Scan for threats applies the same reasoning to a whole domain. You pick one of your domains and start the scan, and the AI reviews its reports from up to the last 30 days. It sorts the failing senders into forwarded copies, your own services that need a fix and sources that look like abuse, then lists the actions in order of impact. It comes with the Professional and MSP plans and the free trial.

The AI layer does not replace the signal scoring. It works on top of it. The goal is not to use AI everywhere; it is to use it precisely where human-style reasoning about ambiguous context produces a materially better result than a fixed scoring threshold. The engineering foundation has to be sound first. AI is the last mile.

A history that grows with every report

Every DMARC report ShieldMarc processes for your domain adds to that domain's history. The engine checks each new row against it: whether the source has sent as your domain before, whether its DKIM selector is new, and how its volume compares with the weeks before.

A source that the AI review or an admin has already judged benign for your domain needs less signal weight the next time it sends as you.

Individual signal scores are commoditised: any platform can buy access to the same IP reputation data. What a reputation database cannot supply is how each source has behaved in your own domain's DMARC reports, recorded over time.

What this means in practice

For customers, the practical effect is less noise and clearer findings. When the Email page flags a sender as suspicious, it has already been through signal scoring before it reaches you. You are not reading a raw DMARC row and deciding whether it matters. You are reading a classified finding with context.

• Misconfigured services are identified as such, so you know to fix your SPF or DKIM setup rather than treating them as a security incident.
• Known forwarders (university systems, mailing lists, legacy mail relays) are recognised and deprioritised, so they do not generate noise for every forwarded message.
• Genuine spoofing attempts are flagged on the Email page with the context behind the score: the source IP, the signals against it and the volume it sent. When you want a closer look, Scan for threats gives a written review of the failing senders on the domain.

MSPs managing many client domains get the same scoring on each one as its reports arrive. When one client domain needs a closer look, Scan for threats reviews it and lists the priority actions.