What should a managed DMARC service SLA include?

A managed DMARC service SLA should include covered domains, evidence inputs, the MSP commitment, client and change-owner responsibilities, escalation triggers, exclusions, and review cadence. It should also identify the record used to preserve decisions and exceptions for each client.

Does an SLA let an MSP change a client's DMARC policy?

No. An SLA can define how the MSP presents evidence and coordinates an approved change. The client and delegated DNS or sender owner must still authorize and apply changes to their environment.

Can aggregate reports prove a sender is authorized?

No. Aggregate reports provide receiver-observed authentication and policy data. They can identify a source for investigation, but client business context and sender-owner confirmation are still needed to authorize that source.

Should every client have the same response target?

Not necessarily. A shared record structure makes work comparable, but response commitments should reflect the client's domains, contacts, service scope, and risk acceptance. Do not turn a framework example into an implied contractual target.

What belongs in a managed DMARC exception?

An exception should identify the affected domain or sender, the evidence gap or accepted risk, the client approver, an expiry, and the next review. That makes a deferred decision visible rather than letting it disappear from the operating record.

Managed DMARC service SLA

A managed DMARC service SLA should define the domains covered, the evidence that starts work, the MSP's response commitment, the client's approval duties, and the outcomes outside the service's control. For a multi-client portfolio, use the same record for each domain but keep sender authorization, DNS changes, and DMARC policy decisions with the client. RFC 9989 defines the protocol, not service-level targets.

At a glance

Quick takeaways

State whether the SLA covers monitoring, investigation, change coordination, reporting, or only selected domains.
Start an obligation from a recorded observation, ticket, or approved change request rather than an assumed sender or threat.
Separate an MSP recommendation from the client approval required to change DNS, sender settings, or DMARC policy.
Make exclusions explicit: receiver decisions, sender-vendor fixes, and delivery outcomes are not controlled by the SLA.
Review open exceptions by client, domain, owner, and next review date.

Operating context and ownership

This framework is for an MSP operating DMARC across multiple client domains. The service lead owns the SLA record and client communication. An authentication specialist reviews report evidence. The client service owner confirms business purpose and accepts risk. The DNS or sender owner applies approved changes. One person may fill more than one role, but each responsibility should still be named.

DMARC aggregate reports are feedback about receiver-observed mail and policy results, not a list of pre-authorized services. RFC 9990 defines the aggregate-report data model. The service model below is a Palisade operating recommendation, not an RFC requirement or a guaranteed response time.

Evidence to collect

Create one service record for every material item. It should preserve the observation, the commitment that applies, and the decision still needed. A sender inventory provides the supporting ownership record, so link the SLA item to the relevant MSP email sender inventory entry rather than accepting a provider name as proof of authorization.

YAMLyaml

client: "Northwind Manufacturing"
domain: "example.invalid"
service_area: "aggregate-report review"
evidence: "new source with repeated DMARC failure"
recorded_at: "2026-07-29"
msp_commitment: "classify evidence and request owner context"
client_responsibility: "confirm sender purpose and approve any change"
escalation_trigger: "business-critical sending path may be affected"
excluded_outcome: "receiver delivery decision"
next_review: "2026-08-05"

The values are illustrative. They do not prescribe an SLA clock, a risk threshold, or an account configuration. Where an item needs a policy decision, compare the observation with the domain's current policy and alignment rules in RFC 9989 before asking for a change.

Managed DMARC SLA matrix showing evidence input, MSP commitment, client responsibility, escalation trigger, and excluded outcome. — Source: Original deterministic Palisade operating framework based on RFC 9989 and RFC 9990. It illustrates service boundaries, not a protocol requirement. Open the full-size SLA matrix.

Use the matrix to write the agreement in operational language. For example, “review” means classify the supplied evidence and ask a focused question. It does not mean that the MSP authorizes a sender, changes a DNS zone, or promises that a receiver will accept mail.

How to run the workflow

1. Define the client and domain scope

List the covered domains, sender populations, report destinations, service hours, and named client contacts. Then state what is outside scope, such as domains managed by another provider or sender-vendor remediation. The scope should distinguish ongoing review from the separate implementation work in Managed DMARC setup.

