MSP Operations
Stop Selling DMARC as a Project. Sell It as a Line Item.
October 5, 2026
Randy Hall, CEO— AI-assisted and reviewed prior to publication.
There is a specific moment in a lot of MSP sales calls where DMARC gets flattened into a single line on a statement of work: publish three DNS records, bill a flat fee, close the ticket. That framing was always going to age badly, and the last two years of mailbox provider enforcement have made it obsolete. DMARC is not a record you publish once. It is a policy that has to be watched, adjusted, and defended every time a client adds a marketing tool, switches payment processors, or spins up a new SaaS platform that sends mail on their behalf.
The core question for any MSP building a security practice in 2025 and beyond is simple: does DMARC get sold as a fixed-price project or a recurring service line? The honest answer is that treating it as a project misprices the actual work, undersells the ongoing risk, and hands away durable monthly revenue that competitors are already collecting from the same client base.
Why does treating DMARC as a project undersell it?
A one-time DMARC project bills for the setup and stops there, but the setup is the smallest part of the job. Standing up SPF, DKIM, and a DMARC record is a DNS change that takes an afternoon. What actually protects a domain from spoofing is the slow climb from a monitoring-only policy to enforcement, a process governed by RFC 7489, the specification that defines how mail receivers evaluate and report on DMARC policy.
That specification builds in aggregate reporting precisely because domain owners cannot get authentication right on the first try. Every new sending source, from a helpdesk tool to a payroll vendor, has to be identified in those reports and either brought into alignment or blocked. A flat project fee pays for none of that follow-through, which is exactly why so many domains stall at the weakest setting.
The scale of that stall is well documented. EasyDMARC's analysis of roughly 1.8 million domains found that global DMARC adoption climbed from about 27% to 47.7% between 2023 and 2025, but a large share of those domains never moved past the monitoring-only stage, leaving more monitoring-only domains than enforcing ones even after the surge in adoption. A project-based engagement that ends at "record published" is, in practice, an engagement that ends at the least protective setting available.
What changed in 2024 and 2025 to make DMARC non-negotiable?
Google, Yahoo, and Microsoft turned DMARC from a best practice into a delivery requirement for anyone sending meaningful volume. Any MSP still pricing it as an occasional add-on is pricing against a market that has already moved past that assumption.
Google's own guidance is unambiguous: senders who meet bulk sender criteria even once are permanently classified as bulk senders, with no expiration date and no way to opt back out by changing sending habits later. That permanence matters for pricing conversations, because it means the authentication requirement never goes away once a client crosses the threshold, even if their volume later drops.
Microsoft followed the same path a year later. Its Defender for Office 365 team announced that outbound mail from high-volume senders would face rejection if it failed to meet authentication requirements, stating plainly that messages failing to meet the required authentication level would be designated with a specific rejection code rather than simply routed to junk. Between Gmail, Yahoo, and Outlook.com, that covers the inboxes that decide whether a client's invoices, quotes, and password resets land or bounce.
Government has been ahead of the commercial mailbox providers for years. CISA's Binding Operational Directive 18-01, issued in 2017, required federal civilian agencies to configure a DMARC policy and eventually move to full enforcement, and the directive explains that agencies must set a DMARC policy of "reject" for all second-level domains and mail-sending hosts within one year of issuance. That timeline, three months to a basic record and twelve months to enforcement, is a useful reference point for any MSP building a service tier, because it reflects how long the underlying protocol actually needs to be deployed safely.
The line-item math MSPs are leaving on the table
Recurring revenue is already the dominant business model in the channel, which is exactly why DMARC fits so awkwardly into a project quote. Datto's State of the MSP research, drawn from a global survey of more than a thousand providers, frames profitability as a top priority for the coming year while pointing to recurring revenue streams as the mechanism fueling growth across MSPs of every size. DMARC belongs on that recurring list, not on the project side of the ledger, because the work it requires never actually finishes.
The two models produce very different economics over a twelve-month client relationship. A project fee gets collected once and the technician moves on to the next ticket. A line item bills every month for exactly the work the protocol demands: reading aggregate reports, identifying new senders, adjusting policy strength, and re-checking alignment after every DNS or vendor change.
| Billing model | What gets delivered | What happens after month one |
|---|---|---|
| Fixed-fee project | SPF, DKIM, DMARC record at p=none | Nothing, unless the client calls back |
| Monthly line item | Ongoing report analysis, policy graduation, alignment fixes | Continuous monitoring and enforcement progress |
That table is not a hypothetical. It is the difference between a domain that gets a record published and forgotten, and one that actually reaches enforcement. Reaching that guide's setup steps at the start of a client engagement is straightforward, since ActiScan's own getting-started guide walks through exactly the checks a technician runs before ever touching DNS.
Where MSPs still get the pricing model wrong
Even providers who have accepted that DMARC should be recurring often underprice it, because they anchor to the setup work instead of the ongoing labor. A few patterns show up repeatedly across the channel.
- Quoting a single flat rate regardless of domain count, which punishes MSPs managing multi-domain clients and makes scaling the practice unprofitable.
- Treating "monitoring" as a marketing term rather than a billed activity, so the technician time spent parsing aggregate reports never shows up as revenue.
- Failing to separate the DMARC line item from a broader "security bundle," which makes it invisible on the invoice and easy for a client to cut during a renewal negotiation.
None of these mistakes are about technical competence. They are pricing decisions, and they are the reason DMARC often shows up as a loss leader instead of a margin driver even at MSPs that do the deployment work correctly.
How to structure the offer as a real service line
A defensible DMARC line item has three components: initial deployment, policy graduation, and ongoing drift detection. Each of those maps to a distinct piece of recurring work, and each should show up as its own justification for the monthly fee rather than getting bundled into a vague "email security" catch-all.
Per-domain pricing tends to scale better than flat-rate bundles because it mirrors how the underlying risk actually grows. A client with four sending domains generates four times the report volume and four times the alignment work of a client with one, and the invoice should reflect that rather than treating every client as equivalent. ActiScan's own pricing structure follows that per-domain logic for exactly this reason, so the line item scales the same way the underlying workload does.
Getting a practice off the ground does not require rebuilding a sales process from scratch. Most MSPs pilot the line item with one or two existing clients whose domains already show authentication gaps, prove out the reporting cadence, and then extend it across the base once the workflow is repeatable. Providers ready to test that workflow can walk through the platform directly by starting from the sign-up page rather than waiting for a larger rollout plan to materialize.
The bottom line for 2025 pricing conversations
DMARC stopped being optional the moment Google, Yahoo, and Microsoft tied it to inbox delivery, and it stopped being a one-time job the moment any of those providers started reporting on ongoing sender behavior. An MSP that still quotes it as a project is quoting against a model the market has already abandoned. The providers collecting recurring revenue from this work are the ones who priced the ongoing report analysis and policy graduation as what it is: a permanent line item on every domain-owning client's invoice, for as long as that client sends email.