MSP Operations
Stop Quoting DMARC as a Project. Sell It as a Line Item.
September 10, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.
A DMARC record takes about fifteen minutes to publish. Getting a client's domain to a safely enforced p=reject policy without breaking legitimate mail takes months of reading aggregate reports, chasing down forgotten senders, and adjusting SPF and DKIM alignment one vendor at a time. MSPs that quote the fifteen minutes and walk away are leaving the months, and the revenue that comes with them, on the table.
That is the core problem with treating DMARC as a project: the invoice closes right when the client's exposure is at its highest. A domain sitting at p=none is publishing a policy that, according to the protocol's own specification, requests no enforcement action from receivers at all. It is visibility without protection, and it is exactly where most flat-fee DMARC engagements stop.
The direct answer: DMARC should be sold as a recurring managed line item, not a one-time project, because the record itself does nothing without ongoing report analysis, sender reconciliation, and policy tightening. A project fee pays for publishing a DNS entry. A monthly line item pays for the work that actually moves a domain from monitoring to enforcement and keeps it there.
Why does flat-fee DMARC pricing leave money and security on the table?
A flat fee treats DMARC like a firewall rule change: configure once, invoice once, move on. But DMARC was designed as an iterative process. The IETF's own specification describes a mechanism where domain owners publish policy and use receiver-generated feedback to refine it over time, not a static setting applied once and forgotten.
That feedback loop is the entire point. Aggregate reports arrive daily, in XML, from every major receiver a domain touches. Someone has to parse them, identify legitimate senders that are failing alignment, and decide when it is safe to move from p=none to p=quarantine to p=reject. Skip that work and the domain either stays wide open or gets pushed to enforcement too fast and starts silently dropping the CEO's newsletter platform or the HR system's onboarding emails.
MSPs who sell the DNS record as the deliverable are selling the least valuable part of the engagement. The valuable part, the part that justifies a monthly invoice, is the analyst work that happens after.
What does a DMARC managed line item actually include?
It includes continuous aggregate report ingestion, sender discovery, alignment troubleshooting, and staged policy advancement, not just an initial record. Below is a simple way to frame the stages for a client who has never seen a DMARC roadmap before.
| Stage | Policy | What the client is paying for |
|---|---|---|
| Visibility | p=none | Report collection, sender inventory, false-positive triage |
| Partial enforcement | p=quarantine | Alignment fixes, percentage rollout (pct=), spam-folder monitoring |
| Full enforcement | p=reject | Ongoing drift detection, subdomain policy, ARC handling for forwarders |
This table maps almost directly onto the deployment checklist that DMARC.org's own community publishes, which treats DMARC deployment as a coordination exercise across departments rather than a single DNS change. The stages don't end at reject, either. Domains keep sending new SaaS tools, marketing platforms, and helpdesk systems online, and each one needs to be authenticated or it becomes a new gap in the same fence.
Framed this way, the line item sells itself on its own logic. Nobody expects a firewall subscription to stop after the appliance ships. DMARC monitoring deserves the same expectation.
How the compliance landscape changed the sales pitch
Regulatory and platform mandates have quietly turned DMARC from a security nicety into a delivery requirement, which gives MSPs a harder deadline to sell against than "best practice" ever did. Google's email sender guidelines require that any domain sending close to 5,000 or more messages a day to Gmail addresses have SPF or DKIM in place, with the bulk-sender tier requiring full DMARC alignment. Yahoo's Sender Hub carries the equivalent requirement and explicitly tells senders that publishing a DMARC policy is the mechanism receivers rely on to enforce it.
On the public sector side, CISA's Binding Operational Directive 18-01 gave federal agencies a fixed timeline: a p=none policy within 90 days and full p=reject enforcement within one year, a schedule that has since become the reference model many MSPs use when setting client milestones. NIST's SP 800-177 guidance goes further, treating SPF, DKIM, and DMARC together as the baseline technology stack for trustworthy email, not optional hardening.
None of these mandates enforce themselves in a client's mailbox. Someone still has to read the reports, fix the misconfigured marketing platform, and advance the policy without breaking delivery. That recurring labor is the product.
The adoption numbers back up the urgency. EasyDMARC's 2026 DMARC Adoption Report found that global adoption among tracked domains reached 52.1 percent this year, up from 47.7 percent in 2025, with enforcement policies climbing alongside it. Half the domains an MSP might quote a project against are still unprotected, and the ones that have moved are the ones already generating recurring reporting revenue for somebody else's book of business.
Structuring the line item without underpricing the work
A workable line item bundles a few things a client actually needs every month, not just the record itself:
- Daily or weekly aggregate report review with a plain-language summary, not a raw XML dump
- Sender reconciliation whenever a new marketing tool, help desk, or CRM starts sending mail
- Staged policy changes with a documented rollback plan
- Quarterly review of subdomain policy, BIMI eligibility, and forwarding-related ARC issues
Pricing conversations get easier once the deliverable list is concrete. A client comparing "$400 to publish a DNS record" against "monthly monitoring and enforcement management" understands immediately which one protects them in month thirteen. ActiScan's own pricing page is built around that same per-domain, recurring logic rather than a flat implementation charge, because the report-reading and sender-chasing work doesn't stop once enforcement is reached.
For MSPs building this into a new service line, the operational sequence matters as much as the pricing model. The getting-started guide walks through the discovery and report-collection phase that has to happen before any policy tightening is safe, which is the same sequence a technical buyer will expect to see in a proposal. Skipping straight to a reject policy without that groundwork is how MSPs create the support tickets that erode the very trust they're trying to sell.
Turning the pitch into a line on the invoice
None of this requires reinventing the sales conversation from scratch. It requires renaming what is already being sold. A DMARC project quote becomes a "domain authentication management" line item, billed monthly, scoped around report review and staged enforcement rather than a single record push. That framing also survives contract renewal conversations better, since the client is renewing a service relationship instead of being asked to pay again for something they believe was already finished.
The MSPs already doing this are not inventing new technical work. They are pricing the work that was always there, the part that happens after the DNS record propagates, and that most flat-fee quotes quietly skip. Given how directly Google, Yahoo, and federal procurement rules now tie deliverability and compliance to an actively managed DMARC policy, that recurring work has a natural home on a services agreement rather than a one-time invoice.
Setting up the account structure to track this per domain, per client, is the first mechanical step. MSPs ready to move can sign up and start building the recurring line item around real report data instead of a one-time record push.