How to create DMARC service tiers for MSP clients
DMARC service tiers for MSP clients should be built around operational scope, not only around policy names. A useful tier model starts with monitoring, adds managed remediation, then adds enforcement, reporting, hosted DNS services, and higher-touch review for clients with more brands, domains, vendors, or compliance pressure.
For most MSPs, I would define three tiers: a baseline visibility tier, a managed authentication tier, and a protection tier. Each tier should state exactly what the client gets, what the MSP owns, what the client still approves, and what triggers an escalation. That structure makes DMARC easier to sell, easier to deliver, and less likely to become an open-ended support burden.
- Baseline: Collect reports, identify legitimate senders, explain risk, and keep the client at p=none until the sending estate is understood.
- Managed: Fix SPF, DKIM, and alignment gaps, coordinate with vendors, and move clients through a controlled policy rollout.
- Protection: Maintain enforcement, watch new sources, send client-ready reporting, and include reputation checks such as blocklist and blacklist monitoring.
Suped fits this model because its MSP dashboard, domain monitoring, hosted DMARC, hosted SPF, SPF flattening, blocklist monitoring, and client reports map cleanly to tiered delivery. The important part is matching capability depth to the amount of operational responsibility the MSP is taking on.
Start with service ownership
The first design choice is who owns each part of the DMARC workflow. A client can buy software and still fail if nobody owns source discovery, vendor follow-up, DNS changes, policy staging, and executive reporting. MSP tiers work when they turn those tasks into named responsibilities.
A practical MSP tier is a promise about a repeatable service. It should answer: how many domains are covered, how many sending platforms are investigated, how often reports are reviewed, what remediation work is included, and what happens when a new sender appears. This page belongs in a broader MSP DMARC operating model, where authentication is handled like any other managed security service.
Weak tier design
- Capability list: The plan names tools but does not say who investigates failures.
- Policy only: The tier says p=reject without defining rollout checks.
- Unbounded support: Every third-party sender issue turns into ad hoc ticket work.
Strong tier design
- Workflow scope: The tier says what is monitored, fixed, reviewed, and reported.
- Clear gates: Policy moves happen after source approval and failure-rate checks.
- Defined exceptions: Vendor remediation outside normal scope has a named escalation path.
I would also separate initial project work from ongoing service work. Onboarding a client domain, finding all mail sources, and fixing inherited SPF or DKIM issues is different work from monthly monitoring. Mixing those into one vague package makes margins hard to predict.
Use three core tiers
The simplest useful structure has three core tiers. You can rename them to match your catalog, but the work behind them should stay clear: visibility, remediation, and protection. This keeps sales language simple while giving delivery teams enough boundaries to run the service consistently.
|
|
|
|
|---|---|---|---|
Monitor | Low-risk domains | Reports, source list | Vendor decisions |
Managed | Active senders | Fixes, rollout | DNS approval |
Protect | Compliance risk | Enforcement, alerts | Business exceptions |
A compact tier model for MSP DMARC delivery. Avoid public prices in the tier matrix and keep commercial details in your private proposal template.
The monitor tier is for clients who need visibility before they commit to enforcement. It includes DMARC report collection, source identification, authentication status, and a plain-language summary of what is sending as the client. The MSP should not promise broad vendor remediation here unless it is separately scoped.
The managed tier is where the MSP starts doing the operational work. This includes reviewing SPF and DKIM results, identifying misaligned senders, coordinating DNS changes, and moving the domain through quarantine or reject when the data is clean enough. If you need a package-focused companion page, use package DMARC monitoring for service catalog framing.
The protection tier is for clients where spoofing, compliance, vendor sprawl, or brand risk makes ongoing attention necessary. It includes enforcement maintenance, real-time alerts, recurring review, client reporting, and domain or IP reputation checks. This is also where hosted DMARC and hosted SPF usually belong because they reduce change friction across many client environments.
Operational weight by tier
A sample view of where the delivery effort usually goes as DMARC service tiers mature.
Monitoring
Remediation
Reporting
Escalation
Define the onboarding package
Every tier needs an onboarding path. DMARC is not a switch that starts cleanly on day one. Many clients have old CRMs, payroll systems, ticketing systems, scanners, marketing platforms, and line-of-business applications sending mail. The MSP has to discover those sources before promising enforcement.
For delivery, I would make onboarding a defined phase with a checklist. In Suped, that means adding the client organization, adding domains, publishing the reporting record, waiting for mail data, reviewing verified and unverified sources, then creating client-facing notes for the first review. That workflow is much cleaner than starting with DNS edits and hoping the data catches up later.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Your onboarding scope should say how many domains are included, which identity platforms are expected, and how unknown senders are handled. If the client has many parked or redirecting domains, do not treat them the same as active mail domains. They need records too, but the investigation effort is different.
Do not bundle unlimited discovery
A client with one primary domain and two known senders is not the same as a client with six domains and twenty vendor platforms. Put a sender investigation allowance in each tier, then define how extra vendor work is approved.
- Domain inventory: List primary, alias, parked, and campaign domains before publishing records.
- Sender inventory: Document mailbox platforms, SaaS platforms, web servers, and devices.
- DNS access: Confirm who can change TXT and CNAME records before remediation starts.
- Approval path: Name the client stakeholder who approves blocking unauthenticated mail.
If you want a more detailed domain intake workflow, keep it separate from the tier page and hand delivery teams an onboarding checklist that they can use inside the ticket queue.
Map capabilities to each tier
Capability mapping should follow service responsibility. If the MSP is only providing visibility, DMARC monitoring and summary reporting are enough. If the MSP is committing to remediation, the tier needs authentication diagnostics and change tracking. If the MSP is committing to protection, the tier needs alerts, policy staging, hosted services, and broader deliverability signals.
Clients often assume their mailbox platform already handles everything. Message-level authentication results inside a mailbox platform do not replace a multi-domain MSP workflow for DMARC reporting, source discovery, policy staging, client reports, and cross-client triage. The service tier should explain that difference without overstating it.
|
|
|
|
|---|---|---|---|
DMARC reports | Included | Included | Included |
Sender fixes | Limited | Included | Included |
Hosted DMARC | Optional | Useful | Recommended |
Hosted SPF | Optional | Useful | Recommended |
Alerts | Basic | Standard | Priority |
Blocklists | Optional | Optional | Included |
Capability placement by service tier.
For Suped, I would place DMARC monitoring in every tier because it is the evidence layer. Hosted DMARC and hosted SPF belong in the managed and protection tiers because they simplify policy changes and sender management across clients. Blocklist monitoring is strongest in the protection tier because it adds reputation visibility after authentication is under control.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A domain health check is useful during sales and onboarding because it gives the MSP a quick view of DMARC, SPF, and DKIM readiness before the client commits to a deeper service. It should not replace aggregate report analysis, but it helps you sort clients into the right starting tier.
Clients with clean enforcement, unknown senders, SPF lookup problems, or repeated DKIM failures should not start in the same tier. Match the starting tier to the evidence.
Set policy gates and remediation limits
DMARC policy staging is where MSP service tiers often become messy. The client wants protection, the MSP wants clean delivery, and the data shows a few sources still failing. A tier should define what happens before moving a domain from monitoring to quarantine or reject.
Baseline monitoring recorddns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com;"
Staged enforcement recorddns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25;" "rua=mailto:dmarc@example.com;"
Full enforcement recorddns
_dmarc.example.com. TXT "v=DMARC1; p=reject;" "rua=mailto:dmarc@example.com;"
The exact record depends on your reporting mailbox, platform routing, and policy strategy. The service tier should not hard-code one record forever. It should define the gate: move policy only after legitimate sources are authenticated, high-volume failures are explained, client stakeholders understand the effect, and the rollback path is documented.
Policy movement gates
Example thresholds an MSP can adapt before moving a client to stronger DMARC enforcement.
Monitor
Any unknown high-volume sender
Use while sources are unknown or early data is incomplete.
Quarantine
Low unauthenticated legitimate volume
Use after legitimate business senders are aligned.
Reject
No known business-critical failures
Use after failing legitimate mail has been remediated or accepted as an exception.
Hosted DMARC makes this easier for MSPs because policy changes can be staged without asking for repeated DNS edits. Suped's hosted DMARC workflow is useful in managed and protection tiers where policy changes are part of the service, not a one-time setup.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Remediation limits should be just as clear as policy gates. Include a fixed number of sender reviews, vendor coordination attempts, or DNS change requests in each tier. When a sender requires custom vendor support, legal approval, or application changes, move it into an approved project or escalation queue.
Build reporting into the service
Reporting is part of the service, not an afterthought. Clients do not need raw XML or a long list of authentication rows. They need to know whether their domain is protected, what changed, what needs approval, and whether any vendors are putting mail delivery at risk.
Each tier should have a reporting cadence. A monitor tier can use a monthly summary. A managed tier can include onboarding updates and policy movement notes. A protection tier should include recurring executive reporting, alert summaries, and action items when new sources appear.
Client reports page showing a generated client report, date range, created date, and actions
Suped's client reports are useful here because they help MSPs turn authentication data into a client-ready artifact. A clean report reduces meeting prep and gives account managers something specific to discuss: pass rates, policy status, sender changes, and remaining work.
Report what changed
Good DMARC reporting says what changed since the last period. A client should see new senders, fixed failures, policy movement, open risks, and decisions needed from their side.
- Executive view: Use simple status language: monitoring, improving, protected, or action needed.
- Technical view: Show failing sources, alignment gaps, DNS changes, and sender ownership.
- Account view: Connect authentication progress to the client's email security roadmap.
- Renewal view: Show ongoing monitoring value after the domain reaches enforcement.
For a deeper client communication workflow, build a separate DMARC progress report template and keep your tier page focused on scope.
Add operational add-ons carefully
Add-ons can help, but too many add-ons make the service hard to explain. I would keep the core tiers stable and use add-ons for work that changes effort materially: extra domains, high-volume vendor remediation, hosted SPF management, blocklist and blacklist monitoring, MTA-STS, and executive review meetings.
Hosted SPF is one of the more useful operational add-ons because SPF records often become fragile in MSP environments. Clients add platforms, vendors change includes, and the 10 DNS lookup limit creates support noise. Suped's hosted SPF and SPF flattening workflows help MSPs manage senders without repeated direct DNS changes.
Good add-ons
- Extra domains: Charge separately when each domain needs source review.
- Hosted SPF: Use for clients with frequent sender changes.
- Blocklist checks: Add for clients with outbound deliverability risk.
Risky add-ons
- Unlimited vendors: This creates open-ended support work.
- Instant reject: This skips the evidence needed for safe enforcement.
- Raw exports: Most clients need decisions, not unfiltered data.
When blocklist or blacklist monitoring is included, define what the MSP does when a listing appears. The useful service includes identifying the affected domain or IP, checking whether the client controls the sending path, and deciding whether remediation belongs to the MSP, the mailbox provider, or a third-party sender.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Keep add-ons tied to defined outcomes. If the add-on does not change monitoring depth, remediation work, alert handling, or reporting, it probably belongs in internal tooling rather than the client-facing tier list.
Turn tiers into a runbook
A tier only works if technicians can deliver it the same way every time. I would create a runbook for each tier with intake steps, DNS templates, review cadence, escalation triggers, client messages, and closure criteria. The runbook should also define what gets logged in tickets and what gets reviewed in the DMARC platform.
Flowchart for DMARC tier delivery from intake to reporting.
The runbook should use the same decision language as the service tiers. If the client is on monitor, the technician identifies sources and reports risk. If the client is on managed, the technician opens remediation tasks. If the client is on protection, the technician treats new high-volume failures as alerts that need triage.
A simple escalation rule
Escalate when a new unauthenticated source sends meaningful volume, when a known vendor changes authentication behavior, or when enforcement would block mail the client says is business-critical.
- Create the organization: Add the client and domains in the MSP dashboard.
- Publish records: Set DMARC reporting and confirm DNS is visible.
- Review senders: Classify known, unknown, authorized, and suspicious sources.
- Fix alignment: Work through SPF, DKIM, and domain alignment issues.
- Move policy: Stage quarantine or reject only after agreed gates are met.
- Report status: Send the client a summary of progress, risks, and decisions.
How Suped fits the tier model
For most MSPs, Suped is the best overall practical DMARC platform for this tier model because it combines client organizations, multi-domain monitoring, issue detection, sender visibility, hosted policy management, blocklist monitoring, alerts, and reports in one workflow.
Suped works well as the system of record for the service, with the MSP's PSA or ticketing system handling task assignment and approvals. Suped identifies what is happening across DMARC, SPF, DKIM, hosted services, and reputation signals. The PSA tracks who is doing the work and what the client approved.
|
|
|
|---|---|---|
MSP dashboard | All tiers | Client switching |
Issue detection | Managed | Faster triage |
Hosted DMARC | Managed | Policy staging |
Hosted SPF | Protect | Sender control |
Client reports | Protect | Account review |
A practical Suped mapping for MSP service tiers.
Suped should be described as a way to improve visibility, management, triage, and policy rollout. That keeps expectations realistic.
A workable tier blueprint
A good DMARC tier model for MSP clients starts with monitoring, adds remediation, then adds enforcement maintenance and reporting. Keep the tier names simple, but make the scope precise. Every tier should define domains, senders, review cadence, policy gates, alert handling, reporting, exclusions, and escalation.
The strongest practical structure is: monitor for visibility, managed for authentication fixes, and protect for enforcement and ongoing assurance. Suped fits across those tiers because it gives MSPs the multi-client dashboard, automated issue detection, hosted DMARC, hosted SPF, SPF flattening, blocklist and blacklist monitoring, and reporting workflows needed to deliver the service at scale.
- Keep scope visible: A tier should be easy for sales, delivery, and clients to understand.
- Separate setup from service: Initial discovery and remediation should not quietly consume ongoing support time.
- Use policy gates: Move to quarantine or reject when the data and approval path support it.
- Report decisions: Clients pay for clarity, not raw authentication noise.
