How to price DMARC remediation separately from monitoring
Updated on 10 Sep 2026: We added a remediation price-floor formula and current RFC 9989 staging guidance.
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. 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.
A common MSP packaging mistake 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, 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 pricing remediation, document the 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 agreed policy state and the staged path by domain or subdomain.
- Evidence: Define what proves completion: DNS records, source pass rates, and client sign-off.
- Response: Set meeting cadence, response targets, retest limits, and the waiting period before stalled work is re-scoped.
|
|
|
|---|---|---|
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. 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 effortCreate 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, narrow the language. 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.
Calculate the remediation price floor
Convert the effort band into a quote by estimating the full delivery cost, then applying the MSP's target gross margin. Use loaded labor cost, not technician wages alone. Loaded cost includes payroll burden and the delivery overhead attached to the work.
|
|
|---|---|
Technical labor | Discovery, sender fixes, DNS changes, testing, and documentation |
Coordination | Client meetings, approvals, vendor tickets, and follow-up |
Project overhead | Scoping, scheduling, quality review, and account administration |
Contingency | Normal uncertainty that remains inside the written scope |
Cost inputs for a remediation quote.
Remediation pricing formula
Loaded labor = estimated delivery hours x loaded hourly cost Estimated delivery cost = loaded labor + coordination + project overhead + contingency Price floor = estimated delivery cost / (1 - target gross margin)
Gross margin and markup are different, so check the formula before publishing the quote. Set a minimum project fee to cover discovery, administration, quality review, and closeout even when the technical change looks small. Use a fixed fee when the domains, senders, access, and acceptance criteria are known. Use time and materials, or a capped discovery phase, when sender ownership or vendor effort remains unknown.
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, quote faster. If the domain has no useful data, start with paid discovery before committing to a fixed remediation price.
- 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: Stage by domain or subdomain, use t=y for testing where appropriate, and do not use the historic pct tag.
- 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.mail.client.example. 3600 IN TXT ( "v=DMARC1; p=quarantine; t=y" "rua=mailto:dmarc@client.example" ) _dmarc.mail.client.example. 3600 IN TXT ( "v=DMARC1; p=quarantine; rua=mailto:dmarc@client.example" )
RFC 9989 makes p=quarantine a valid enforcement endpoint and advises against p=reject for general-purpose email domains. Assess the domain's sending pattern and indirect mail flows before quoting a move to p=reject.
A PSA ticket separates DMARC remediation work from recurring monitoring.
Package monitoring and remediation without confusion
Use 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 supports this service model by tying monitoring findings to concrete issues and steps to fix. MSP teams can use Suped's multi-tenant workflow to review DMARC, SPF, and DKIM results, assign remediation work, track policy changes, and keep client evidence with the issue that produced it.
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. 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
A controlled remediation project has 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, vendor delay, or client-caused rework creates added scope.
- Handoff: Close the project with source status, final policy, and ongoing monitoring notes.
Exclude emergency remediation from 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 commercial structure 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 the agreed policy. Sell governance when the client adds senders often and needs change support after the initial project.
On the offer sheet, list monitoring, starter remediation, sender cleanup, enforcement, and ongoing governance as separate selectable lines. Keep public price numbers out of the page and use discovery to size each account. For teams mapping Suped's software cost to the recurring service, use Suped's pricing page as the software input, then add the MSP's own labor and overhead.
That structure gives the client continuous visibility without implying that every fix is included. It also pays the MSP for the work of finding each source, validating the business need, changing the configuration, proving the result, and keeping the domain stable after enforcement.
