How to write DMARC monitoring into an MSP proposal
Updated on 8 Sep 2026: We updated this guide for RFC 9989 and added practical commercial terms, including SLA response targets and offboarding controls.
DMARC monitoring belongs in an MSP proposal as a managed email authentication service, not as a one-time DNS task. The proposal should define discovery, DNS record changes, source authorization, policy staging, alerting, monthly reporting, and support responsibilities. It should also state what the client must approve, which mail sources are in scope, and what happens before the domain moves to p=reject.
For MSP owners, the commercial value sits in the operational work: finding every legitimate sender, fixing broken SPF and DKIM, reducing the successful delivery of spoofed mail, and proving progress over time. The broader DMARC for MSPs model works because DMARC produces ongoing evidence and recurring exceptions, with a clear reporting cadence.
Write the proposal around client outcomes first, then map those outcomes to service delivery. That keeps the proposal concrete and avoids selling acronyms. The client sees what changes, who does the work, how risk goes down, and how they will know the service is working.
Start with the outcome clients understand
A good DMARC proposal starts with the business problem: attackers can send messages that use the client's domain in the visible From address. DMARC lets the domain owner request how receivers handle messages that fail aligned authentication and provides reporting for review. Avoid leading with TXT records. Lead with domain protection, sender visibility, and evidence that approved systems authenticate correctly.
The proposal should make one promise that your team can actually deliver: managed progression toward DMARC enforcement without breaking legitimate mail. That promise is stronger than saying you will publish a DMARC record, because the record alone does not tell you whether payroll, CRM, ticketing, marketing, invoicing, and line-of-business systems are authenticated. Do not guarantee inbox placement. Correct authentication and alignment remove one cause of filtering, but DMARC does not control every deliverability decision.
- Outcome: Reduce successful delivery of mail that spoofs the client's domain through monitored DMARC policy progression.
- Visibility: Identify legitimate and unknown senders using aggregate DMARC data and source review.
- Control: Fix SPF, DKIM, and domain alignment issues before enforcement affects valid mail.
- Reporting: Show monthly progress, remaining exceptions, and recommended next actions.
Proposal warning
Do not promise immediate enforcement unless discovery is complete. Write enforcement as a staged goal with explicit checkpoints, because some clients have mail sources that nobody documented during onboarding.
Define the scope before the technical work
Scope is where many MSP proposals get weak. A DMARC service touches DNS, identity, mail platforms, third-party senders, client approvals, and incident handling. If those boundaries are vague, the service turns into unpaid cleanup.
The proposal should name the domains, the records you manage, the reporting period, the policy target, and the support channel. If the client has subsidiaries or parked domains, state whether those domains are included or require a separate onboarding step.
In scope
- Domains: Primary sending domains and agreed subdomains listed in the proposal.
- Records: DMARC, SPF, DKIM, and related DNS entries needed for authentication.
- Operations: Monitoring, issue triage, sender review, alerts, and recurring reports.
- Policy: A staged move through none, quarantine, and reject when data supports it.
Out of scope unless added
- Unknown apps: Remediation for software the client did not disclose or approve.
- Vendor work: Custom integration work inside third-party systems outside managed access.
- Legal review: Compliance attestations beyond the service report unless separately agreed.
- Bulk cleanup: Historical domain consolidation, abandoned systems, and brand governance.
For a deeper service boundary, use a separate scope document or statement of work. A useful companion is a DMARC service scope that lists responsibilities before the client signs.
Run discovery before quoting the work
A proposal written before discovery should use cautious language. You can still sell the service, but the first phase should be assessment. That protects margin because the hardest part of DMARC is usually sender inventory, not publishing the first record.
Check the domain's current authentication state before writing the proposal. Suped's domain health checker gives the MSP a quick view of DMARC, SPF, and DKIM gaps before the sales conversation moves into delivery.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Discovery should produce a short list of client-specific risks. That list becomes proposal evidence. Instead of saying DMARC is important, show that the client's domain has no enforcement policy, missing DKIM on a sender, SPF lookup risk, or no reporting address.
Cloudflare DNS records screen showing DMARC, SPF, and DKIM entries.
- Current policy: Record the existing DMARC policy and whether reports are being collected.
- Known senders: List mail platforms, apps, devices, ticketing tools, and finance systems.
- DNS access: Confirm who can approve and publish authentication changes.
- Risk items: Note SPF lookup pressure, missing DKIM, and unauthenticated sources.
Demo prospecting report findings page showing email security score, risk level, and DMARC, SPF, and DKIM findings
Write the implementation phases
The proposal should split implementation into phases. This makes the work easier to approve and manage. A client does not need every DNS detail, but they do need to understand why enforcement waits until legitimate mail passes DMARC.
DMARC policy stages
A practical proposal should show how the domain moves through policy stages after evidence improves.
Observe
p=none
Collect reports, identify sources, and fix authentication gaps.
Contain
p=quarantine
Request quarantine handling after approved senders pass DMARC.
Protect
p=reject
Request rejection when reporting shows legitimate mail is covered.
Maintain
ongoing
Watch for new senders, DNS drift, and authentication failures.
A typical first record should collect aggregate reports and avoid enforcement until the sender inventory is known. Verify that the rua destination can receive and process reports before publishing it. RFC 9989 removed the pct tag, so proposal milestones should use explicit policy changes for a domain or subdomain instead of percentage-based rollout. If the client has many departments or vendors, slow the policy path and make client approvals explicit.
Starting DMARC record for monitoringtext
_dmarc.clientdomain.com TXT v=DMARC1; p=none; rua=mailto:dmarc-reports@clientdomain.com
Implementation language
State that policy progression depends on observed DMARC results, sender owner approval, and successful remediation. That clause prevents the client from expecting p=reject before the environment is ready.
Make responsibilities explicit
DMARC projects stall when the MSP owns the technical work but the client owns the missing business context. The proposal should make responsibility visible. Your team can inspect reports and recommend fixes, but the client often needs to confirm whether a sender is legitimate.
|
|
|
|---|---|---|
DNS access | Shared | Client grants access or approves changes. |
Sender review | Shared | MSP flags sources, client confirms use. |
Record changes | MSP | MSP publishes approved SPF, DKIM, and DMARC updates. |
Policy approval | Client | Client approves quarantine and reject milestones. |
Monitoring | MSP | MSP reviews alerts, issues, and monthly reports. |
Use simple ownership labels so the client knows where approvals sit.
Suped's product supports this operating model through its MSP and multi-tenancy dashboard. Teams can manage client organizations, domains, authentication status, alerts, and reports in one place, which makes the service easier to deliver through a repeatable workflow.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Set commercial terms and service levels
A managed DMARC proposal needs commercial limits around recurring work. Separate one-time onboarding from ongoing monitoring, then define the response clock, included remediation, client dependencies, and work that requires a change request. Tie the recurring fee to the agreed domain inventory or service bundle so newly added domains do not enter scope by assumption.
|
|
|---|---|
Onboarding fee | Cover discovery, the baseline report, sender inventory, and initial approved DNS work. |
Recurring fee | Price the agreed active domains or bundle and state how subdomains and parked domains are counted. |
Response target | Start the clock when monitoring creates an alert or the service desk receives a request, and state covered hours. |
Included remediation | Set an included time or change allowance for DNS work and sender coordination. |
Client dependency | Pause delivery milestones while required access, sender decisions, or policy approvals remain outstanding. |
Change control | Route undisclosed senders, custom vendor work, and extra domains through the agreed change process. |
Data and offboarding | Define report retention, export format, access removal, and transfer of reporting destinations when the service ends. |
Adapt each term to the MSP's staffing model and contract.
Set the response clock carefully
Do not promise 24/7 response for DMARC changes unless the service is staffed for it. Aggregate reports arrive after each receiver's reporting period, so measure MSP response from alert creation or report receipt, not from the time an underlying message was sent.
Add reporting and success metrics
Reporting should be part of the proposal, not an afterthought. Clients keep paying for managed services when they can see risk reduction, completed work, and remaining decisions. A DMARC report should show authorized mail volume, authentication results, unresolved sources, policy status, and recommended next actions.
Example progress view
Use progress metrics to show how the domain moves toward enforcement over time.
Authorized
Needs review
Unauthorized
Unknown
Good reporting also gives account managers a reason to speak with clients about security progress. If the client has executive or board reporting and compliance needs, add a monthly or quarterly summary. A separate guide to DMARC progress reports can help turn raw authentication data into client-ready updates.
Demo client report summary page showing total emails, authorized delivery, threats blocked, and email volume trend
- Authentication: Show SPF and DKIM results plus DMARC pass rates by source.
- Policy: Show the current policy, target policy, and decision needed for the next stage.
- Exceptions: List sources still needing remediation or business owner confirmation.
- Reputation: Include blocklist and blacklist findings when domain or IP reputation needs attention.
Use proposal language clients can sign
Effective proposal wording is specific enough for delivery and plain enough for a non-technical buyer. It should not read like a DNS tutorial. It should describe a managed service with clear phases, acceptance points, and exclusions.
Sample proposal wordingtext
Managed DMARC monitoring and enforcement We will monitor DMARC aggregate reports for the agreed client domains, identify authorized and unauthorized sending sources, and recommend required SPF, DKIM, and DMARC changes. We will stage DMARC policy changes from monitoring to enforcement after legitimate mail sources pass DMARC and the client approves the policy milestone. The service includes issue triage, DNS change recommendations, sender review support, alert review, and monthly reporting. Client approval is required for new sender authorization, DNS changes where client-controlled, and movement to quarantine or reject policy.
If you offer tiered service packages, keep the DMARC proposal tied to operational depth rather than public price points. Entry tiers can cover monitoring and reports. Higher tiers can include active remediation, hosted DNS management, policy staging, and executive reporting.
Contract wording that protects delivery
Add a clause that new sending services must be reported to the MSP before use. This reduces surprise failures after the domain reaches p=quarantine or p=reject.
Where Suped fits in the service
Suped is the product behind the managed service. The MSP can use it to monitor client domains, interpret DMARC data, triage issues, configure alerts, manage hosted records, and create client-ready reports.
Describe Suped's product as the management layer for DMARC monitoring, issue detection, source review, and reporting. When the client needs policy management without repeated DNS edits, Hosted DMARC gives the MSP a simpler way to stage approved policy changes.
Manual-only delivery
- Data: Reports need manual parsing before the MSP sees useful patterns.
- Alerts: Failures depend on someone checking reports at the right time.
- Scale: Each client becomes a custom process with more room for drift.
- Reporting: Account managers need extra effort to turn data into updates.
Suped-backed delivery
- Data: DMARC, SPF, DKIM, source, and issue views sit in one platform.
- Alerts: Configured alerts help the team react when new report data shows a problem.
- Scale: MSP dashboards support multiple clients and domains.
- Reporting: Client reports turn authentication progress into a repeatable review.
The proposal should still be written as your managed service. Suped is the product used to deliver the workflow consistently, including DMARC policy monitoring, authentication issue detection, hosted SPF and DMARC management where appropriate, blocklist and blacklist checks, and client reporting.
A proposal clients can approve
A strong MSP proposal for DMARC monitoring has a simple structure: state the risk, define the managed outcome, list the domains, show the phases, assign responsibilities, set commercial terms, and describe reporting. That gives the buyer enough confidence to approve the service and gives your operations team enough detail to deliver it.
The most important choice is to avoid selling DMARC as a quick DNS edit. Sell the managed process: discover, monitor, fix, enforce, and maintain. That is the work clients often cannot handle reliably without help, and it is the part an MSP can turn into a recurring security service.
