MSP Operations
Why DMARC Monitoring Deserves Its Own Line on the Invoice
October 9, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.
Every MSP has a client who assumes DMARC is already handled because "email security is part of the package." That assumption is usually wrong, and it is expensive in ways that rarely show up until a domain gets spoofed or Gmail starts rejecting mail. The instinct to fold DMARC monitoring into an existing managed-services or email-security contract feels generous. It is also the single fastest way to make a labor-intensive, ongoing discipline look like a free feature nobody has to pay for again.
The core issue is simple: DMARC monitoring should be billed as a distinct, recurring line item because it is distinct, recurring work. Reading aggregate reports, chasing down unauthorized senders, coordinating SPF and DKIM fixes with third-party vendors, and nudging a client from p=none toward p=reject is ongoing analyst labor, not a one-time DNS edit buried inside a flat-fee contract.
Isn't DMARC Monitoring Just Part of Email Security Already?
No, and conflating the two is where most of the pricing trouble starts. Email security products filter inbound threats hitting a client's inbox, while DMARC governs outbound trust: whether mail claiming to be from the client's domain actually came from an authorized source. They solve different problems, run on different timelines, and require different ongoing attention.
DMARC, as defined in RFC 7489, is a DNS-published policy mechanism that tells receiving mail servers what to do with messages that fail SPF or DKIM checks, and it asks those receivers to send back aggregate reports documenting what happened. Those reports arrive daily, in machine-readable XML, from every major mailbox provider that sees the domain's traffic. Someone has to actually read them, correlate the source IPs against known senders, and decide whether a failure means a marketing tool needs an SPF update or a phishing campaign is spoofing the brand. That is a recurring operational task with its own labor curve, separate from whatever spam-filtering or threat-detection product a client already pays for.
What Gets Lost When DMARC Rides Along for Free
Bundling DMARC into an existing contract buries the work where nobody can see it, including the technician doing it. When DMARC is simply absorbed into a flat managed-IT or security retainer, clients have no reason to believe the service exists at all, because nothing on the invoice tells them it does.
This creates two separate problems. First, the MSP eats the labor cost of monitoring, triage, and policy progression without a corresponding revenue line, which makes the work the first thing cut when margins get tight. Second, and more damaging long-term, the client never develops a mental model of DMARC as a service with value, which makes it nearly impossible to sell deeper enforcement work, brand protection add-ons, or incident response later.
A few consequences tend to follow a bundled approach:
- Technicians treat DMARC reports as a background chore instead of a tracked deliverable, so domains stall at p=none indefinitely.
- Clients assume the work is "already covered," so there is no urgency when a vendor needs to update its SPF record.
- Renewal conversations never surface DMARC as a reason the contract has value, so the service is the first casualty of a price negotiation.
How Should MSPs Price DMARC Monitoring Separately?
The cleanest approach splits one-time setup from recurring monitoring and prices each on its own. Setup covers sender discovery, SPF and DKIM cleanup, and the initial policy plan. The monthly fee covers ongoing report review, remediation coordination, and the gradual move toward enforcement, and it should appear on the invoice as its own line so the client sees exactly what they are buying every month.
| Pricing component | What it covers | Billing cadence |
|---|---|---|
| Onboarding and audit | Sender inventory, SPF/DKIM cleanup, initial DMARC record | One-time project fee |
| Monthly monitoring | Aggregate report review, alerting, remediation coordination | Recurring per domain or per client |
| Enforcement progression | Moving from p=none to p=quarantine to p=reject | Included in monitoring or milestone-based |
Per-domain pricing scales more predictably than a flat per-client fee once a client has more than a handful of domains, since report volume and remediation effort track domain count rather than headcount. MSPs weighing their own numbers can model both approaches against a published rate card, and a platform's pricing page is a reasonable starting point for benchmarking what the underlying tooling costs before marking it up for labor and margin.
The Compliance Clock Is Forcing This Conversation Anyway
Clients are no longer asking whether DMARC matters, they are asking why their mail stopped delivering. Google's own guidance requires bulk senders, meaning anyone sending 5,000 or more messages a day to Gmail addresses, to publish a valid DMARC record and pass SPF and DKIM alignment, and Google has said plainly that messages failing to meet these requirements can be marked as spam or rejected outright, as described in Google's email sender guidelines. That is not a recommendation anymore for a meaningful share of client traffic, it is a delivery gate.
The federal government went further nearly a decade ago. CISA's Binding Operational Directive 18-01 required federal agencies to publish a DMARC policy and set it to p=reject within a year, stating outright that a reject policy provides the strongest protection against spoofed email by ensuring unauthenticated messages are rejected before delivery, according to CISA's own directive page. That mandate became the template regulators and large enterprise customers now point to when they ask vendors and contractors for proof of DMARC enforcement.
The enforcement gap between organizations that treat DMARC as an ongoing service and those that set a record once and walk away is well documented. EasyDMARC's 2026 adoption analysis, which examined DMARC records across roughly 1.8 million domains plus the Fortune 500 and Inc. 5000, found that global valid DMARC adoption grew from 523,921 domains in 2023 to 937,931 in early 2026, yet more than half of Inc. 5000 companies with a DMARC record remain stuck at the do-nothing p=none policy, per the EasyDMARC adoption report. Fortune 500 companies, by contrast, reached enforcement-level policies at a far higher rate, which tracks almost exactly with which organizations treat DMARC as something that gets staffed and paid for rather than configured once and forgotten.
That gap is the sales argument. A client stuck at p=none is not protected, they are just generating data nobody is reading. Industry pricing analyses of MSP DMARC offerings have flagged bundling as a specific pitfall, noting that folding the service into a broader managed-IT line makes the value invisible because clients cannot understand why a standalone DMARC fee would be charged when they already pay thousands for managed services, a dynamic that one MSP-focused pricing breakdown argues is best solved by treating DMARC as a separate line item with its own sale and its own value perception.
Making the Line Item Easy to Sell
A separate line item does not need a separate sales process to be effective. The pitch is straightforward: a flat monthly fee buys ongoing report analysis, vendor coordination, and measurable progress toward a reject policy, framed against the real cost of a spoofed invoice email reaching a client's customers. Framing the service around enforcement progress, not just "monitoring," gives the client a visible milestone to pay for.
For MSPs building this out for the first time, walking a pilot client through onboarding end to end is the fastest way to find the real labor cost before setting a price. A structured getting-started guide can shorten that first engagement considerably, and testing the workflow on a live account through a signup is a low-risk way to see what the recurring monitoring work actually involves before quoting it to the rest of the client base. Once that baseline exists, pricing DMARC as its own service stops being a guess and starts being a number backed by real hours.
Charging separately is not about squeezing more revenue out of existing clients for its own sake. It is about making a genuinely recurring body of work visible, on the invoice and in the client's head, so that it keeps getting done after the first quarter's enthusiasm fades.