What should an MSP collect before starting client DMARC remediation?

An MSP should collect the client and domain scope, client approver, DNS owner, known sending paths, public-record evidence, sender ownership, proposed actions, approval state, validation result, exception owner, and review date. The purpose is to create a traceable operating record, not to assume that one DNS result proves the production path.

Does a public DMARC check prove that a client's mail is fixed?

No. A public DMARC check can inspect published DNS evidence. It does not prove that every sending platform uses the intended configuration, that an exact production message path authenticated, or how a receiving mailbox provider will handle a future message.

Who approves a client DMARC remediation change?

The client should approve changes that fall outside the authority delegated to the MSP. The MSP can prepare evidence, coordinate the change, and document validation. The DNS host and sending-platform owner control their systems unless the client has explicitly delegated that access.

When should an MSP keep a remediation item as an exception?

Keep an item as an exception when required evidence, ownership, approval, or a safe test path is missing. The record should name the exception owner, explain the decision or blocker, and include a future review date.

Can aggregate reports replace a delivered-message check?

No. Aggregate reports can help identify sources and prioritize remediation. A delivered-message check remains useful when the question concerns the authentication result for an exact production path.

Client DMARC remediation workflow

A client DMARC remediation workflow gives an MSP one repeatable way to turn domain evidence into owned work across a portfolio. Create a record for each client domain, separate observed evidence from assumptions, assign each issue to the party that controls it, obtain client approval before DNS changes, validate the real sending path, and keep unresolved items in an exception register.

At a glance

Quick takeaways

A portfolio workflow needs a separate evidence record for every client domain and sending path.
Public DNS checks are useful intake evidence, but they do not prove a production message path.
The MSP can coordinate remediation, while clients, DNS hosts, and sending platforms retain distinct responsibilities.
Client approval should be recorded before a controlled DNS change or a change to a sender configuration.
An exception remains active until it has an owner, a decision, and a future review date.
This workflow is a Palisade operating framework, not an external DMARC requirement.

Operating context and ownership

This workflow is for an MSP or multi-client IT team that manages recurring DMARC remediation work. It differs from a single-domain checklist because each client has separate approval rights, DNS access, sending systems, business-critical mail flows, and escalation paths.

The MSP owns the operating record: intake quality, evidence collection, issue triage, coordination, change documentation, and recurring review. The client owns business decisions, authorization, and any access that the service agreement does not delegate. The DNS host publishes approved record changes. A sending-platform owner controls that platform's authentication settings and can provide a delivered-message sample. Receiving mailbox providers make their own delivery and policy decisions.

Use what is DMARC for protocol background. This article focuses on the service workflow around remediation rather than explaining the protocol itself.

Define the service boundary at onboarding. Record whether the MSP may prepare DNS changes, submit changes after written approval, configure a sender platform, or only provide evidence and recommendations. A technically correct recommendation can still remain blocked when authority is unclear.

Portfolio decision flow showing intake, evidence triage, client approval, controlled change, validation, and exception review — Source: Palisade.

Evidence to collect

Create one working record for every client domain. Keep the evidence source with the observation so a later reviewer can distinguish a public DNS answer from a client statement or a delivered-message result.

Collect:

Client name, business owner, technical approver, and escalation contact.
Domain and known sending paths in scope.
DNS host and the person or team authorized to approve changes.
Public DMARC, SPF, and DKIM evidence where relevant.
Sender owner, observed authentication evidence, and the next action.
Proposed change, approval state, validation result, and rollback condition.
Exception owner, reason, and review date.

Use the DMARC checker when the immediate question is whether a domain has a published DMARC record. These checks inspect public DNS evidence. They do not identify every legitimate sender, prove that a platform uses a configured record, monitor the client continuously, or prove a receiving provider's private delivery decision.

Keep the operating record portable enough to work in a PSA, ticket system, spreadsheet, or client report:

YAMLyaml

client: example-client
domain: yourdomain.com
evidence:
  dns_check: public record result
  message_path: redacted delivered-message result
  client_confirmation: known sender confirmed by client
owner: sender-platform-owner
next_action: request proposed remediation details
approval_status: pending-client-approval
verification_result: not-yet-tested
exception_owner: client-technical-approver
review_on: 2026-09-01

Treat this as a working framework. The field values should reflect the service agreement and the client's actual authority model, not a generic ticket label.

How to run the workflow

1. Confirm scope and ownership

Owner: MSP service owner. Input: Client domain list, contacts, service boundary, and known sending systems. Output: An approved scope record with a named business approver, technical approver, DNS owner, and escalation route.

Start with the domains the client expects the service to cover. Do not assume that a parent domain, subdomain, parked domain, or acquired brand domain belongs in the same remediation queue. Record exclusions and the reason for each exclusion.

Ask the client to identify important sending paths such as marketing, support, billing, application, and internal systems. Mark each path as client-confirmed, report-observed, message-verified, unknown, or retired. These labels prevent a one-time onboarding list from being mistaken for current production evidence.

2. Normalize evidence by domain and sender

Owner: MSP analyst. Input: Public DNS checks, aggregate-report observations, client inventory, and redacted delivered-message evidence where available. Output: A normalized sender and issue list with dated evidence.

Aggregate-report data can help identify sending sources and prioritize investigation. It does not replace a real delivered-message check when the question is whether an exact production path authenticated as expected.

For each observed source, record what is known and what remains unknown. An unrecognized source is an investigation item, not proof of unauthorized mail. A platform listed by the client is also not proof that it currently sends with the domain.

Use DMARC audit template for MSPs when the portfolio needs a consistent review artifact before remediation tickets are assigned.

3. Assign remediation to the controlling party

