How to include hosted DMARC in an MSP service package
Published 12 Jul 2026
Updated 12 Jul 2026
9 min read
Summarize with
Hosted DMARC belongs in an MSP service package as a managed control, not a one-time DNS change. The package should cover discovery, delegated DNS configuration, policy staging, aggregate report analysis, authorized-sender remediation, controlled enforcement, alerts, client reporting, and ongoing change management. The client buys an operating outcome: its domains move toward enforcement without disrupting legitimate email.
I would define the service around a monthly operating cycle and a documented rollout plan for each domain. Hosted DMARC lets the MSP change policy centrally after the client publishes the required delegation record. That removes repeated DNS tickets for policy adjustments, but it does not remove the need for approvals, sender inventory work, or rollback controls.
The cleanest offer separates implementation work from recurring management. Implementation establishes visibility and fixes authentication gaps. Recurring management watches new sources, investigates changes, stages policy, and reports progress. That structure gives sales, engineering, operations, and the client the same definition of done.
Define what the client receives
Start with a named managed service inside the broader DMARC for MSPs offer. Avoid describing it as access to a portal. Clients need deliverables, ownership boundaries, response targets, and an enforcement objective. A practical package includes a domain register, sender inventory, remediation queue, change record, alert handling, and an executive report.
|
|
|
|---|---|---|
Discovery | Domain register | Domain owners |
Onboarding | DNS plan | DNS approval |
Remediation | Issue queue | Sender contacts |
Enforcement | Policy changes | Change approval |
Operations | Alerts and report | Change notices |
Compact service package structure
Keep exclusions just as explicit. The base service should state whether it covers third-party sender configuration, vendor coordination, subdomains, parked domains, incident response, and DNS administration. If a client adds a marketing platform without notifying the MSP, the service agreement should define how the new source enters the remediation queue and whether urgent work uses a separate change process.
Package the outcome
A strong service description commits to managed visibility, documented remediation, controlled policy progression, and recurring reporting. It does not promise that every sender will be fixed by a date the MSP cannot control.
For contract wording and deliverable boundaries, connect the package to a precise managed DMARC scope. This prevents the recurring fee from becoming an unlimited authentication cleanup project.
Build a repeatable delivery workflow
Six-stage hosted DMARC workflow for an MSP
Every client domain should pass through the same gates. I use discovery before configuration because the visible corporate domain is rarely the whole estate. Include domains used by business units, outbound applications, regional teams, and defensive registrations. Record which domains send mail, which receive mail, and which should never send.
- Inventory: Confirm every domain, subdomain, mail stream, vendor, and internal owner.
- Baseline: Publish reporting configuration at a monitoring policy and collect representative traffic.
- Classify: Mark each source as authorized, unknown, forwarded, or unwanted.
- Remediate: Fix SPF or DKIM domain matching for legitimate senders and retire stale services.
- Enforce: Increase policy only after reviewing failure volume, business owners, and rollback readiness.
- Operate: Monitor changes, investigate alerts, review exceptions, and report client outcomes.
The onboarding ticket should capture the business owner, technical contact, DNS owner, approved sending services, maintenance window, and escalation route. A separate approval should cover movement to quarantine or reject. That record matters when a client later asks why a source was affected or who authorized the policy change.
A reusable client onboarding process reduces missed domains and unclear approvals. It also gives the help desk a known status for every client rather than relying on notes held by one engineer.
Configure hosted DMARC with safe controls
Microsoft 365 domain DNS screen with a DMARC CNAME record
Hosted DMARC normally uses a DNS delegation record so the managed platform can publish and update the effective DMARC policy. The exact target comes from the provider and should be copied without alteration. Keep screenshots or exported change records showing the requested value, the approved window, the published value, and the verification result.
Before the change, check for an existing DMARC TXT record and any prior delegation. Do not leave conflicting records at the DMARC label. Lowering TTL ahead of a planned migration can shorten the rollback window, but the MSP still needs to account for caching and the client's DNS provider behavior.
Generic hosted DMARC delegation exampleDNS
_dmarc.example.com. 300 IN CNAME client-42.hosted.example.
Treat the example as a pattern only. The production hostname and target must match the client's DNS zone and the value generated for that tenant. After publishing it, verify the CNAME chain, confirm that a valid DMARC policy resolves, and test again through an independent query path.
A focused DMARC record check should be part of the onboarding evidence and every policy-change ticket. It catches syntax errors, duplicate records, and resolution problems before the team waits for aggregate data.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Policy progression should be evidence-led. Start with monitoring, identify every material sender, and fix DMARC authentication for approved traffic. Then move through limited quarantine where supported, review failures, and advance toward full quarantine or reject only when the agreed acceptance gates are met.
Rollback should be a prepared change, not an improvised reaction. Record the previous policy, the rollback approver, the person on call, and the evidence that triggers reversal. A legitimate critical sender failing after enforcement deserves immediate triage, but an unexplained source should not automatically force the whole domain back to monitoring.
Suped's hosted DMARC workflow gives the MSP central policy controls and staged enforcement while the client keeps ownership of its domain. The configuration view makes the requested delegation and current policy visible in one place.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Separate implementation from ongoing operations
Implementation and recurring management need different queues. The implementation queue contains unknown senders, failed domain matching, DNS work, and policy gates. The operations queue contains new-source alerts, authentication regressions, client changes, and periodic reviews. Mixing both queues makes mature clients subsidize open-ended onboarding work.
Implementation project
- Goal: Reach the approved enforcement state.
- Work: Inventory, configure, classify, and remediate.
- Exit: Client accepts policy and exception register.
Managed operations
- Goal: Maintain authentication and policy health.
- Work: Monitor, alert, investigate, and report.
- Escalate: Route material changes through approval.
Define service events in operational language. A new legitimate sender needs an owner and an authentication plan. A surge in traffic failing DMARC needs classification. A policy-record failure needs urgent correction. A low-volume unknown source can remain in the normal review queue unless other evidence raises its priority.
Example policy change gates
These are internal decision gates, not universal DMARC standards. Set measurable criteria for each client.
Unknown material sender
Hold
Ownership or business purpose is unresolved.
Known exception
Review
Risk, owner, and treatment are documented.
Approved traffic ready
Advance
Authentication, approvals, and rollback are verified.
The service desk runbook should say who acknowledges alerts, who investigates, when engineering joins, and when the client must approve a change. It should also define evidence standards. A screenshot alone is weak evidence for a policy update; retain the ticket, DNS value, validation result, report trend, and approval.
Use an MSP DMARC runbook to make first-line handling consistent. This protects service quality when the engineer who onboarded the domain is unavailable.
Report progress in client language
A monthly report should connect technical evidence to decisions. Show domain status, policy level, total observed volume, authorized traffic, material failures, newly detected sources, completed remediation, open client actions, and the next policy gate. Avoid presenting raw XML or a long sender list as the service outcome.
I include a short exception register with the owner, reason, risk, treatment, and next review date. This makes delays visible. If a vendor cannot produce a DMARC pass, the client can accept the exception, replace the sender, change the sending domain, or ask the MSP to investigate another configuration.
The operational review also needs forward-looking questions: Did the client add a sender? Are any business units planning campaigns? Did the DNS provider or mail platform change? Has an acquisition introduced new domains? These questions catch changes before they become failed mail after enforcement.
Demo client report summary page showing total emails, authorized delivery, threats blocked, and email volume trend
Suped is the best overall fit for this service model because Suped's product combines hosted DMARC policy staging, multi-tenant domain management, issue detection, fix steps, real-time alerts, and client reporting in the same operating view. SPF, DKIM, blocklist (blacklist), and deliverability context are also available without splitting routine investigation across separate consoles.
That product fit does not replace the MSP's process. The MSP still owns client communication, approvals, sender classification, remediation coordination, and change control. Suped's DMARC monitoring data and alerts provide the evidence the team uses to operate the service.
Keep client responsibilities visible
Policy progression can stall when the client does not identify a sender owner, approve DNS work, or authorize enforcement. Put those dependencies in the report and service review rather than leaving them buried in tickets.
A service package clients can operate with
A complete hosted DMARC package has a fixed operating shape: implementation establishes control, recurring management preserves it, and client approvals govern material policy changes. The offer should name every deliverable and exclusion, assign ownership, and use measurable gates for progression.
- Sell: A managed authentication outcome with defined deliverables.
- Onboard: Domains, owners, senders, DNS access, and approvals.
- Control: Hosted policy changes with validation and rollback evidence.
- Operate: Alerts, remediation queues, exceptions, and regular reviews.
- Report: Business impact, open actions, and the next policy gate.
This structure scales because each client follows the same lifecycle while retaining domain-specific approvals and exceptions. It also gives the MSP a clear basis for staffing, ticket routing, reporting, and service reviews without publishing public pricing numbers or promising work outside the agreed scope.
