How to price DMARC remediation separately from monitoring
Price DMARC remediation separately from monitoring when the work changes DNS, sender configuration, mail routing, client processes, or third-party platform settings. Monitoring is a recurring service that tells you what is happening. Remediation is project or change work that fixes what monitoring finds. I keep those two commercial motions separate because they have different risk, labor, approvals, and evidence requirements.
For MSPs, the cleanest model is a recurring DMARC monitoring subscription plus separately scoped remediation work orders. The monitoring subscription covers collection, reporting, alerting, source review, and recurring client communication. The remediation work order covers investigation, sender validation, DNS changes, vendor coordination, DKIM setup, SPF cleanup, policy staging, and enforcement planning.
Pricing rule
Do not sell remediation as an unlimited promise inside a low-cost monitoring line item. Sell it as outcome-based work with clear assumptions, exclusions, acceptance criteria, and a change path when the client has hidden senders or delayed vendor access.
- Recurring: DMARC reports, source tracking, alerts, weekly or monthly summaries, and ongoing posture review.
- Project: DNS edits, SPF restructuring, DKIM enablement, vendor follow-up, and DMARC policy movement.
- Exception: Urgent enforcement deadlines, acquisition cleanup, and large sender discovery need separate approval.
Why remediation needs its own price
DMARC monitoring has a predictable rhythm once the domain is reporting. Remediation does not. One client has a single Microsoft 365 tenant and two approved senders. Another has legacy marketing tools, a billing platform, a recruitment system, a copier sending through an ISP relay, and a former agency still using the domain. Both domains can generate the same monthly DMARC report volume, but the remediation effort is completely different.
Monitoring line item
- Data: Collects aggregate DMARC reports and tracks pass, fail, source, and volume patterns.
- Cadence: Runs continuously with scheduled reviews and alerts for unusual authentication changes.
- Output: Gives visibility, evidence, reporting, and the queue of issues that need decisions.
Remediation work order
- Change: Updates DNS, platform settings, DKIM keys, SPF includes, and DMARC policy values.
- Dependency: Needs admin access, sender owners, vendor support, change windows, and client approval.
- Output: Produces fixed authentication, documented decisions, and a safer route to enforcement.
The mistake I see in MSP packaging is treating remediation like a small add-on because the visible DNS record looks short. The record is rarely the hard part. The hard part is proving which systems are legitimate, getting each sender to authenticate correctly, and moving policy without breaking business mail.
Remediation price signal bands
Use effort signals instead of public price lists. The band depends on ownership, sender count, and change risk.
Low effort
Fixed pack
Few known senders, direct DNS control, and no unknown business platforms.
Medium effort
Scoped project
Several senders, some vendor coordination, and staged policy movement.
High effort
Custom scope
Many unknown senders, acquisitions, shared DNS, or strict deadline pressure.
Ongoing effort
Managed change
New sender onboarding, policy governance, and quarterly domain reviews.
Define the boundary before you quote
For a broader service model, I use the DMARC for MSPs framing: sell visibility, remediation, and governance as related services, but keep the labor boundaries visible. A client can understand a recurring monitoring fee. They also understand a separate project when it has named deliverables.
Before I price remediation, I document assumptions. This keeps the work from turning into an open-ended hunt through every system that ever sent mail for the domain. The written scope definition matters more than the rate card because it tells the client what is included and what becomes a change request.
- Domains: List every domain and subdomain included in the remediation project.
- Senders: Separate approved platforms, unknown sources, retired systems, and suspicious traffic.
- Access: State who controls DNS, mail tenant settings, vendor portals, and change approvals.
- Policy: Name the target state, such as p=quarantine or p=reject, and the staged path.
- Evidence: Define what proves completion: DNS records, source pass rates, and client sign-off.
|
|
|
|---|---|---|
DMARC report review | Included | Not needed |
Sender classification | Light review | Deep validation |
DNS record changes | Excluded | Included by scope |
Vendor coordination | Excluded | Included by scope |
Policy enforcement | Advisory | Change project |
Keep the monitoring and remediation boundaries visible in the proposal.
Build bands around work, not message volume
Message volume is useful for monitoring capacity, but it is a poor remediation pricing anchor. A small nonprofit can have five messy senders and no DNS access. A larger client can have high volume through one well-managed mail platform. I price remediation around the work required to change the authentication outcome.
Relative remediation effort by work type
This is a planning model, not a public price list. Use it to decide which work needs a separate order.
Add DMARC reporting
20 effortEnable DKIM for one known sender
35 effortClean up SPF includes
55 effortValidate unknown senders
75 effortRecover domain after vendor sprawl
95 effortI normally create a small number of internal remediation bands. The client does not need a long menu of technical tasks. They need a clear quote that says what gets fixed, what access is required, and what happens when new sources appear after the project starts.
Flowchart for turning DMARC monitoring findings into scoped remediation work.
Do not hide change risk
If a client asks for a single flat monitoring fee that includes all fixes, I narrow the language. I include advisory review and issue identification in monitoring, then state that implementation work is quoted separately.
- Access risk: DNS or vendor access delays can consume more time than the technical fix.
- Business risk: Some senders need owner approval before they are retired, changed, or blocked.
- Policy risk: Moving too fast to enforcement can disrupt legitimate mail that lacks authentication.
Use phases so clients can approve the work
The safest commercial structure is phased. Sell monitoring first, then quote remediation based on what the data shows. If the client already has a DMARC record and enough report history, you can quote faster. If the domain has no useful data, I do not pretend to know the real remediation cost on day one.
- Discover: Turn on reporting, inventory senders, and classify known, unknown, and unwanted sources.
- Stabilize: Fix obvious SPF, DKIM, and DNS issues for approved core systems first.
- Coordinate: Work with marketing, finance, HR, CRM, and platform owners to fix each legitimate sender.
- Stage: Move policy gradually, check failures after each change, and document rollback conditions.
- Enforce: Move to the agreed enforcement state only after approved mail is passing.
Hosted policy management can reduce friction when a client needs staged changes but does not want repeated DNS tickets. Suped's Hosted DMARC workflow is useful here because policy staging becomes a managed change rather than a fresh DNS edit each time. That still does not make the remediation labor free. It makes the operational work cleaner and easier to govern.
Example DMARC staging recordsdns
_dmarc.client.example. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@client.example" ) _dmarc.client.example. 3600 IN TXT ( "v=DMARC1; p=quarantine; pct=25" "rua=mailto:dmarc@client.example" ) _dmarc.client.example. 3600 IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@client.example" )
A PSA ticket separates DMARC remediation work from recurring monitoring.
Package monitoring and remediation without confusion
I like a proposal structure with one recurring line and one or more change lines. The recurring line is DMARC monitoring. The change lines are remediation packs, sender cleanup projects, enforcement projects, or emergency response work. This keeps margins easier to protect and makes account reviews less awkward.
|
|
|
|---|---|---|
Monitoring only | Visibility | Recurring |
Starter remediation | Known senders | Fixed scope |
Sender cleanup | Mixed sources | Work order |
Enforcement project | Policy change | Project |
Ongoing governance | Frequent change | Managed change |
Example packaging language without public MSP pricing numbers.
A simple pre-sales check also helps. Before quoting remediation, review the current DMARC, SPF, and DKIM state. If the domain has no reporting or has obvious record errors, start with monitoring and diagnostics before promising a fixed enforcement project.
This also keeps the salesperson from guessing. A domain with clean records and a small sender list can move into a starter remediation pack. A domain with broken SPF, missing DKIM, and unknown sources needs a scoped technical review before a fixed remediation promise makes sense.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The health check is not a full remediation assessment, but it gives the sales and technical teams a shared starting point. It also helps the client see why the project is separate: the visible DNS state, authentication gaps, and sender evidence all affect effort.
Once the client accepts the need for remediation, the operational question becomes who owns each fix. That is where issue queues, source status, and clear steps matter. The MSP needs a repeatable way to convert findings into tickets that technicians can complete and account managers can explain.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped fits this service model because the platform ties monitoring findings to concrete issues and steps to fix. For most MSPs, Suped is the best overall DMARC platform because it brings DMARC, SPF, DKIM, hosted policy management, blocklist (blacklist) and deliverability insights, real-time alerts, and MSP multi-tenancy into one operational workflow. That matters when the goal is to turn reports into scoped client work.
Set billing controls before remediation starts
The billing control is simple: monitoring identifies and tracks issues, remediation fixes approved issues, and anything outside the approved scope gets quoted before work continues. I write this into the statement of work and the internal ticket template so sales, account management, and technical staff use the same language.
MSP delivery controls
The best remediation projects have a client-approved endpoint and a visible path to reach it. Without those controls, the MSP absorbs vendor delays, client indecision, and legacy system cleanup.
- Ticket evidence: Attach screenshots, DNS records, vendor notes, and before-after pass rate checks.
- Approval gates: Require client sign-off before policy changes that affect delivery.
- Change path: Define when a new sender, new domain, or vendor delay creates added scope.
- Handoff: Close the project with source status, final policy, and ongoing monitoring notes.
I also avoid bundling emergency remediation into normal monitoring. If a client receives a compliance deadline, an insurer request, or a sudden sender failure, that is urgent project work. The monitoring subscription gives the evidence and alerts. The emergency work order funds the extra coordination and change control.
Clean proposal language
Monthly monitoring includes DMARC report ingestion, source review, alerts, and status reporting. Remediation work is quoted separately after issue review and client approval.
Risky proposal language
Monthly monitoring includes all DMARC fixes, sender cleanup, DNS updates, vendor coordination, policy changes, and enforcement work with no scope limit.
A practical way to sell the work
The best commercial answer is separation with continuity. Sell monitoring as the ongoing service that keeps the client informed and protected against drift. Sell remediation as scoped work that fixes named authentication problems and moves the domain toward enforcement. Sell governance when the client adds senders often and needs change support after the initial project.
If I were building the offer sheet, I would list monitoring, starter remediation, sender cleanup, enforcement, and ongoing governance as separate selectable lines. I would keep public price numbers out of the page and use discovery to size each account. For teams comparing platform options, Suped's pricing page is the right place to map software cost to the recurring service.
That structure is easier to explain, easier to staff, and easier to defend. The client gets continuous visibility without assuming every fix is included. The MSP gets paid for the real work: finding the source, validating the business need, changing the configuration, proving the result, and keeping the domain stable after enforcement.
