ActiScan

MSP Operations

How to Price DMARC Monitoring So It Actually Grows With Your Client Base

October 1, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

Brass balance scale weighing coins against a set of keys, symbolizing pricing scaled to complexity.

DMARC has moved from a niche recommendation to a near-mandatory line item on every MSP's security stack. Since February 2024, Google and Yahoo have required any domain sending 5,000 or more messages a day to publish a DMARC record, and Google's own guidance confirms that bulk senders must align either SPF or DKIM under the policy to keep mail out of the spam folder. That single requirement turned DMARC from a "nice to have" audit item into recurring work almost every client now needs, which is exactly why pricing it correctly matters more than it did three years ago.

So how should an MSP price DMARC monitoring so revenue scales with the client base instead of eroding as domains multiply? The short answer: separate the one-time setup from the recurring monitoring fee, tier the recurring fee by sender complexity rather than a flat per-client rate, and build in minimums that stop single-domain accounts from becoming a loss leader.

What Is Actually Driving Client Demand for DMARC Right Now?

Demand is being pulled by mailbox providers, not pushed by MSPs. EasyDMARC's 2026 adoption report found that global DMARC adoption reached 52.1% of the 1.8 million domains tracked, up from 47.7% the prior year, with enforcement policies climbing alongside it. Red Sift's global tracking tells a more sobering version of the same story: across a much larger sample of 73.3 million domains, only 14.9% have implemented even a basic DMARC policy, and just 2.5% enforce p=reject.

That gap between "some large companies are ahead" and "most domains have nothing" is where MSP revenue lives. Every client who sends marketing email, invoices, or notifications through a third-party platform is a candidate for the Google and Yahoo bulk sender rules, and most of them have never looked at a DMARC aggregate report in their life. That unmet demand is the justification for pricing DMARC as a distinct, defensible line item rather than folding it invisibly into a security bundle.

Why Flat, Per-Client Pricing Breaks Down as the Book Grows

A flat monthly fee per client feels simple to sell, but it ignores that DMARC workload does not scale linearly with client count. A single-domain client with two approved senders requires a fraction of the analyst time that a client running five brands, a marketing platform, a help desk tool, and three regional subdomains requires. Suped's guidance to MSPs is blunt about this mismatch, arguing that a client with one domain and two approved senders is not the same service as a client with many brands and shared DNS ownership, and that fixed public prices tend to break down once sender count and DNS access start to vary.

The practical failure mode looks like this: an MSP prices DMARC monitoring at $75 a month flat, wins ten easy clients, then signs an enterprise account with fourteen sending sources and a legacy marketing platform that keeps breaking SPF alignment. The flat fee now covers roughly a tenth of the actual analyst time that account consumes. Margin on the whole DMARC line collapses precisely when the book looks like it is growing.

How Should Tiers Be Structured So Revenue Tracks Complexity?

The fix is tiering by DMARC maturity stage and sender complexity instead of by client logo. Red Sift's guide to packaging DMARC services for MSPs recommends a structure that follows the DMARC journey itself: an entry-level monitoring tier at p=none, an enforcement tier that carries the bulk of ongoing work as clients move to p=reject, and a premium tier covering BIMI, MTA-STS, and forensic reporting. Each tier maps to a distinct amount of analyst time, which means each tier can carry a distinct price without the MSP having to negotiate every account from scratch.

A simplified version of that structure looks like this:

TierWhat it coversBilling logic
MonitoringAggregate report collection, sender inventory, p=none baselineEntry price per domain, low touch
EnforcementSPF/DKIM cleanup, phased move to quarantine/reject, vendor coordinationCore recurring fee, scales with sender count
PremiumBIMI, MTA-STS, TLS-RPT, forensic detail, compliance reportingAdd-on priced per feature or per domain

This mirrors the three-stage revenue model that industry guidance describes for DMARC services, where onboarding is billed once, monitoring and enforcement carry the recurring fee, and add-ons like MTA-STS or BIMI become the expansion path once a client reaches p=reject. Tools that make this tiering practical, including ActiScan's own pricing structure, are built around per-domain billing precisely so an MSP is not stuck renegotiating a platform contract every time it adds a client with an unusually complex sending environment.

Bundling, Minimums, and the Multi-Domain Trap

Bundling DMARC into a flat per-user managed security rate is tempting because it simplifies the client conversation, but it carries a real cost. Red Sift's own packaging guidance warns that folding DMARC into an existing per-user rate risks making the service invisible inside a larger package, which makes it harder to demonstrate specific value or justify price increases when enforcement work is added later. An MSP that cannot point to a line item struggles to explain why the bill goes up when a client's marketing team adds a fourth email platform.

Minimum engagement thresholds solve the opposite problem: the single-domain client who wants DMARC for compliance reasons but generates almost no analyst work. Rather than pricing that account into a loss, most guidance for MSPs recommends either a modest fixed minimum per domain or bundling single-domain DMARC into a broader security package instead of selling it standalone. A short list of what the recurring fee should always cover, regardless of tier, keeps that conversation honest:

  • Ongoing collection and review of DMARC aggregate reports
  • Identification of unauthorized or unknown sending sources
  • Coordination with the client's third-party vendors on SPF and DKIM alignment
  • Progression planning from p=none toward p=quarantine and eventually p=reject
  • Client-facing reporting that shows what changed and why

That list is also the practical definition of what "monitoring" means under the DMARC specification. The protocol itself, most recently restated in RFC 9990, exists specifically so that domain owners can request aggregate reports from receivers, and the value an MSP adds is turning that raw XML into decisions a client can act on.

Getting the Onboarding Math Right

The setup fee deserves as much rigor as the recurring fee, because underpricing onboarding is where DMARC projects quietly go unprofitable. Onboarding should cover discovery of every sending source, the initial DNS changes, SPF and DKIM cleanup, and the first policy plan, all before the first invoice for ongoing monitoring goes out. Underestimating that phase is the single most common reason MSPs report thin margins on their first few DMARC clients, because the discovery work for a client with several undocumented marketing tools takes far longer than the DNS record change itself.

Getting this sequencing right matters enough that it is worth walking new team members through a structured process rather than improvising it account by account. A documented onboarding flow, such as the one in ActiScan's getting-started guide, turns a variable, hard-to-scope task into a repeatable checklist that a junior analyst can run without senior oversight on every account. That repeatability is what actually lets pricing scale, since the fee only holds up if the labor behind it is predictable.

Pricing for the Book You Will Have, Not the One You Have Today

The MSPs who get DMARC pricing wrong are usually the ones who priced for their first five clients and never revisited the model. A tiered structure that separates onboarding from monitoring, prices monitoring by sender complexity rather than by client count, and treats BIMI, MTA-STS, and forensic reporting as genuine upsells rather than freebies will hold its margin whether the book has ten domains or three hundred. Reviewing that structure against actual account data every couple of quarters, rather than assuming the original rate card still fits, is what keeps DMARC a profitable line of business instead of a courtesy service buried inside a bigger contract.

For MSPs building this out for the first time, starting with a platform that bills per protected domain rather than per seat makes the tiering math above far easier to hold to. Reviewing the current plan structure on the signup page is a reasonable next step before quoting the next prospect, since the pricing model chosen at the platform level tends to shape every client contract built on top of it.

Further Reading

← Back to all posts
Pricing DMARC Monitoring That Scales With Your MSP — ActiScan Blog