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.

DMARC monitoring is not a commodity, even though it is often sold like one. MSPs that price it as an add-on line item at a flat monthly rate tend to leave money and margin on the table, while those that structure the offer around the actual work of moving a domain from p=none to enforcement build a service that scales with client risk and technician effort alike. The pricing model an MSP chooses says more about the profitability and stickiness of the offer than the number typed into the quote.
What is the core question MSPs actually need to answer about DMARC pricing?
The real question is not "what should I charge," it is "what am I actually selling." DMARC monitoring can be scoped as a one-time DNS project, a recurring per-domain subscription, a per-mailbox add-on, or a bundled security feature, and each choice changes who buys, how long they stay, and how much remediation work gets absorbed for free.
Model One: Per-Domain Flat Monthly Rate
The most common structure treats each protected domain as the billing unit, independent of mailbox count or email volume. Industry pricing benchmarks put ongoing per-domain monitoring and enforcement work in the range of 50 to 200 dollars per domain per month depending on market, with a separate one-time onboarding fee for the initial audit and setup.
This model is intuitive for clients with a handful of domains and predictable for the MSP's own forecasting. It breaks down for clients running dozens of parked or marketing domains, where a flat per-domain fee either overcharges for domains that never send mail or undercharges for the one domain generating hundreds of thousands of aggregate report rows a month.
Model Two: Recurring Subscription Separated From Remediation Work
A growing number of MSPs split the offer into two distinct line items: a monitoring subscription and a separately scoped remediation engagement. The guidance from Suped's DMARC-for-MSPs research is direct on this point, arguing that MSPs should price DMARC monitoring as an ongoing managed service, not as a one-time DNS task, with the monthly fee covering monitoring, investigation, remediation coordination, client reporting, and policy progression.
The remediation half of that split matters because the work is lumpy. Discovery, DNS access, sender inventory, and the first policy decision create a front-loaded workload that a flat recurring fee absorbs poorly, so the recurring fee should cover only the steady-state activity of report review, alert triage, sender change review, and client reporting. This model protects margin on messy clients while keeping the recurring price honest for clean ones.
Model Three: Bundled Into a Broader Security-Inclusive Tier
Some MSPs fold DMARC monitoring into an existing security or compliance bundle rather than selling it as a standalone SKU. This works when the MSP already prices managed services per user or per device and wants email authentication to look like a natural extension of that stack rather than a new negotiation.
The tradeoff is visibility. When DMARC monitoring disappears into a tier, it becomes harder for the client to see the specific value of enforcement work, and harder for the MSP to justify raising the price of that component independent of the whole contract. Broader MSP pricing research from providers like N-able and Huntress documents this tension across managed services generally, noting that bundled per-user or per-device models simplify billing but can obscure the margin contribution of any single feature.
Model Four: Volume-Tiered Platform Pricing
The fourth model prices based on report volume or domain portfolio size rather than a flat per-domain rate, which is how many of the underlying DMARC platforms MSPs resell actually charge. Vendor pricing analysis notes that organizations with larger domain portfolios pay more, but per-domain costs often decrease with volume, and higher email volumes generating more DMARC aggregate reports can increase platform costs. MSPs reselling on top of that structure either pass the tiering through directly or average it into a blended per-domain rate.
This model rewards MSPs who can consolidate many client domains onto one multi-tenant platform, since the marginal cost of the next domain drops as the portfolio grows. It penalizes MSPs who price flat regardless of platform tier, because a single client with heavy inbound volume can quietly erase the margin on ten quiet ones.
Why Does the Model Matter More Than the Rate Itself?
Because the model determines what happens when the work gets hard, not just what the invoice says on a normal month. A flat per-domain rate with no remediation carve-out means the MSP either eats the cost of a messy multi-vendor SPF cleanup or has an awkward renegotiation mid-engagement, and a bundled rate means the client never sees the line item worth defending when budgets tighten.
| Model | Best fit | Main risk |
|---|---|---|
| Flat per-domain | Clients with 1-5 active domains | Overcharges parked domains, undercharges heavy senders |
| Subscription + separate remediation | Clients with legacy mail sprawl or multiple vendors | Requires clear scoping discipline up front |
| Bundled into security tier | Clients already on a managed security contract | Obscures DMARC's specific value and margin |
| Volume-tiered platform pass-through | MSPs with large multi-tenant domain portfolios | Punishes flat pricing on high-volume clients |
The urgency behind all four models is not hypothetical. Since February 2024, Gmail has required senders of 5,000 or more daily messages to set up SPF and DKIM, and to publish a DMARC record for their sending domain, and the federal government set an even earlier precedent when the Department of Homeland Security's Binding Operational Directive 18-01 required all federal executive branch agencies to move to a DMARC policy of p=reject within one year. Those deadlines created the compliance pressure that makes DMARC monitoring sellable, but they say nothing about how an MSP should structure the invoice once the client says yes.
What the Adoption Data Says About Where the Market Actually Is
Most client domains are still not enforcing anything, which is exactly the gap MSPs are paid to close. EasyDMARC's 2025 global adoption research, covering more than 1.8 million domains, found that DMARC adoption rose from 27.3 percent in 2023 to 47.6 percent in 2025, but that over 80 percent of domains still have no DMARC record or use a non-enforcing p=none policy. That gap between publishing a record and actually enforcing one is the entire market for the remediation-heavy pricing models described above.
The underlying protocol has not stood still either. The DMARC specification originally defined in RFC 7489 has been formally obsoleted by new IETF standards track documents, and the current specification spells out that a quarantine or reject policy with the testing flag set will cause the receiver to apply a policy of none to failing messages, or quarantine instead of reject, until the sender confirms the record is working as intended. MSPs pricing monitoring as a static, one-time deliverable are pricing against a protocol that keeps evolving underneath the client's DNS records, which is another argument for a subscription model over a one-time project fee.
Putting a Model Into Practice
None of these four models is universally correct, but the ones that survive contract renewal tend to separate predictable monitoring work from unpredictable remediation work, and they price the domain portfolio realistically rather than assuming every domain behaves the same. MSPs evaluating their own stack can compare tiers directly on the ActiScan pricing page, most of which map cleanly onto the subscription-plus-remediation or volume-tiered approaches described here.
For MSPs building this into a new service line rather than retrofitting an existing one, the getting-started guide walks through the audit-to-enforcement sequence that determines how much setup work a given client actually requires, which is the input every pricing model above depends on. Technicians who want to see how domain scanning maps to that workflow before quoting a client can create an account through the signup page and run the first audit against a live domain.
The rate on the quote is negotiable. The model behind it determines whether the engagement is still profitable eighteen months in, after the easy domains are enforced and the hard ones are the only ones left.