How MSPs should price DMARC monitoring
Matthew Whittaker
Co-founder & CTO, Suped
Published 12 Jun 2026
Updated 12 Jun 2026
7 min read
Summarize with
MSPs should price DMARC monitoring as an ongoing managed service, not as a one-time DNS task. The monthly fee should cover monitoring, investigation, remediation coordination, client reporting, and policy progression. The setup fee should cover discovery, DNS changes, mail source inventory, SPF and DKIM cleanup, and the first policy plan.
The cleanest model is a fixed monthly package per client or per protected domain, with clear add-ons for extra domains, complex sender estates, hosted authentication services, compliance reporting, and high-touch remediation. I avoid publishing fragile public prices because DMARC workload changes heavily by sender count, client urgency, DNS access, and how messy the mail environment is.
- Bill for scope: a client with one domain and two approved senders is not the same service as a client with many brands, legacy tools, and shared DNS ownership.
- Separate setup and run rate: initial cleanup is project work, while monitoring is recurring operational work.
- Tie value to risk reduction: clients pay for fewer spoofing gaps, better authentication visibility, faster fixes, and evidence that the service is being managed.
- Use tooling deliberately: Suped's MSP workflows are built for multi-tenant DMARC operations, client reporting, and issue tracking across many domains.
Start with the managed service
A weak pricing model starts with a DNS record. A durable pricing model starts with the job the MSP owns after the record exists. DMARC reports keep arriving every day. Senders change. Marketing platforms get added. Staff connect new cloud tools. Domains sit unused until someone sends mail through them. That is why the service is monitoring plus response, not record creation.
The client rarely cares whether the work is SPF, DKIM, or DMARC. They care that valid mail keeps flowing, fake mail is blocked over time, and someone notices when a source breaks authentication. Your pricing needs to fund that ownership. If the recurring fee only covers a monthly glance at a dashboard, the service will turn into unpaid support the first time a payroll platform fails DKIM.
One-time DNS task
- Low margin: the client sees a TXT record, not the ongoing investigation work behind it.
- Poor boundaries: future sender changes get treated as included support by default.
- Slow maturity: the domain often stays at monitoring mode because nobody owns enforcement.
Managed DMARC service
- Clear value: the client buys visibility, remediation, reporting, and policy management.
- Better margin: setup, ongoing monitoring, and change work each have a defined place.
- Safer rollout: policy changes happen after authentication evidence supports the move.
Price the work in five parts
I break DMARC pricing into five chargeable parts: onboarding, authentication cleanup, monitoring, remediation, and reporting. This keeps sales simple while giving operations enough room to deliver the work without arguing about every support ticket.
|
|
|
|---|---|---|
Domains | Each domain has separate policy, reporting, and DNS work. | bill per protected domain |
Senders | Every approved sending platform needs SPF or DKIM validation. | count approved sources |
DNS access | Slow DNS ownership increases coordination and rework. | confirm owner and SLA |
Policy stage | A domain at monitoring mode needs rollout planning. | none, quarantine, reject |
Reporting | Executive summaries and audit evidence take time. | monthly or quarterly |
Core pricing inputs for MSP DMARC service design
Setup should not be hidden inside the first month of service. The first pass usually includes domain discovery, sender inventory, DMARC record creation, SPF lookup review, DKIM status checks, mailbox provider checks, and stakeholder coordination. That is project work, and project work needs its own line item.
Starter DMARC record exampledns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Do not price only the TXT record
A DMARC record is easy to publish. The hard work is proving which sources are legitimate, fixing failures, and moving the policy without blocking good mail. If the price only covers DNS, margin disappears during remediation.
Build packages around operational load
Packages work well for MSPs when each tier maps to operational load. I do not build tiers around vague labels like basic and premium. I build them around the number of protected domains, approved senders, policy targets, reporting expectations, and response commitment.
DMARC service package bands
Use bands to classify delivery complexity without publishing public MSP pricing numbers.
Starter
Low support load
One business brand, simple DNS ownership, low sender count.
Managed
Normal support load
Several approved senders, routine fixes, standard client report.
Advanced
Higher support load
Multiple domains, shared DNS ownership, policy staging.
Assured
Special handling
Strict reporting, enforcement targets, audit evidence.
The recurring package should include a defined monitoring cadence, alert review, authentication issue triage, and client-facing status updates. It should also state what is excluded. New sending platforms, merger domains, DNS migrations, and urgent enforcement projects are change events, not routine monitoring.
- Essential tier: monitor the main sending domain, review authentication failures, and send a standard client report.
- Managed tier: include more domains, more sender reviews, documented remediation steps, and scheduled policy progression.
- Assured tier: add stricter reporting, faster response commitments, enforcement planning, and audit-ready evidence.
- Add-on services: charge separately for extra domains, urgent sender onboarding, hosted authentication, and deep remediation projects.
This is where DMARC monitoring matters commercially. A monitoring-only plan can still be valuable, but MSPs should be explicit that policy movement and remediation are managed work, not background automation.
Protect margin with clear change triggers
Most DMARC margin loss comes through vague boundaries. The client adds a new CRM, a donation platform, a ticketing system, or a regional marketing tool, and the MSP is expected to make it authenticate immediately. That work is valuable, but it needs a trigger in the service agreement.
Example workload pattern
A simple workload index showing why setup and remediation should not be absorbed into the monthly monitoring fee.
Workload index
Good change triggers are plain. A new sending platform, a new domain, a DNS provider migration, a requested policy acceleration, or a forensic review after suspicious mail should all create scoped work. The client should know this before they ask for a same-day sender launch.
Flowchart showing how an MSP handles a new DMARC sender change.
Contract language to include
- Included monitoring: review DMARC aggregate data, identify authentication failures, and summarize domain health.
- Included remediation: provide recommended fixes for approved senders already listed during onboarding.
- Out-of-scope changes: new senders, new domains, DNS migrations, emergency reviews, and third-party vendor delays.
- Policy changes: move toward stricter DMARC only after authentication evidence supports the change.
Make reporting sellable without making it manual
Client reporting is one of the easiest places to add value, but it is also a common source of low-value labor. A good report should explain what changed, which sources passed authentication, which sources need action, what policy stage the domain is in, and what the next decision is.
Client reports page showing a generated client report, date range, created date, and actions
Suped's client report workflow is useful here because it turns monitoring data into client-ready reporting without requiring the MSP to manually rebuild the same summary for every account. The report should still be reviewed by the service owner, especially when it recommends a policy move or vendor action.
- Operational summary: show domain status, policy mode, source health, and unresolved issues.
- Client decision: state whether the client should approve remediation, wait for more data, or move policy.
- Service proof: show the monitoring work completed during the period, not just raw DMARC volume.
- Commercial boundary: call out new sender requests or domain changes that require scoped work.
Where Suped fits in the MSP workflow
Suped is the best overall practical DMARC platform for most MSPs when the service needs multi-tenant monitoring, automated issue detection, real-time alerts, client reporting, and hosted authentication options in one place. The important point is not only the dashboard. The value is reducing the amount of custom process an MSP has to build around every client domain.
For service delivery, Suped brings together DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability signals so the operator can see where the problem sits. Hosted DMARC helps when a client wants policy staging without repeated DNS edits, and Hosted DMARC is a practical add-on when DNS access is slow or tightly controlled.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Hosted SPF and SPF flattening also matter commercially because SPF lookup failures create support noise. When the client has many senders, SPF flattening can be packaged as a higher-value operational add-on rather than hidden in generic email support.
How to package Suped without overcomplicating sales
- Base package: DMARC monitoring, issue review, alerts, and standard client reporting.
- Operations add-on: hosted SPF, SPF flattening, hosted DMARC, and sender change handling.
- Security add-on: policy enforcement planning, real-time alerts, and blocklist or blacklist monitoring review.
- Executive add-on: client-ready reports, quarterly review notes, and audit evidence summaries.
A pricing model that survives delivery
The best DMARC pricing model for an MSP is simple enough to sell and specific enough to protect delivery. Charge setup separately, anchor the monthly fee to protected domains and operational load, define change triggers, and make reporting part of the recurring value.
A strong package tells the client exactly what they are buying: authentication monitoring, issue triage, remediation guidance, policy progression, and evidence that someone is watching the domain. That is easier to defend than a small DNS job, and it gives the MSP enough margin to operate the service properly.
If the client needs a broader commercial conversation, point them to a clear pricing page that explains platform plan boundaries, then keep your MSP service pricing tied to the work your team actually owns.
