# DMARC policy rollout across client domains > DMARC policy rollout across client domains needs an approval-gated MSP workflow for ownership, evidence, exceptions, verification, and reporting. A DMARC policy rollout across client domains needs a portfolio workflow, not a repeated DNS task. An MSP should establish client authority, collect domain and sender evidence, assign each domain to an approval-gated wave, record exceptions, and keep verification evidence with every proposed policy change. This is a Palisade operating framework for multi-client coordination. It is not a replacement for the controlling DMARC standard, sender documentation, or client approval. ## Quick takeaways - Keep each client's domains, evidence, approvals, and exceptions separate. - A published-record check can confirm public DNS, but it cannot confirm sender ownership or a receiver's delivery decision. - Use rollout waves to prevent one client's readiness from becoming another client's deadline. - Record the owner, evidence, next action, review date, and rollback decision for every blocked domain. - Treat a proposed DMARC policy change as a client-approved change request. - Report portfolio progress as dated evidence and open decisions, not as a universal protection score. ## Operating context and ownership A multi-client rollout has several control boundaries. The MSP can maintain the operating record, collect evidence, coordinate remediation, and prepare a proposed change. The client decides what business sending is authorized and approves changes within the agreed service boundary. The DNS host publishes records. Each sending platform controls its own authentication configuration. Receiving mailbox providers make their own message-handling decisions. This division matters when one service desk manages dozens of domains. A domain can have a valid public record while its client has not confirmed a low-volume sender. Another client may have confirmed its senders but lack an authorized DNS change owner. Those are different blockers and should not sit in one undifferentiated queue. Use one service record per client domain. Give every record a named client approver, MSP owner, DNS change owner, and sender owner where applicable. The [Palisade MSP workflow](/for-managed-service-providers) is the appropriate discussion when this becomes a recurring portfolio service rather than a one-domain task. The framework below is Palisade operating guidance, not an external DMARC requirement. Its purpose is to make authority, evidence, and pending decisions visible before a client change is proposed. ![Portfolio rollout workflow showing separate client evidence records, approval-gated waves, exception handling, and post-change review](/images/editorial/dmarc-policy-rollout-across-client-domains/dmarc-policy-rollout-across-client-domains-portfolio-workflow.webp "1200x829") *Source: Palisade.* ## Evidence to collect Start with an intake record that distinguishes reported facts from assumptions. A client-provided sender list is useful, but it is not the same as evidence from a delivered production message or a reporting source. Keep those states separate so an MSP does not close work based on an untested statement. Collect these fields for each domain: - Client name and named technical approver. - Domain and any known related sending domains. - DNS provider, change owner, and approved change path. - Known sending platforms and the business owner for each one. - Public-record evidence, dated when collected. - Redacted delivered-message evidence when the production path must be confirmed. - Open exception, affected business process, owner, next action, and review date. - Proposed rollout wave, approval status, verification check, and rollback note. Use a portable record that can live in a PSA ticket, service register, or client report: ```yaml client: example-client domain: yourdomain.com evidence: public_record: checked-YYYY-MM-DD sender_inventory: client-confirmed delivered_message: pending-redacted-sample owner: msp-service-owner next_action: confirm-sender-owner-and-change-approval review_on: YYYY-MM-DD rollout_wave: evidence-review approval_status: pending rollback_note: client-approved-reversal-path-required ``` A [DMARC record check](/tools/dmarc) is useful when the immediate question is what record is publicly visible for a domain. It cannot prove that a listed platform is an authorized client sender, that the platform uses the expected production path, or that a mailbox provider will handle a future message in a particular way. For a single-domain repair where no policy is published, see [how to address a DMARC policy that is not enabled](/resources-post/resolving-the-issue-dmarc-policy-not-enabled). Portfolio work adds tenancy, approvals, exception ownership, and reporting to that narrower task. ## How to run the workflow ### 1. Establish client scope and authority Owner: MSP service owner. Input: client domain list, contacts, and service agreement. Output: a scoped portfolio record with named approvers and escalation contacts. Confirm which domains are in scope and who can authorize business-sender decisions and DNS changes. Record whether the MSP may only recommend changes or may prepare them for client approval. Do not begin a policy wave for a domain with unclear authority. ### 2. Create separate evidence records Owner: MSP analyst. Input: public DNS results, client sender inventory, and redacted message evidence where available. Output: one dated evidence record per domain. Do not merge evidence across clients just because domains use the same sender. A sender can be authorized for one client and unknown for another. Label the source of each item, such as `client-confirmed`, `public-record`, `message-verified`, `unknown`, or `retired`. ### 3. Classify work into portfolio waves Owner: MSP service owner with client approver. Input: evidence records and open exceptions. Output: an approval-gated work queue. Use operational states such as `intake`, `evidence-review`, `remediation-pending`, `client-approval`, `post-change-review`, and `blocked`. These are workflow states, not protocol-defined DMARC phases. Place domains in a wave only when their evidence and owners are sufficient for the next proposed action. A high-volume unknown sender, a missing DNS owner, and a client awaiting approval should each remain visible for different reasons. ### 4. Assign remediation to the controlling party Owner: the party that controls the observed gap. Input: dated evidence and a specific observed issue. Output: an owner-specific ticket with a retest condition. The MSP should describe the gap and the completion evidence without assigning a technical cause that the available evidence does not prove. Ask the client to confirm business authorization. Ask the sender owner for the configuration evidence it controls. Ask the DNS owner for the approved change record after a client-approved update. A useful ticket states the domain, observed evidence, responsible party, requested action, and the exact retest. “Review sender ownership for yourdomain.com and provide a redacted delivered-message sample after the approved configuration change” is testable. “Fix DMARC” is not. ### 5. Request approval for each proposed change Owner: client approver. Input: current record evidence, sender evidence, exceptions, proposed change, verification plan, and rollback note. Output: recorded approval or rejection. A client policy change should have its own decision record. Include the prior public value, proposed value, intended publication owner, effective time, verification method, and the condition that would trigger a rollback discussion. Do not treat a portfolio target as approval for an individual client domain. > Do not publish a client DNS change based only on a dashboard indicator or a public lookup. Confirm the approved record, the responsible change owner, and the required same-path evidence first. ### 6. Validate the completed wave Owner: MSP analyst and client approver. Input: authoritative DNS evidence, public resolver evidence, vendor status where applicable, redacted delivered-message evidence, and later reporting data. Output: a dated post-change review. Use four independent layers where they apply: - DNS: confirm the published result with the authoritative source and at least one public resolver. - Vendor: review the sender's current verification or authentication status when that sender provides one. - Message: inspect a real delivered message from the exact production path, using redacted headers or authentication evidence. - DMARC: review aggregate-report evidence after data accumulates. A green vendor status is not a delivered-message check. A public lookup is not proof of the production sending path. Keep the review open when a required layer is missing, then record what evidence is still needed. ## Investigate this with your coding agent Use this when the MSP has a redacted inventory and a policy repository or runbook that can be inspected safely. Prepare only client-approved, redacted records and exclude credentials, private keys, tokens, unredacted headers, and customer data. ```agent Problem: Build an approval-gated rollout queue for multiple client domains with missing-evidence flags. Evidence: Redacted client domain inventory, redacted DNS-as-code repository or policy repository, sender inventory, approval owners, exception register, and rollout runbook. Repository scope: Inspect only the portfolio inventory, DNS-as-code repository, sender inventory, and rollout runbook provided for this client service. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not cross tenant boundaries, modify DNS, change sender configuration, alter DMARC policy, access secrets, or make production changes. Requested output: Diagnosis of missing ownership or evidence fields, a minimal proposed wave queue, approval owners, verification checks, rollback notes, and unknowns. Verification: A human compares the proposed queue with the authoritative client inventory and applicable standards and provider guidance before approving any change. Stop if: Credentials, private data, production mutation, active incident handling, ambiguous client ownership, or missing authoritative inventory is required. ``` ## Exceptions and escalation Use a visible exception register instead of allowing blocked domains to disappear into ticket notes. Each entry should state the client, domain, observed condition, business impact, owner, requested decision, next review date, and whether the item blocks a proposed wave. Escalate when: - The client cannot confirm whether a sender is legitimate. - The DNS change owner is unknown or cannot approve the publication path. - A business-critical sender has no safe retest window. - Evidence from a delivered message conflicts with the client inventory. - A sender owner cannot provide the information needed for a same-path retest. - A client requests a change without a rollback decision or approval record. The MSP owns the service record and escalation process. The client owns acceptance of business risk and approval of client changes. The DNS host controls publication. The sender controls sender-side configuration. A mailbox provider controls its own handling decision. Use a simple decision path: if evidence identifies an owner, assign the next action and review date. If evidence is incomplete, keep the domain in evidence review. If the business impact is high or the owner is unavailable, escalate to the client approver. If approval is missing, do not advance the domain. ## Reporting and success measures Report on a regular operating cadence that matches the client's service agreement. A monthly portfolio review can show work in progress, while a quarterly client review can summarize decisions, completed waves, and unresolved risks. Use an evidence-based report: - Domains by operational state and named owner. - Sender inventory items by evidence status. - Open exceptions by client, business impact, owner, and review date. - Proposed changes awaiting client approval. - Completed changes with retained before-and-after evidence. - Post-change reviews that still lack DNS, vendor, message, or reporting evidence. Do not turn these fields into a claim that every future message will authenticate or that every receiver will make the same delivery decision. The report is an operating artifact. It shows what the MSP observed, what the client approved, what remains unresolved, and when the next review is due. [Managed DMARC service SLA guidance](/learning/managed-dmarc-service-sla) can help define the service conversation around ownership, escalation, and review. Keep any SLA terms specific to the client agreement rather than applying an invented portfolio-wide target. ## Turn policy rollout records into a managed portfolio workflow When recurring client domains, approvals, sender evidence, and exception queues are creating operational overhead, use [Palisade for managed service providers](/for-managed-service-providers) to discuss the workflow. 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 a next policy step when the evidence indicates readiness. A human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=dmarc-policy-rollout-across-client-domains) Palisade does not authorize client senders, change a client's DMARC policy without human review, control external DNS without the required access and approval, or guarantee how a receiving mailbox provider will handle mail. ## Sources and further reading - [Palisade for managed service providers](/for-managed-service-providers) - [Palisade DMARC checker](/tools/dmarc) - [Managed DMARC service SLA](/learning/managed-dmarc-service-sla) - [DMARC monitoring for MSPs](/learning/dmarc-monitoring-for-msps) ## Frequently asked questions ### What is a DMARC policy for a domain? A DMARC policy is the instruction a domain publishes for receivers to follow when a message fails DMARC: `none` to monitor, `quarantine` to divert, or `reject` to refuse. It is carried in the domain's DMARC TXT record. In a multi-client workflow, record the current public value, the client approval owner, the sender evidence, the verification plan, and the rollback decision before proposing any change. ### Can I have multiple DMARC records on my domain? No, a domain can publish only one DMARC record at its `_dmarc` owner name. [RFC 9989 tells receivers to discard every returned record when more than one is found](https://www.rfc-editor.org/rfc/rfc9989.html), so a duplicate leaves the client with no usable policy at all. Use a public record check to see what is visible, keep the authoritative DNS evidence, and route the correction through the client's approved change process. ### How does DMARC work with subdomains? A subdomain uses its own DMARC record when it publishes one. When it does not, it inherits the parent domain's record, where the `sp` tag sets the policy for inheriting subdomains and the parent's `p` value applies if `sp` is absent. In portfolio work, keep each subdomain as a separate scope and evidence item until the client, DNS owner, and sender owners confirm the intended arrangement. ### What are typical phases for DMARC deployment? Most deployments run in three stages: publish `p=none` with aggregate reporting, fix the senders those reports expose, then move to `quarantine` and `reject`. This MSP framework tracks the same work as intake, evidence review, remediation pending, client approval, post-change review, and blocked exceptions. Those states organize responsibility and evidence, and they do not replace the technical requirements in the controlling standard or provider documentation. ### Should an MSP use one rollout queue for every client? No, one shared queue mixes clients whose approvals, evidence, and risks have nothing to do with each other. Use a single workflow model across the portfolio, but keep separate records for each client's domains, owners, approvals, evidence, and exceptions. Shared reporting has to preserve those tenancy boundaries. ### Can a DMARC checker prove a rollout is complete? No, a DMARC checker cannot prove a rollout is complete, because it only shows the record visible in public DNS at that moment. It cannot confirm client authorization, the production sending path, whether the state holds over time, or whether every sender's evidence has been collected. Completion is a decision recorded against evidence, and the checker supplies one line of it.