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.

Legacy DMARC platforms display these rows and leave classification to the user. If authentication failed, it shows as failed. What that failure means — whether it is a misconfiguration you need to fix, a forwarder you need to accommodate, or an attacker you need to act on — requires manual investigation that most teams do not have the capacity to perform at scale.

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 is cross-referenced against threat intelligence feeds that aggregate reports of malicious activity. 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.
• Cross-domain consistency. When a source appears across multiple customer domains in our platform, its behaviour across that broader dataset informs its classification for each individual domain. A source seen sending authenticated mail across hundreds of domains is almost certainly a legitimate service. A source seen only targeting one domain with repeated authentication failures is a stronger threat signal.

AI evaluation on top of raw signals

Raw signal scores are good at catching clear-cut cases. A known-bad IP sending thousands of unauthenticated messages to multiple target domains 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 evaluation adds the most value. Our engine passes the aggregated signal context to an AI evaluation layer that reasons about the combination of factors holistically — the way an experienced security analyst would when investigating a suspicious source manually.

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 proprietary database that compounds over time

Every DMARC report processed by ShieldMarc contributes to a growing dataset of sending source behaviour. As more domains are monitored and more reports are ingested, the engine's picture of the global email sending landscape becomes more detailed and more accurate.

This creates a compounding advantage. A source that has been classified as a legitimate provider across thousands of domains requires far less signal weight to classify correctly when it appears on a new domain. A source that has been associated with spoofing attempts across multiple customers triggers faster and with higher confidence as the pattern accumulates.

Individual signal scores are commoditised — any platform can buy access to the same IP reputation feeds. The proprietary dataset of how sources behave specifically in the context of DMARC authentication, across a real customer base, over time, is not something a competitor can purchase or replicate overnight. It is the kind of advantage that only comes from operating the platform at scale.

What this means in practice

For customers, the practical effect is fewer alerts that mean nothing and more alerts that mean something. When the threat feed surfaces a finding, it has been through signal scoring, AI evaluation, and cross-domain consistency checking before reaching your dashboard. 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 escalated with the full context: the source IP, its reputation history, the volume and pattern of the attempt, and a confidence level based on the weight of signals pointing to malicious intent.

MSPs managing multiple client domains benefit disproportionately. A threat actor targeting one client via domain spoofing will often probe other domains in the same portfolio. Because our detection operates across all monitored domains simultaneously, a pattern that emerges on one client domain can inform the classification of the same source when it appears on another.