MSP Operations

Four Ways MSPs Are Pricing DMARC Monitoring — And Why the Model Matters More Than the Rate

August 27, 2026

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

Ask five MSPs how they price DMARC monitoring and expect five different answers, quoted in three different units. Some bill per domain, some per client regardless of domain count, some fold it into a per-user security seat, and some tuck it invisibly inside a broader "managed security" line. The rate on the invoice is rarely the part that determines whether the service line is still profitable eighteen months from now.

The core issue is not what an MSP charges for DMARC monitoring today, but which billing unit it chooses. Per-domain pricing scales cleanly with a client's actual footprint but punishes portfolio clients with dozens of subdomains. Flat per-client pricing is easy to invoice but exposes the MSP to margin erosion the moment a client adds domains through a marketing campaign or acquisition. The model, not the rate, decides who eats that cost later.

What are the four common ways MSPs price DMARC monitoring?

The four recurring structures seen across MSP pricing guides and platform documentation are per-domain, flat per-client, per-user or bundled-into-seat, and tiered packages tied to DMARC maturity stage. Each has a clear rationale and a clear failure mode, and most MSPs eventually blend two of them rather than picking one permanently.

Per-domain pricing charges a fixed monthly or annual fee for every domain under monitoring. Its appeal is that cost tracks scope directly: a client with twenty domains pays roughly twenty times as much as a client with one domain, which makes the invoice easy to justify in procurement conversations. The trade-off shows up with portfolio-style clients: a parent brand running many sub-brands feels the cost far more sharply than a single-domain client, even though the operational effort per domain may be similar.

Flat per-client pricing charges one number regardless of domain count. It produces a simpler invoice and folds neatly into existing "managed IT" bundles, but the MSP absorbs all the variability. That works fine until a client adds ten domains through an acquisition, at which point the flat rate that looked generous a year ago is now underwater.

Per-user or per-seat bundling rides on top of pricing the MSP already uses for its broader security stack, where standard managed security packages commonly range from $110 to $175 per user per month, with advanced tiers reaching $175 to $400. Folding DMARC into that number simplifies the client conversation, but the risk is that the service becomes invisible inside a larger package, making it hard to demonstrate specific value or justify a price increase when the client later wants enforcement and BIMI added on top.

Tiered maturity packages map price to where a domain sits on the DMARC journey: monitoring at p=none as the entry point, enforcement work moving the policy toward quarantine and reject as the core revenue driver, and a premium tier covering BIMI, MTA-STS, and forensic reporting. This structure gives MSPs the clearest upsell path because each tier maps directly to a distinct stage of DMARC maturity, and the client understands exactly what triggers the next price increase.

Why does the billing model matter more than the headline rate?

Because the unit an MSP bills against determines who absorbs cost when a client's domain footprint changes, and that change is rarely predictable at the point of sale. A client's newsletter platform spike, a subdomain added for a new product, or an acquired sibling company can shift the underlying workload without warning.

Once volume changes, the billing model can matter more than the headline per-unit price. Two vendors advertising similar per-domain rates can diverge sharply in what a client actually pays once tier thresholds, overage clauses, or bundled minimums come into play.

This is also where DMARC differs from most other recurring line items on an MSP invoice. Unlike a seat count or a ticket volume, a domain portfolio can jump overnight: a client's marketing team spins up a microsite subdomain, a franchise adds three new locations each with a subdomain, or the parent company completes an acquisition and inherits an unmanaged domain that has never had SPF or DKIM configured. Any pricing model anchored purely to domain count needs a rule for that moment, whether it is a minimum engagement threshold, a quarterly true-up, or an automatic tier upgrade the client agreed to in advance.

The compliance backdrop is pushing more clients to ask

Gmail and Yahoo now enforce authentication requirements for anyone sending more than roughly 5,000 messages a day to their users, and Google's own guidance is explicit that this applies to any domain that has crossed that threshold even once, not just self-identified marketers. Google's Email Sender Guidelines FAQ states that Gmail requires senders who send 5,000 or more messages a day to authenticate outgoing email and avoid unwanted or unsolicited content, and that enforcement tightened further starting in November 2025, when non-compliant traffic began experiencing temporary and permanent rejections rather than simple spam-folder routing.

That enforcement timeline is precisely why DMARC monitoring conversations are landing on more MSP desks than they were two years ago. It is not a hypothetical risk anymore. A client's transactional email, invoice reminders, or marketing sends can be rejected outright at the mail server if the domain lacks an aligned DMARC policy, and the underlying mechanics of that policy are defined in the current standards-track specification, RFC 9990, which formally obsoletes the original DMARC document, RFC 7489, as of May 2026.

For MSPs, this compliance pressure is a double-edged sword commercially. It makes the initial sale easier, since the client now has an external deadline rather than an abstract security pitch. But it also means prospects are shopping quotes more aggressively, comparing per-domain rates across vendors without necessarily understanding what happens to that rate once their domain count changes. A client evaluating a proposal is often comparing low-cost entry-level plans against enterprise contracts, with little visibility into which tier they will actually land in a year from now.

A simple framework for comparing the four models

The table below summarizes where each model tends to hold up and where it tends to break, based on the patterns MSP pricing guides consistently describe.

Most experienced MSPs do not pick one model in isolation. A common pattern is per-domain pricing for smaller, self-serve clients and flat per-client or tiered pricing for larger enterprise accounts, with a defined conversion point between the two as a client's footprint grows. Vendor pricing structures reflect the same split: some platforms hold a strict per-domain fee with volume discounts as the portfolio grows, while others offer flat-rate tiers specifically aimed at improving unit economics for MSPs managing hundreds of client domains.

Building the model before quoting the rate

Whichever structure an MSP chooses, the operational scope should be settled before the price is. A workable package needs to define what triggers a change in what the client is billed: a new domain, a new subdomain used for a fresh sender, a policy change from none to quarantine to reject. Pricing anchored to protected domains and operational load, with setup billed separately from the ongoing monthly fee, tends to hold up better under scrutiny than pricing that tries to capture everything in one number.

It also helps to decide upfront how forensic and aggregate reporting factor into the invoice, since the reporting mechanics themselves are what the domain owner is actually paying to have monitored. The aggregate report format that MSPs rely on for visibility into SPF, DKIM, and alignment failures is standardized so that domain owners can request aggregate reports from receivers, per the current specification. That report is what turns a policy from a guess into a monitored, evidence-backed control, and it is the recurring deliverable that justifies charging monthly rather than treating DMARC as a one-time DNS task.

For MSPs building or refining this service line, starting with a clean domain inventory makes the pricing conversation far easier, since the number of domains, subdomains, and third-party senders drives almost every model above. ActiScan's getting-started guide walks through that discovery step before any policy or pricing decision is made. Once the scope is clear, MSPs can model per-domain, flat, and tiered scenarios against their own delivery costs using the rate card on the pricing page, and new partners can set up a workspace directly through signup to start scanning client domains before quoting a single contract.

The rate an MSP puts on a proposal will always be negotiable. The billing model behind it, and whether it survives the client's next acquisition, product launch, or marketing campaign, is the part worth getting right the first time.