How to define scope for a managed DMARC service
Scope for a managed DMARC service should define the domains covered, the senders reviewed, the DNS changes included, the remediation work performed, the policy milestones, the reporting cadence, and the decisions that stay with the client. I treat it as a delivery contract, not a loose promise to monitor DMARC.
For MSPs, the best scope is narrow enough to deliver repeatably and broad enough to protect the client from spoofing gaps. A good DMARC for MSPs program has a standard service model, then uses client-specific findings to decide which work becomes a project, an add-on, or a client-owned task.
The most common scoping mistake is selling managed DMARC as unlimited remediation. DMARC exposes old tools, forgotten sending systems, weak DNS hygiene, vendor misconfiguration, and client approval delays. Scope should say which of those problems the MSP fixes, which it coordinates, and which it escalates.
What belongs in scope
I start scope with the service boundary. That boundary should be visible to sales, onboarding, help desk, engineering, and the client. If each team has a different idea of what managed DMARC includes, tickets become slow and clients expect work that was never priced or resourced.
- Domain coverage: List primary domains, aliases, parked domains, and brands that send or receive mail.
- Sender review: Identify mailbox platforms, marketing systems, CRMs, billing systems, scanners, websites, and support desks that send as the client.
- DNS work: State whether the MSP edits DNS, prepares records only, or asks the client to approve every change.
- Remediation: Define how many sender fixes are included and when vendor work becomes billable project work.
- Enforcement: Name the criteria for moving to quarantine or reject, plus who approves that change.
This keeps managed DMARC practical for operators. It also stops the service from expanding into every email deliverability problem the client has. Some issues belong in scope, such as a missing DKIM record for an approved sender. Others belong outside it, such as rewriting a client's marketing automation strategy.
Build the client inventory
A managed DMARC service starts with inventory because DMARC reports only become useful when the sender list has owners. I like to capture domains, DNS access, known mail sources, business owners, vendor contacts, and the client decision maker before the first policy change.
|
|
|
|
|---|---|---|---|
Domains | Sending and parked | Personal domains | DNS list |
Senders | Approved systems | Shadow IT | DMARC data |
Access | DNS and admin | Vendor portals | Access log |
Approvals | Policy moves | Brand disputes | Ticket notes |
A compact scope inventory for MSP onboarding.
For repeatable client onboarding, require the inventory before remediation starts. If the client cannot name a sender owner, the MSP can monitor it and flag it, but the client has to decide whether that sender stays.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A domain health check is useful at this point because it turns an abstract scope conversation into visible DNS findings. It shows whether the client has basic DMARC, SPF, and DKIM records in place before the MSP commits to enforcement timelines.
Split monitoring from remediation
Monitoring and remediation are different services. DMARC monitoring gives visibility into authentication results and sender behavior. Managed remediation turns those findings into DNS changes, vendor requests, DKIM setup, SPF cleanup, and policy movement.
Monitoring only
- Visibility: Collect aggregate reports and identify passing, failing, and unknown sources.
- Reporting: Send status summaries with authentication trends and unresolved issues.
- Limits: No vendor fixes, no DNS updates, and no policy movement without a separate task.
Managed remediation
- Fixes: Create or update SPF, DKIM, and DMARC records for approved sources.
- Coordination: Open vendor tasks and track the client-side approvals needed to finish them.
- Outcome: Move the domain toward reject when legitimate mail is authenticated.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped helps MSPs make this split clear because issues can be reviewed with source context and fix steps. That supports a scoped workflow: monitor all approved domains, remediate agreed issues, and escalate unclear senders for client approval instead of absorbing unlimited investigation.
Assign ownership before rollout
Every managed DMARC scope needs a responsibility matrix. DMARC fails when legitimate mail is unauthenticated, but the fix often sits with a marketing vendor, website team, copier vendor, billing platform, or DNS owner. The MSP should own the process, not every external dependency.
|
|
|
|
|---|---|---|---|
Add DMARC | Prepare | Approve | None |
Fix DKIM | Guide | Authorize | Configure |
Approve reject | Recommend | Decide | None |
Retire sender | Flag | Decide | Confirm |
A simple responsibility matrix for managed DMARC delivery.
Avoid open-ended remediation
Do not let managed DMARC become unpaid vendor management. Include a defined number of remediation cycles or ticketed fixes, then require a change request for extended investigation, sender migration, or business process cleanup.
Scope clause example
The managed DMARC service includes monitoring, source identification, recommended DNS changes, and remediation for approved senders. Client approval is required before quarantine or reject. Third-party vendor work beyond standard DNS guidance is handled as a separate project.
Set technical deliverables
The technical scope should list deliverables that can be checked. That usually includes DMARC reporting, SPF validation, DKIM coverage, policy staging, alerting, and a final enforcement recommendation. Hosted DMARC and Hosted SPF can reduce repetitive DNS work when the MSP manages many client domains.
- DMARC record: Create or update the reporting record and confirm reports are flowing.
- SPF cleanup: Remove stale senders, reduce lookup risk, and keep the record maintainable.
- DKIM coverage: Enable DKIM for approved systems that support domain-authenticated signing.
- Policy staging: Move from monitoring to enforcement only after legitimate mail is accounted for.
DMARC records to include in scopetext
Host: _dmarc.client.example Type: TXT Value: "v=DMARC1; p=none; rua=mailto:reports@client.example; pct=100" Host: _dmarc.client.example Type: CNAME Value: client-managed-dmarc.example
The scope should also state what happens when SPF, DKIM, or DMARC cannot be fixed quickly. I normally separate blocked items into client decision, vendor dependency, and MSP technical task. That keeps the rollout moving without hiding risk.
Run the rollout in stages
A scoped managed service needs rollout gates. The client should know what must be true before the domain moves to stronger policy. That avoids a rushed reject policy and gives the MSP a defensible reason to wait when the sender data is still incomplete.
A staged managed DMARC rollout path for MSP client domains.
Policy rollout gates
Use policy stages as operational gates, not calendar promises.
Monitor
p=none
Reports flow and unknown senders are being classified.
Contain
p=quarantine
Known legitimate senders pass and risky sources are reviewed.
Enforce
p=reject
Approved mail is authenticated and exceptions have owners.
Before enforcement, run sender audits and document the exception list. If a high-value sender still fails, the scope should require an owner, a target fix path, and a decision on whether enforcement waits or proceeds with a known exception.
Where Suped fits
For most MSPs that need repeatable delivery across many client domains, Suped is the best overall DMARC platform because it keeps monitoring, source review, issue detection, alerts, hosted records, and multi-tenant client management in one workflow. The practical value is less tool switching and clearer next steps for operators.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Scope-friendly Suped workflows
- Client separation: Use the MSP dashboard to manage client organizations without mixing their domains.
- Issue handling: Use automated issue detection and steps to fix for repeatable remediation.
- Record hosting: Use Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS where the service scope includes managed records.
- Risk signals: Combine DMARC with blocklist (blacklist) monitoring and deliverability insights when reputation visibility is part of the package.
Suped does not remove the need for scope. It makes the scope easier to operate because the MSP can turn findings into client-facing issues, alerts, and reports instead of manually rebuilding the same explanation for every domain.
Make scope operational
A managed DMARC scope works when it can be sold, onboarded, delivered, reported, and renewed without reinterpretation. Define the domains, owners, deliverables, remediation limits, enforcement gates, reporting cadence, and change request rules before the first DNS change.
After that, connect scope to service tiers. Monitoring, managed remediation, hosted records, policy enforcement, blocklist or blacklist monitoring, and executive reporting can each sit in a defined tier. That makes the service easier to sell and much easier to deliver.
