MSP Operations
The Hidden Margin Trap in DMARC Enforcement Deals
October 7, 2026
Randy Hall, CEO— AI-assisted and reviewed prior to publication.
A client signs a tidy monthly retainer for "DMARC management." Six months later the domain is still sitting at p=none, a new SaaS billing platform has broken alignment twice, and the technician assigned to the account has logged more hours than three other clients combined. Nobody renegotiated the price. This is the margin trap, and it is built into how most DMARC deals get sold in the first place.
What is the hidden margin trap in DMARC enforcement deals?
The trap is a mismatch between how DMARC work is priced and how it actually gets done. Most contracts are sold as flat, low monthly fees that assume DMARC deployment is a quick technical task, when the real work of reaching enforcement is a sustained, unpredictable labor commitment that can run for the better part of a year. The gap between the fee and the effort is where margin quietly disappears.
That mismatch is not a rounding error. According to a 2024 report cited by DMARC Report, only 28.5% of domains with a published DMARC record have actually reached p=reject enforcement, which means most deployments stall somewhere in the monitoring or quarantine phase, exactly the phase that demands the most ongoing labor from the MSP and produces the least visible progress for the client.
Why the timeline breaks the pricing model
DMARC pricing models are frequently built around an implicit assumption that enforcement is a project with a defined end date. The actual timeline tells a different story. A small business with one domain and a few sending sources can realistically reach p=reject in nine to twelve months, and organizations with multiple domains and complex forwarding rules typically need twelve to eighteen months, according to DMARC Report's phase-by-phase enforcement roadmap.
MSPs rolling this out across a client base face a multiplied version of the same problem, since each client's sender inventory, DNS access, and internal approval process differs. A flat fee priced to look competitive against a "managed IT" line item rarely accounts for eighteen months of report parsing, sender chasing, and DNS troubleshooting per domain.
The technical side compounds this. SPF records are capped at ten DNS-querying mechanisms under RFC 7208, a limit that exists to prevent DNS amplification but that most organizations blow past the moment they add a fourth or fifth cloud sending service. Every time a client adopts a new marketing platform, CRM, or ticketing tool, the SPF record risks breaking, DKIM alignment has to be re-verified, and the DMARC policy has to be reconsidered before it can safely move a stage forward. That work is real, it is billable in theory, and it is almost never scoped separately in the original deal.
Where the labor actually goes
The core structural problem, as MSP-focused pricing guidance from Suped lays out clearly, is that monitoring and remediation are fundamentally different kinds of work being sold under one line item. Monitoring is recurring and predictable. Remediation is project work triggered by DNS changes, new senders, or mail routing changes, and it carries different risk and approval requirements, a distinction that gets lost the moment both are bundled into one flat number.
The practical consequence is that a client who adds a new sending platform expects the MSP to "just handle it" as part of the existing monthly fee, because the invoice never separated the two. Suped's guidance on reducing labor cost in DMARC management makes the point that a managed service scope has to explicitly prevent project work from leaking into recurring support, or the recurring queue absorbs unbounded effort at a fixed price.
A short table makes the mismatch concrete:
| Work type | Nature | Typical pricing treatment | Margin risk |
|---|---|---|---|
| Aggregate report monitoring | Recurring, predictable | Bundled into flat fee | Low |
| New sender onboarding | Ad hoc, frequent | Often bundled | High |
| SPF/DKIM remediation after a break | Project, urgent | Rarely itemized | High |
| Policy stage advancement (none to quarantine to reject) | One-time per stage, high judgment | Assumed included | Very high |
Why bundling feels safer than it is
Bundling remediation into a flat monthly fee looks simpler on a proposal and easier to sell alongside a broader managed-IT package. The problem surfaces months later, when the client has added three new senders, the MSP has absorbed dozens of unplanned hours, and there is no natural point in the relationship to renegotiate scope without an awkward conversation about money.
A simple illustration puts a number on this failure mode: if an MSP charges $100 per domain per month and the underlying platform license costs $50, the actual gross margin is 50% before a single hour of labor, far less than the invoice suggests once platform pass-through costs are counted. Add unbilled remediation hours on top of that and the real margin can go negative on accounts that looked profitable at signing.
Redsift's guidance for MSPs pricing DMARC services makes a related point about why the domain, not the user seat, has to be the pricing unit in the first place, since DMARC workload scales with domain and sender complexity rather than headcount. Treating a ten-domain client the same as a one-domain client at the same flat rate is the same error in a different shape.
What actually holds enforcement back
The technical driver behind most of the surprise labor is shadow senders. Every marketing tool, HR platform, or invoicing service a client's staff signs up for independently becomes another authenticated sender the MSP has to discover, verify, and align before policy can safely advance. This is precisely why Google's own sender guidelines now require domains sending significant volume to Gmail to maintain SPF or DKIM authentication and keep spam rates under 0.3% as tracked in Postmaster Tools, a bar that keeps moving as a client's sending footprint grows.
Two structural fixes recur across the pricing guidance reviewed for this piece:
- Separate the commercial motion for monitoring from the commercial motion for remediation, so that DNS changes, new sender onboarding, and policy stage advancement are quoted as distinct work rather than absorbed silently.
- Price setup and discovery as a front-loaded, one-time engagement, since domain discovery, sender inventory, and initial SPF and DKIM cleanup create disproportionate early workload that a flat monthly number cannot recover.
Neither of these fixes requires abandoning flat-fee pricing entirely. They require drawing the boundary in the contract before the first sender break happens, not after the fifth one.
Building a pricing model that survives the real timeline
An MSP evaluating its own DMARC book should ask a blunt question: does the current pricing survive a client that takes the full eighteen months and adds five new senders along the way? If the answer requires hoping the client stays simple, the fee is undercosted.
A more durable structure separates a recurring monitoring subscription, an onboarding or discovery fee sized to the actual sender-inventory work, and clearly scoped remediation work orders for anything that touches DNS, mail routing, or a new platform. Suped's remediation-pricing guidance frames the dividing line simply: price remediation separately from monitoring whenever the work changes DNS, sender configuration, mail routing, client processes, or third-party platform settings.
Getting the underlying visibility right is the precondition for any of this pricing discipline to work, since an MSP cannot scope remediation it cannot see coming. Tools that surface sender inventory changes and alignment breaks as they happen, rather than at the next scheduled report review, give account teams the lead time to flag scope changes to clients before the hours are already sunk. ActiScan's own approach to this starts with the kind of domain visibility outlined in its getting-started guide, which walks through discovering active senders before a policy change goes live rather than after a delivery incident forces the issue.
None of this is a promise that better tooling or better contracts eliminate the labor DMARC enforcement requires. The standard itself, defined in RFC 7489, was built around a gradual rollout mechanism for exactly this reason, since the "pct" tag exists specifically to let domain owners phase enforcement in slowly rather than flip a switch. The work is inherent to the protocol, not a symptom of a bad vendor. What MSPs control is whether the contract reflects that reality or quietly assumes it away.
Firms rebuilding their DMARC pricing around this reality typically start by auditing where existing client engagements sit against the true enforcement timeline, then rebuild rate cards around the monitoring-versus-remediation split before the next renewal cycle. Reviewing plan structures on the pricing page or moving a test domain through signup to see how sender discovery surfaces in practice are reasonable next steps for a team that suspects its own DMARC book has the same gap.
The margin trap is not a pricing mistake so much as a timing mistake: it prices DMARC as a project when the standard itself, and the data on how long real deployments take, both say it is closer to a managed practice that runs for a year or more per client. Contracts that acknowledge that upfront are the ones that stay profitable through enforcement, not just through onboarding.