MSP Operations
How to Actually Price DMARC Monitoring So MSPs Don't Race to the Bottom
September 14, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.
Every MSP that has quoted DMARC monitoring against a competitor has felt the pull toward a flat, forgettable number: five dollars a domain, bundled free with a security stack, thrown in to win the deal. That instinct is understandable and it is also how a genuinely valuable service line turns into a line item nobody defends at renewal.
The short answer to how DMARC monitoring should be priced is this: charge for the operational work, not the DNS record. A domain with one email source and a client that already wants enforcement takes an hour. A domain with fourteen shadow IT senders, no DKIM on half of them, and a compliance officer asking about audit evidence takes weeks. Price the labor curve, not the acronym.
Why Is DMARC Monitoring So Easy to Underprice?
DMARC monitoring gets underpriced because the visible deliverable, a DNS TXT record, looks identical whether it took ten minutes or ten weeks to get right. The record itself is trivial to publish. The work that makes it safe to enforce is not, and that work is invisible on a proposal unless the MSP itemizes it.
The record only has three real states, and each one implies a different amount of ongoing labor. As defined in RFC 7489, a domain owner can request no action, quarantine of failing mail, or outright rejection, and the specification is explicit that these are progressively stricter enforcement instructions to receiving mail servers. Getting from the first state to the third is the actual product. The record is just the receipt.
Selling the receipt instead of the work is exactly how DMARC monitoring becomes a race to the bottom: two MSPs compete on the price of publishing a record, and the one who skips the sender discovery, the SPF cleanup, and the phased rollout wins the quote and loses the client the first time a legitimate vendor's email starts bouncing.
What Should MSPs Actually Charge For?
MSPs should charge for four separable phases of work: discovery and setup, active monitoring and reporting, remediation when something breaks, and the policy progression toward enforcement. Bundling all four into one flat number is what makes the fee arbitrary, and unbundling them is what makes it defensible in a renewal conversation.
Industry guidance on DMARC service design increasingly separates monitoring from remediation as distinct commercial motions, precisely because they carry different risk, labor, and approval requirements. One framework built for MSPs treats the monitoring subscription as the recurring layer covering collection, alerting, and source review, with a separate, scoped remediation work order whenever the fix requires DNS, sender configuration, or routing changes. That separation matters because a client with a single, well-behaved mail source and a client running six marketing platforms and two abandoned CRM integrations are not buying the same service, even though both are technically "on DMARC."
A practical way to structure the fee is against the phase the domain is actually in, not a flat per-domain rate:
| Phase | What the work involves | Typical billing pattern |
|---|---|---|
| Discovery and setup | Sender inventory, SPF/DKIM audit, initial p=none record | One-time or bundled setup fee |
| Monitoring | Aggregate report review, alerting, monthly client reporting | Recurring subscription |
| Remediation | Fixing broken senders, DNS changes, vendor coordination | Scoped project or hourly work order |
| Enforcement progression | Staged move to quarantine then reject, ongoing tuning | Recurring, often at a higher tier |
This structure also gives MSPs a natural upsell path instead of a single take-it-or-leave-it price, and it mirrors how the broader managed services market already prices differentiated tiers rather than flat per-seat fees.
How Enforcement Deadlines Changed the Pricing Conversation
The pricing conversation shifted meaningfully once large mailbox providers stopped treating DMARC as optional guidance and started enforcing it as a delivery requirement. That change gives MSPs a harder deadline to sell against, which is worth pricing differently than a discretionary security improvement.
Google's own guidance states plainly that starting in November 2025, Gmail began ramping up enforcement on non-compliant traffic, and messages failing the requirements now face temporary and permanent rejections. The underlying requirement, in force since February 2024, is that any sender pushing more than 5,000 messages a day to Gmail accounts must meet specific authentication and unsubscribe requirements or risk exactly that throttling. Yahoo moved on a comparable timeline. That is no longer a best-practice recommendation an MSP can quote casually. It is a compliance clock, and clients with marketing platforms, ticketing systems, or CRM tools sending on their behalf are exposed the moment they cross that volume threshold.
That urgency is also why enforcement rates lag adoption rates so badly. EasyDMARC's 2026 adoption analysis of 1.8 million domains found adoption climbing to roughly 52% of top domains, up from 47.7% the year before, while enforcement growth trails behind publication growth by a wide margin. Fortune 500 companies, by contrast, have reached 95% adoption with over 80% already at enforcement, according to the same analysis, which tells MSPs exactly where the market gap and the revenue opportunity sit: mid-market and SMB clients that published a record years ago and never moved past monitor-only.
That gap is precisely the service line worth pricing on its own line item rather than folding into a generic security bundle, since it is the part of the work most likely to generate a support ticket when a client's invoicing platform suddenly starts landing in spam.
Why Flat Per-Domain Pricing Breaks Down at Scale
Flat per-domain pricing breaks down because the workload driving DMARC monitoring scales with the number and complexity of sending sources behind a domain, not with the number of domains an MSP manages. A client with three domains and one mail platform is cheaper to protect than a client with one domain and nine shadow-IT senders.
This is why some DMARC-focused platforms explicitly recommend against publishing a fixed public price at all, instead billing to the scope of the sender estate, client urgency, and DNS access involved in each engagement. A separate MSP-facing guide reaches a similar conclusion, noting that the broader per-user pricing common across managed services does not map cleanly onto DMARC because the unit of work is the domain and its senders, not the headcount behind it.
In practice, that means an MSP quoting DMARC monitoring should ask about sender count and DNS access before quoting a number, the same way a project-based engagement would scope hours before quoting a fixed bid. Tooling that automates aggregate-report parsing and sender identification, the kind built into a platform like ActiScan, reduces the labor per domain, but it does not eliminate the underlying variability, and pricing should reflect that the tool shortens the work rather than removes it.
Building the Offer Without Racing Anyone
None of this requires reinventing an MSP's existing service catalog. It requires treating DMARC monitoring as a named, scoped service line with its own setup fee, its own recurring rate, and its own remediation terms, the same discipline already applied to patch management or backup monitoring.
A workable rollout looks like this in practice:
- Quote setup separately from monitoring, and size the setup fee to the sender audit, not the DNS change itself.
- Price the recurring monitoring fee against enforcement stage, since a p=reject domain under active tuning carries more ongoing labor than a stable p=none domain.
- Keep remediation as a scoped, billable work order whenever a broken sender needs fixing rather than folding unlimited fixes into the base fee.
MSPs evaluating a platform to support this can walk through domain setup on ActiScan's getting-started guide to see how much of the discovery and reporting work is automatable before quoting a client, compare tier structures on the pricing page to model recurring fees against the phases above, and open a signup to test the workflow against a real client domain before committing to a rate card. The goal is not to find the lowest number that wins the next quote. It is to find the number that survives the renewal conversation once the client asks what, exactly, they have been paying for.