How to define scope for a managed DMARC service
Updated on 6 Sep 2026: We updated this guide for RFC 9989 and clearer MSP change-control boundaries.
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. 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
Start with the service boundary in the statement of work (SOW). 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, subdomains, 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.
- Data and exit: Set report access, retention, export, and deletion terms, plus the records returned when service ends.
This keeps managed DMARC practical for operators. It also stops the service from expanding into every email deliverability problem the client has. Managed DMARC covers authentication for the client's exact domains. It does not cover inbound filtering or lookalike-domain monitoring. Compromised-account response needs separate scope. 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. Capture domains, subdomains, DNS access, known mail sources, business owners, vendor contacts, and the client decision maker before the first policy change. Confirm that the client owns each domain or has written authority to approve changes. Record confirmed non-sending domains separately so they can move to enforcement without active-sender remediation.
|
|
|
|
|---|---|---|---|
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 and flag it, but the client has to decide whether that sender stays. An unfamiliar IP address alone is not enough to approve a sender. Confirm it with message headers, the return-path domain, the DKIM signing domain, vendor configuration, and an internal owner.
?
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. A message fails DMARC when neither SPF nor DKIM produces an authenticated domain that satisfies the strict or relaxed comparison with the visible From domain. 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 policy record, verify authorization for any external aggregate-report destination, 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" Provider-hosted option, where supported: Host: _dmarc.client.example Type: CNAME Value: client-managed-dmarc.example
RFC 9989 removed the historic pct tag, so new scope templates should use evidence-backed policy changes instead of percentage rollouts. RFC 9990 now defines aggregate reporting, including authorization when reports go to a domain outside the policy domain. The scope should also state what happens when SPF, DKIM, or DMARC cannot be fixed quickly. Separate blocked items into client decisions, vendor dependencies, and MSP technical tasks so the rollout can continue 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. Quarantine and reject state the domain owner's requested handling, but receiving systems can apply local policy.
Managed DMARC rollout for MSPs: inventory, monitor, fix senders, client approval, and enforce.
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 unresolved senders have decisions.
Before enforcement, run sender audits and document every unresolved sender. If a high-value sender still fails, the scope should require an owner, a fix path, and a client decision to delay enforcement, move the mail to a dedicated subdomain with its own policy, or retire the sender.
Define change control and rollback
Production DNS and sender changes need a documented path. Scope should distinguish standard changes from emergency changes and name the approver, maintenance window, verification method, rollback trigger, and evidence retained in the ticket. Response targets should pause while the MSP waits for client approval or vendor action.
- Capture the current DNS value, TTL, report baseline, affected senders, and business owner before the change.
- Record client approval, the change window, the person implementing it, and the exact proposed value.
- Verify public DNS, send a controlled message through affected systems, and record the authentication result.
- Restore the prior value or lower the policy when the agreed rollback trigger occurs, then escalate to the named decision owner.
A rollback plan should name observable triggers, such as failed transactional mail or a material rise in DMARC failures for an approved sender. A generic promise to reverse the change is not enough for a service desk runbook.
Where Suped fits
Suped's product gives MSPs a shared workflow for monitoring, source review, issue detection, alerts, hosted records, and multi-tenant client management. Operators can move between client organizations, review an issue with its fix steps, and keep managed-record work inside the agreed service boundary.
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, change rules, and offboarding terms before the first DNS change. A common baseline is weekly internal review and monthly client reporting, with scope checked during the client's regular service review. Put alert response targets and immediate-escalation events in the service level agreement (SLA).
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.