Owner: MSP analyst assigns; client, DNS host, or sender owner acts. Input: Normalized issue list and the defined service boundary. Output: One owner-specific remediation proposal per issue.

Write the issue in observable terms. For example, identify the domain, sender, available evidence, requested action, approval requirement, and test needed after the change. Avoid broad tickets such as "fix DMARC." They do not tell the recipient what they control or how the MSP will verify completion.

The sender owner may need to provide platform-specific configuration details or a new delivered-message sample. The DNS owner may need to publish an approved change. The client approver may need to accept an exception when the business cannot yet remediate a path.

4. Prepare a client approval package

Owner: MSP service owner. Input: Proposed remediation, evidence, affected business path, rollback condition, and test plan. Output: A client decision: approve, defer, reject, or request more evidence.

The approval package should state what will change, who will make the change, what evidence supports it, what can break, and how the team will recognize a failed result. Record the previous state before a change so the rollback path is clear.

Do not publish a DNS or sender-configuration change based only on a green public-record check. Confirm that the client has approved the change and that the affected sending path has a defined retest.

For a portfolio policy change, use DMARC policy rollout across client domains to keep each client's approval and evidence separate from the broader portfolio target.

5. Make the controlled change and retain the record

Owner: Authorized DNS or sender-platform owner. Input: Client-approved change request and change window. Output: A dated change record with the before state, after state, actor, and rollback condition.

The MSP should record the approved change and the evidence needed for post-change review. The client, DNS host, or sender platform may perform the actual action depending on access and contract terms.

Do not turn a remediation proposal into an implied authorization. The client remains responsible for approvals outside the delegated service scope, and the sender platform remains responsible for its own configuration behavior.

6. Validate the same production path

Owner: MSP analyst, with the sender owner where needed. Input: Public DNS result, vendor status if available, and a real message from the affected production path. Output: A validation result or an exception with a next action.

Validate at the applicable layers:

DNS: Check the published record through the authoritative source and a public resolver where the service process permits.
Vendor: Record the sending platform's current authentication or verification result if the platform provides one.
Message: Review a redacted delivered message from the exact production path when the issue concerns actual authentication behavior.
DMARC: Review accumulated aggregate-report evidence after the relevant data becomes available.

A vendor indicator is not proof of a delivered-message result. A DNS lookup is not proof that an application is signing or using the intended path. Keep these layers separate in the client record.

Investigate this with your coding agent

Use this when the MSP already has redacted inventory, ticket, and runbook artifacts but needs a consistent remediation-register schema. Prepare only redacted examples and confirm that no active incident or client authorization decision is being delegated.

Agent handoff

Copy the prepared prompt

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

Problem: Build a proposed remediation register for a multi-client DMARC service where evidence, ownership, approval, validation, and exceptions are currently inconsistent.
Evidence: Redacted domain inventory, existing ticket fields, remediation runbook, DNS change templates, and example aggregate-report or delivered-message evidence with private data removed.
Repository scope: Inspect the approved MSP operations repository, read-only inventory exports, and remediation ticket schema.
Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, private keys, tokens, unredacted headers, customer data, DNS systems, PSA systems, or production incidents. Propose CSV or JSON fields for client/domain, sender, owner, authentication evidence, proposed change, approval status, verification result, exception owner, and review date.
Requested output: Diagnosis of current field gaps, a minimal proposed schema, mappings to existing artifacts, validation rules, rollback considerations, and unknowns.
Verification: Validate the proposed schema against redacted sample records and confirm that each record requires an owner, approval state, verification result, exception owner when blocked, and review date.
Stop if: Credentials, private data, client authorization, production mutation, an active incident, or missing redacted evidence 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

Keep an exception register for work that cannot safely move forward. An exception is not a closed ticket. It is a documented decision with an owner and review date.

Escalate when:

The client cannot confirm whether an observed sender is legitimate.
No party can demonstrate ownership of the DNS zone or sending platform.
The requested change affects a business-critical path without a safe test.
A sender owner cannot provide the evidence needed for validation.
The client defers a decision but the domain remains in scope.
A remediation result conflicts with the available production-message evidence.

The service owner decides how the item is handled within the agreement. The client approver accepts business risk or authorizes a change. The DNS host and sender platform control their respective systems. The receiving mailbox provider controls its own handling decision.

Use a simple decision path: if ownership is known and approval exists, proceed to the controlled change and validation. If evidence is incomplete, request the missing artifact and set a review date. If the client declines or cannot approve the work, retain the item as an exception and report it clearly.

Reporting and success measures

Use a monthly operational review and a client-facing quarterly summary. The monthly artifact should show domain status, open remediation work, evidence gaps, approvals pending, validation outcomes, and overdue exceptions. The quarterly summary should explain what changed, what remains blocked, and which client decisions are required next.

Measure service process health without treating one number as proof that every future message will authenticate:

In-scope domains with a named client approver and DNS owner.
Open remediation items with dated evidence.
Issues without an assigned controlling party.
Approved changes with recorded before state, after state, and validation result.
Exceptions without a future review date.
Domains where expected evidence stopped arriving.

Use DMARC QBR reporting: an MSP decision workflow to turn the operational register into a client decision document. Keep technical evidence in the service record and present decisions, risk, and ownership clearly in the client summary.

Turn client remediation records into a recurring service queue

A portfolio remediation workflow needs more than a one-time DNS check. Palisade is AI-first, agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy stage when the evidence indicates readiness, while a human reviews the evidence and applies the change.

Book a demo or start with Palisade to discuss a multi-client DMARC workflow built around domain ownership, remediation evidence, client approval, and exception review.

Palisade does not authorize client changes, change DNS policy without the required access and approval, prove every future message will authenticate, or guarantee how receiving systems handle mail.

Evidence