2. Classify the evidence before promising an action

Record whether the trigger is an aggregate-report observation, a client ticket, a planned sender change, or a missed review. A report can show a source and an authentication outcome, but the client or sender owner still supplies the business context. Give the item a status such as evidence-limited, awaiting owner confirmation, approved for change coordination, or exception. This prevents a generic alert from becoming an unapproved configuration task.

3. Apply the matching service commitment

For a routine observation, commit to reviewing the record and requesting missing context. For a suspected impact to a critical sending path, commit to notifying the named client contact and preparing a scoped decision. For approved changes, commit to coordination and a post-change evidence check. Do not write a blanket “resolve” commitment unless the agreement also names the systems and authority needed to resolve it.

4. Obtain the client decision and hand off the change

Present the evidence, recommendation, possible consequence, and proposed owner. The client decides whether a sender remains authorized and whether a change is acceptable. The DNS or sender owner performs the external change. Use the DMARC QBR reporting workflow to carry open decisions and their dates into the recurring review, instead of treating an SLA acknowledgement as closure.

5. Recheck and close the service record

After an approved change, recheck the relevant public record, delivered-message evidence when available, and later aggregate-report data. Close the record only when the agreed evidence has been reviewed. If the observation persists or evidence is unavailable, retain it as an exception with an owner and review date.

Portfolio escalation flow from receiver observation through MSP classification, client decision, approved change coordination, and later evidence review. — Source: Original deterministic Palisade operating framework based on the RFC 9990 aggregate-report model. It is a decision flow, not evidence that a receiver will take a specific action. Open the full-size escalation flow.

Investigate this with your coding agent

When the SLA record already points to a client-approved, non-production runbook repository, an agent can check whether the template preserves the same fields for every tenant. Provide redacted examples only.

Agent handoff

Copy the prepared prompt

Give this to a coding agent that can inspect the relevant repository or configuration source of truth.

Problem: Review a non-production managed-DMARC SLA template for missing ownership, exception, and approval fields.
Evidence: A redacted SLA record, a redacted exception register, and the current template path.
Repository scope: The client-approved non-production runbook or policy-template repository only.
Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, client data, production DNS, or another tenant's files.
Requested output: Identify missing fields, propose the smallest template diff, explain affected workflow steps, and include rollback instructions.
Verification: Run the repository's template tests or render a redacted fixture and compare required fields.
Stop if: Client approval, credentials, unredacted data, cross-tenant access, or a production mutation is required.

Human approval required: Review the proposed diff and verification plan before allowing changes. Do not paste secrets, private keys, API tokens, unredacted headers, or customer data.

Exceptions and escalation

An exception should name the affected domain or sender, the missing evidence or accepted risk, the client approver, the expiry, and the return path. A temporary exception is not permission to broaden SPF, DKIM, or DMARC policy. Keep the record open when the sender owner cannot explain the path, when a client has not approved a change, or when a change could affect legitimate mail.

Escalate a material item when an unfamiliar source recurs, a critical sending path may be affected, or a policy decision could broaden the impact of a failure. The escalation package should contain the report period, observed identity and result, prior changes, a recommendation, and the decision requested. The MSP can coordinate that package; it cannot determine sender authorization or make the external change without the delegated owner.

Reporting and success measures

Report service performance as operational evidence: covered domains with a named owner, items waiting for client input, open exceptions with a future date, and approved changes that received a later evidence check. Do not use a portfolio-wide “DMARC success” score that hides unresolved domains or implies a delivery guarantee.

For commercial packaging, keep the SLA's commitments separate from price and tier design. The MSP DMARC management pricing guide covers that commercial decision. A recurring review process can then connect each client record to the right service tier without changing its approval boundary.

Turn the SLA record into recurring evidence work

If your team has repeated sender and alignment items across clients, Palisade's DMARC Agent guidance describes turning aggregate-report findings into source-specific authentication tickets with recommended actions. It does not authorize senders, change client DNS, approve DMARC policy, or guarantee delivery.

Start with Palisade

Evidence