ActiScan

MSP Operations

The Cross-Sell Sitting in Your Existing Client List

September 17, 2026

Ric Hall, CRO— AI-assisted and reviewed prior to publication.

A magnifying glass beside one folder pulled forward from a row of client files on a desk

Every MSP sales deck talks about new logo growth, but the fastest revenue an MSP can add this quarter is usually already under contract. It is sitting in domains the MSP already manages, in DNS records nobody has audited since onboarding, and in email authentication gaps that quietly put clients at risk of both fraud and deliverability failure.

The core answer is simple: the highest-probability cross-sell for an MSP is closing DMARC, SPF, and DKIM gaps across clients already on a managed services contract, because the need is provable with a scan, the fix is billable, and the client relationship already exists. No new prospecting is required, only a domain audit and a proposal.

Why does this cross-sell outperform net-new sales?

It outperforms net-new sales because the trust and billing relationship already exist, which removes the two hardest parts of any sale. The MSP is not asking a stranger to sign a contract, it is asking a paying client to fix something the MSP can show them in their own DNS records.

Industry data backs the timing. Kaseya's 2025 Global MSP Benchmark Report found that security services have become central to channel revenue, with 67% of respondents naming security one of their five fastest-growing revenue categories. The demand is there. What is often missing is a concrete, low-friction reason to open the conversation with a specific client this month rather than someday.

Email authentication provides that reason because it is binary and checkable. A domain either publishes a DMARC record at enforcement or it does not, and an MSP can prove which is true in under a minute with a free lookup, then walk into the account with a finding instead of a pitch.

What the scan usually finds

Run a DMARC and SPF check across a typical client book and a predictable pattern emerges. Some clients have no DMARC record at all. Others published a record years ago at p=none, which only monitors mail flow and enforces nothing, and never moved to quarantine or reject. A smaller group has SPF records that exceed the ten DNS lookup limit defined in the specification, which causes a permanent error result regardless of whether the sending server is legitimate, a failure mode described directly in the SPF standard's lookup limit guidance that underpins DMARC's own alignment checks.

These are not edge cases. Adoption research from EasyDMARC's 2025 report found that DMARC adoption among top domains grew from 27.2% to 47.7% between 2023 and 2025, which means well under half of monitored domains had a record at all, and a separate analysis tracking hundreds of thousands of domains found that even among domains with a valid DMARC record, only a small fraction are actually enforcing a reject or quarantine policy rather than merely monitoring. In practical terms, an MSP scanning fifty client domains should expect to find real, fixable gaps in a meaningful share of them.

Is there already a forcing function, or does the MSP have to create one?

There is already a forcing function, and it did not come from the security industry, it came from the mailbox providers. Google and Yahoo now require authentication from senders, which turns "you should fix this" into "you are already out of compliance with your own inbox provider."

Google's own Workspace documentation states plainly that starting February 1, 2024, email senders who send more than 5,000 messages per day to Gmail accounts must meet SPF, DKIM, and DMARC requirements, and Google's sender guidelines FAQ spells out the specific alignment mechanics that make a DMARC record actually count toward compliance rather than just exist. This is not a future roadmap item, it has been enforced for well over a year, and clients who cleared the bar in early 2024 with a loose configuration may have drifted since as marketing tools and new SaaS senders were added without anyone updating the SPF record.

That drift is the second half of the cross-sell. A domain that passed a compliance check eighteen months ago is not guaranteed to pass one today, and an MSP that only checked once at onboarding has no way of knowing whether the client's current state matches what was documented. Recurring scans, not a one-time audit, are what catch the moment a new CRM or webinar tool breaks alignment.

Framing the risk without overselling it

The commercial case should stay grounded in specific, defensible numbers, not fear-based generalities that erode trust when a client asks a follow-up question. The FBI's Internet Crime Complaint Center is the strongest source available here.

The 2024 IC3 Annual Report is a federal law enforcement document, which makes it a stronger reference for a client conversation than any vendor estimate. It recorded that business email compromise losses totaled $2.77 billion in 2024 alone, and separate IC3 reporting tracked in coverage from Nacha shows that BEC-related losses reported to IC3 reached roughly $8.5 billion cumulatively over the prior three years. DMARC enforcement does not stop every BEC attempt, since many BEC scams use lookalike domains or compromised mailboxes rather than direct spoofing, and no MSP should claim otherwise. What a strict DMARC policy does verifiably prevent is a specific technique defined in the standard itself: unauthorized use of the client's exact domain in the From header, which the protocol was designed to address as described in the original DMARC specification, RFC 7489.

That distinction matters for how the pitch is worded. The accurate claim is that DMARC enforcement closes one well-documented spoofing vector and satisfies mailbox provider requirements. It is not a claim that DMARC eliminates phishing risk or replaces the client's broader security posture, and MSPs that overstate it will get caught out the first time a client is hit by a different attack type.

Turning the finding into a proposal

Once the domain-level gaps are identified, the packaging decision determines whether this becomes a one-time project fee or a recurring line item. A one-time DMARC implementation is billable but finite. A monitored, tiered offering that reviews DKIM key rotation, SPF lookup counts, and DMARC aggregate reports on an ongoing basis is a service that renews.

A simple three-tier structure works well for most books of business:

TierScopeTypical fit
BaselineSPF and DKIM setup, DMARC at p=none for monitoringNew or smaller clients
ManagedMove to quarantine, monthly report reviewExisting clients past onboarding
EnforcedFull reject policy, ongoing lookup and vendor auditsClients with compliance or vendor requirements

Scanning the whole client list at once, rather than domain by domain as requests come in, is what turns this into a program instead of a favor. Tools built for this workflow let a technician run the audit across every managed domain in one pass, and the getting-started guide walks through setting that first bulk scan up in a way that produces a client-ready findings list rather than a raw DNS dump. From there, the commercial conversation is a short one, since the MSP is presenting a documented gap and a fix, not speculating about risk.

Pricing this correctly matters too. Underpricing a compliance-driven service signals it is not important, while overpricing it against a genuine mailbox provider deadline gives the client an easy reason to delay. The pricing page lays out how the scan-to-managed-service tiers typically map onto per-domain and per-technician costs, which gives account managers a straightforward answer when a client asks what ongoing monitoring will cost against a one-time fix.

Where to start this week

The fastest path to revenue here is not a new campaign, it is a spreadsheet. Export the full client domain list, run it through a bulk authentication scan, and sort the output by severity, no record, p=none, and SPF over the lookup limit tend to be the three buckets worth acting on first.

From there, the pitch writes itself for each account because the finding is specific to that domain. MSPs that have not yet built this into a recurring motion can get a scanning account running quickly through the sign-up page and have a findings report for the full client list well before the next quarterly business review. The list already being billed is, in most cases, the shortest path to the next dollar of recurring revenue, not the next trade show badge scan.

← Back to all posts