Introduction
The hardest conversation in DMARC-as-a-service isn't the technical rollout — it's the conversation at month four when a client asks why a brand acquisition that touched three new domains isn't covered by the contract. The answer to that conversation lives in the Master Service Agreement and Statement of Work, written before the work starts. This article is the contract-language companion to the DMARC for MSPs pillar: what to put in scope, what to put out of scope, how to write change control that doesn't bleed margin, and the exit clauses that protect both sides.
This article doesn't replace your legal counsel. It's the operational starting point that lets the legal conversation happen efficiently, with the technical realities mapped out clearly enough that the lawyers can draft the actual clauses.
Why this topic matters
Most MSP DMARC engagements don't fail technically — the technical work is well-understood and repeatable. They fail commercially, at the boundary between "we agreed to do this" and "we agreed to do that other thing too, didn't we?" A well-scoped MSA / SOW prevents most of those conversations. A badly scoped one means the MSP eats the cost of every ambiguity, every time, until the engagement becomes unprofitable enough that someone proposes ending it.
The artefact pays for itself the first time a client asks whether the new sub-domain they spun up for the marketing campaign is included.
The MSA vs SOW split
Most MSP practices use a two-document model:
Master Service Agreement (MSA). The long-lived umbrella covering the relationship: payment terms, IP ownership, confidentiality, indemnification, liability caps, dispute resolution, exit conditions. Signed once, lives for years, doesn't change per engagement.
Statement of Work (SOW). The specific engagement: what DMARC tier, what client domains, what timeline, what milestones, what's in scope versus out, what the change-control mechanism looks like. Re-issued for each engagement and any material scope change.
This article is mostly about the SOW. The MSA-level provisions specific to DMARC are at the end.
What's in scope: the explicit list
The SOW should enumerate, by name, every client domain covered by the engagement. Not "all client domains" — every domain, listed. The format that works:
“` Covered domains (Tier 2 active management):
- clientco.com
- clientco.eu
- clientco-marketing.com
Covered domains (Tier 1 monitoring only):
- clientco-legacy.net
- clientco-archive.com
“`
Why explicit naming matters: clients add domains. They acquire companies. They spin up new sub-domains for marketing campaigns. They register country-code TLDs after a strategy review. Without explicit naming, every one of those becomes "is that included?" — and you have to negotiate the answer in the middle of the work, when both sides are already invested in keeping the engagement going.
Pair the domain list with the tier assignment (which domain gets which level of service) and the per-domain pricing (whether per-domain pricing applies). This is the line item the client sees on their invoice; it should match the line items in the SOW exactly.
What's out of scope: the explicit exclusions
The mirror image of the scope list. Be specific about what isn't included so the conversation about scope additions happens before the work starts, not after.
Standard exclusions:
- New domains the client adds during the engagement (handled via change order; see below).
- Domains acquired through M&A activity during the engagement.
- Sub-domain delegations the client makes to third-party platforms during the engagement.
- Inbound email security configuration (Defender for 365 anti-spam policies, Workspace Gmail filters, etc.) — DMARC is outbound authentication; inbound is its own scope.
- BIMI rollout if it isn't explicitly in the SOW. BIMI has its own SKU and its own pricing.
- Client-side DNS provider migration. If the client moves DNS providers mid-engagement, the work to re-establish DKIM and SPF on the new provider is a change order, not included scope.
- Custom integrations into client systems (PSA, SIEM, SOAR) beyond standard platform exports.
- Training of client staff on the platform or on DMARC operationally.
- Incident response for breaches unrelated to email authentication.
The exclusion list isn't adversarial. It's clarifying. A client who reads it and asks "what about X?" is having the right conversation at the right time.
Change-control language
Change orders are how scope additions get added to the engagement without renegotiating the whole SOW. The language that holds up:
“` Scope changes during the engagement will be handled via written Change Order. Each Change Order will specify:
- The scope addition or modification
- The impact on engagement timeline (if any)
- The fee for the additional work (fixed or hourly basis)
- Whether the addition flows into the recurring Tier 3 scope after
the rollout completes
Change Orders take effect on written acceptance by both parties. Work under a Change Order will not begin until acceptance. “`
The "won't begin until acceptance" clause is the one that protects margin. Without it, a chatty client can verbally request scope additions that the MSP feels obligated to honor, and then resist paying for them because there was no formal acceptance.
A useful pattern: bundle small change orders. A new sub-domain or a single new SaaS sender is small change-order territory; bundle three or four of them into a single quarterly change order rather than processing each individually. Reduces administrative friction without giving away scope.
Liability and indemnification clauses
DMARC at p=reject carries non-trivial risk during the rollout: a misconfigured authentication chain can bounce legitimate client mail. The contract has to allocate that risk explicitly.
The pattern that holds up across most MSP MSAs:
Limited liability cap. The MSP's total liability under the engagement is capped at the fees paid in the preceding twelve months (or some similar fixed figure). This is standard MSA language and not specific to DMARC.
Carve-outs for negligence. Gross negligence, willful misconduct, breach of confidentiality, and (sometimes) breach of data-protection law are typically carved out of the liability cap. This is also standard.
DMARC-specific carve-out. A clause acknowledging that DMARC enforcement at p=quarantine or p=reject may result in legitimate mail being deferred or rejected during the rollout, and that the client agrees to the phased rollout approach (with rollback windows) as the operational mitigation for that risk. This protects the MSP from being held responsible for the inherent risk of the work the client hired them to do.
Hold-harmless for client-caused changes. If the client (or a third party the client engages) makes changes to DNS records, mail-routing configuration, or sender configuration during the engagement without notifying the MSP, the MSP is held harmless for the consequences. This is the clause that prevents "the marketing team changed our SPF and then your DMARC rollout broke our newsletter" turning into a credit demand.
Exit clauses and offboarding
The cleanest engagements are the ones where the exit is clear before the entry. Two pieces of exit language matter:
Termination for convenience. Either party can terminate with 30-60 days' written notice. On termination, the MSP completes a defined offboarding process (handover documentation, RUA endpoint cutover, etc.) for a defined fee. The full mechanics of the offboarding live in the tenant offboarding article.
Termination for cause. Material breach (non-payment, gross misconduct, etc.) with a defined cure period. Standard MSA language.
What survives termination. Confidentiality, IP ownership of any tools or documentation produced for the engagement, liability provisions for past work. Standard MSA language.
The offboarding fee is worth being specific about. A clean offboarding involves real work — RUA cutover, documentation handover, decommissioning monitoring — and free offboarding incentivizes clients to leave the moment they think they could run it themselves. Charge for it; the fee covers the work and creates a small disincentive for casual churn.
MSA-level DMARC provisions
A few clauses specific to DMARC that belong in the MSA rather than the SOW because they're long-lived:
DNS record ownership. The MSP publishes DNS records on the client's behalf during the engagement. Ownership of those records (in the legal sense) remains with the client; the MSP holds operational responsibility under the engagement, not legal ownership. This matters at termination — the records stay with the client.
Data handling for aggregate reports. Aggregate DMARC reports contain operational data about the client's email infrastructure. The MSA should specify where this data is stored (which jurisdiction), how long it's retained, who can access it, and what happens to it at termination. EU clients will care; non-EU clients should care.
Right to audit. Enterprise clients sometimes want the right to audit the MSP's operational controls. Including the right (with reasonable notice and a defined scope) is usually easier than negotiating it later when the enterprise client asks for SOC2 evidence.
Subcontractor disclosure. If the MSP uses subcontractors (a junior analyst from a partner firm, an offshore SOC, a fractional consultant), the MSA should require disclosure. Some enterprise clients require approval; most just want visibility.
Common scoping pitfalls
- "All client domains" as the scope clause. Looks comprehensive, drives ambiguity. Always enumerate.
- No change-control mechanism. Either you process every scope addition as an emergency or you eat the cost of every scope addition silently. Neither scales.
- Implicit BIMI inclusion. Clients hear "DMARC service" and think it includes BIMI because BIMI requires DMARC. It doesn't. Be explicit that BIMI is a separate engagement.
- No offboarding fee. Free offboarding sounds generous; in practice it incentivizes premature termination and adds work the engagement never priced for.
- Vague tier language. "Active management" means different things to different MSPs. Define what's in each tier in the SOW so the deliverable is unambiguous.
- No SLA on report cadence. If the SOW promises "monthly reporting" without defining what monthly means (calendar month? business day?), every late report becomes a small argument.
Step-by-step approach
- Draft the MSA with legal counsel for the long-lived umbrella provisions. Cover DMARC-specific risk allocation explicitly.
- Build a SOW template per service tier. Each SOW reuses the template with client-specific scope, domain list, and pricing.
- Run the first three SOWs by legal to validate the template. After that, the template should hold for most engagements.
- Establish a change-order template that flows into both the engagement scope and the billing system.
- Build the offboarding workflow alongside the SOW template. Knowing what offboarding looks like at SOW signing reduces friction at termination.
- Revisit annually. Legal language drifts; market expectations drift; the technical reality drifts. An annual review keeps the template current.
Best practices
- Enumerate domains explicitly. Never use "all client domains" as scope.
- Define every term you'll bill against. "Active management" needs a definition.
- Use change orders for scope additions. They're cheap to process and they prevent margin bleed.
- Carve out DMARC enforcement risk in liability language with the rollback-window mitigation.
- Charge for offboarding. It's real work and the fee disincentivizes casual churn.
- Annual SOW refresh for enterprise clients. Aligns with their procurement cycle and gives both sides a moment to recalibrate scope.
Recommended next step
If your current MSA / SOW doesn't enumerate client domains explicitly, that's the first fix. Add the domain list as an appendix that can be updated via change order without re-signing the SOW. Most other improvements compound off that change.
FAQ
Can I use a single document for both MSA and SOW?
You can, but the moment you have a second engagement with the same client (a new tier addition, a BIMI rollout, an incident response engagement), the single-document model breaks. Splitting MSA and SOW from the start saves the rework.
What about clients who insist on their own MSA?
Common with enterprise clients who have their procurement framework. Use their MSA; insist on your SOW. Most enterprise MSAs accommodate a vendor's own SOW format as an exhibit.
How do I handle clients with frequent M&A activity?
Define a "domain addition" change-order template up front. Each acquired domain flows through the standard change order. Don't try to write "all current and future domains" into the SOW — it sounds simple and creates expensive ambiguity.
What's a reasonable offboarding fee?
Roughly 30-50% of one month's recurring revenue, covering RUA cutover, documentation handover, and platform decommissioning. Higher for enterprise clients with multiple domains; lower for single-domain SMB.
Should the SOW reference specific DMARC policies?
It can reference target end state ("p=reject by week 12") but shouldn't lock the operational decision to a calendar date. The rollout cadence depends on what discovery surfaces. The change-control language handles cases where the target slips for reasons within the client's control vs the MSP's.
What if the client wants to see the SOW before signing the MSA?
Show them a sample SOW with redacted client information. Don't issue a real SOW before MSA signature; the SOW assumes the MSA's risk-allocation framework.
Final thoughts
The MSA / SOW is the artefact that lets the technical work happen without the commercial work eating it. Spend the time on the contract before the engagement; the conversations you save during the engagement are worth multiples of the upfront drafting time.
The clients who balk at a well-scoped SOW are the clients who would have balked later at the change orders. Finding out at signing is cheaper than finding out at month four.