The MSP's competitive edge in domain security

How MSPs are using these tools to win business

1. Walk into a meeting with evidence: Run a Security Grade scan on a prospect's domain. In seconds you have a clear security score covering DMARC, SPF, SSL, DNSSEC, and more. You are showing facts, not a pitch deck.
2. Surface the gaps they did not know they had: The scan identifies specific, fixable issues: missing DMARC policy, weak SPF, expiring certificates, unsigned DNSSEC. Every gap is an opportunity you can quote for.
3. Show them the threat landscape: Use the Lookalike Domain Scanner to show which confusingly similar domains already exist. Most clients have never seen this. It changes the conversation instantly.
4. Close and onboard in the same meeting: Once they see the score, add their domains to the dashboard. Monitoring starts immediately. Brand alternates are detected automatically. You go from audit to active protection in minutes.

How ShieldMarc helps your clients get insured and stay insured

• DMARC at enforcement, the single most-asked question on cyber insurance applications. ShieldMarc tracks policy stage and guides you to p=reject.
• SPF and DKIM alignment. Insurers want to see that legitimate mail is properly authenticated, not just that a record exists.
• SSL/TLS certificates valid and monitored. Expired certificates signal neglect. Continuous monitoring removes that risk.
• DNSSEC, MTA-STS, TLS-RPT: advanced controls that demonstrate mature security posture. ShieldMarc checks all three.
• Security Grade as evidence, a single, auditable score your client can present to their broker. It covers every signal in one scan.

All the signals in one view

DMARC aggregate reports, SPF and DKIM alignment, SSL certificate state, DNS record history, DNSSEC, MTA-STS, TLS-RPT, CAA, domain expiry and WHOIS changes, uptime and lookalike registrations all land in a single per-domain view, correlated by timestamp. If DKIM alignment started failing on Tuesday at 14:07 and a DNS TXT record changed at 14:05, they are next to each other. You see cause and effect, not four disconnected dashboards.

Claude AI on tap for deep reasoning, enriched by our threat model

On paid plans, the AI analysis buttons on DMARC reports, threat-feed and domain posture route to a frontier Anthropic Claude model. The model does not see raw DMARC XML. It sees a pre-enriched context assembled by our own threat model: each sending source scored for IP reputation, reverse DNS and ASN fit, SPF and DKIM alignment shape, volume and velocity, and cross-domain behaviour across our entire customer base. Claude reasons on top of that prepared picture, correlates it with the full per-domain signal bundle (DMARC, SPF, DKIM, SSL, DNS, DNSSEC, MTA-STS, TLS-RPT, uptime, WHOIS, lookalikes), and plain-Englishes the specific change, selector rotation, or sender behaviour that caused the break. This is why the output is specific, not generic: the reasoning is Claude; the signal quality is ours.

Free-tool explainers (DMARC Checker, Security Grade, SSL, DNSSEC) run on cheaper models because they do not need that depth, and that is how we keep the free tier genuinely free.

AI never runs on its own. The model only reads your signals when an operator explicitly clicks an AI analysis button. No background inference, no auto- summaries, no silent outbound calls. The signal layer, the enforcement engine and the alerts all run deterministically without AI involvement.

That is how a single engineer covers 100 client domains across DMARC, SSL, DNS and brand protection without drowning. Correlated signals plus frontier-grade AI reasoning on demand is the compounding advantage modern MSPs run on.

How our threat scoring engine works

Every row in every DMARC report we parse runs through five independent signal checks before anything surfaces in your dashboard:

• Sending IP reputation, cross-referenced against public abuse feeds, so spam-associated IPs score very differently from clean commercial mail relays.
• Reverse DNS and ASN: does the PTR record look like a branded mail service, or a generic VPS on a hosting ASN with no mail history?
• Failure shape: SPF-pass DKIM-fail looks like a forwarder; DKIM-missing high-volume from an unknown IP looks like spoofing.
• Volume and velocity: a sudden spike from a new source is treated very differently from a steady low-volume pattern from a familiar one.
• Cross-domain consistency: if the same IP sends authenticated mail for hundreds of other domains on the platform it is almost certainly legitimate; if it only targets one customer with repeated auth failures, the score is pushed the other way.

The weighted score classifies each source as misconfig, forwarder, or threat. Misconfigurations become configuration tasks you can action. Forwarders are recognised and deprioritised so they stop generating noise. Threats are escalated with the source IP, the reputation history, the volume curve, and the confidence level. You do not investigate every failure; you investigate the ones the engine flags.

Every report we parse adds to a proprietary dataset of sending source behaviour across our customer base. The dataset compounds. An actor probing one client is far more likely to be identified when they probe another, because the signal pattern is already in our engine.

The only personal data we hold

• Your account and team-member email addresses, for login, invites and notifications.
• Authentication and audit log entries, including IP address and user agent for each significant action.
• DMARC forensic (RUF) report headers, only in the rare cases where receivers send them. Google, Microsoft and Yahoo do not send RUF by default, so this set is empty or near-empty for most customers. Headers only, never body content.

We never store email body content, card data, or any personal data relating to your end users. That is a deliberate product decision, not a future aspiration. Full detail on the Trust page.