--- title: "How MSPs move 50 client domains to DMARC p=reject safely" description: "Move client domains to DMARC p=reject with an MSP workflow for sender review, approval, staged enforcement, exceptions, DNS handoffs, and reporting." canonical: https://www.palisade.email/learning/msp-move-client-domains-to-dmarc-reject last-updated: 2026-11-06 --- # How MSPs move 50 client domains to DMARC p=reject safely > Move client domains to DMARC p=reject with an MSP workflow for sender review, approval, staged enforcement, exceptions, DNS handoffs, and reporting. MSPs move 50 client domains to DMARC `p=reject` safely by treating each domain as an evidence and approval decision, then advancing eligible domains through quarantine before reject. Keep sender identification, alignment remediation, DNS ownership, client approval, and post-change review separate for every domain so a portfolio target does not conceal an unresolved mail path. ## Quick takeaways - A domain is ready for `p=reject` only after its legitimate sending services have been identified and reviewed. - Use the same intake record for every client, but make enforcement decisions domain by domain. - Move from `p=none` to quarantine first, monitor the result, then consider reject. - The client approves business risk, the DNS owner publishes records, and sender owners repair their own authentication configuration. - A public DMARC lookup confirms a published record. It does not prove that every production sender aligns. - Keep blocked domains in an exception register instead of advancing them to match a portfolio schedule. ## Operating context and ownership This is an MSP operating framework for a portfolio of client domains, not an external protocol requirement. It gives the MSP a common way to collect evidence, assign remediation, request approval, and record policy changes while preserving each client's ownership of its domains and mail systems. For wider multi-client operating guidance, see the [MSP learning hub](/learning/msp). DMARC distributes a domain owner's policy for handling mail that fails DMARC authentication. The policy can request no specific action, altered delivery, or rejection, as described in [RFC 7489's historical overview of DMARC policy handling](https://www.rfc-editor.org/rfc/rfc7489). RFC 7489 is obsolete, so use current product documentation and observed message evidence for implementation decisions. The MSP owns the operating record and coordination. The client owns the decision to accept residual delivery risk and approve enforcement. The DNS host publishes the approved record. Each email service owner controls its own sending configuration. Receiving mailbox providers make their own delivery decisions after they evaluate a message. Palisade recommends that clients identify marketing, CRM, support, and transactional senders before enforcement, including infrequent and seasonal services that may need several weeks to appear in monitoring data. [Palisade's DMARC lockdown guide](https://docs.palisade.email/guides/locking-down-dmarc) recommends a progressive move from `p=none` to quarantine, at least a week of monitoring, and then reject. ![Portfolio decision flow showing domains moving from intake to sender review, quarantine, reject, or an exception register](/images/editorial/msp-move-client-domains-to-dmarc-reject/msp-move-client-domains-to-dmarc-reject-enforcement-flow.webp "1200x829") *Source: Palisade.* Define the service boundary during intake. Record whether the MSP can only recommend DNS changes, can publish a client-approved change, or must hand the change to a separate DNS administrator. Do not let access to a DNS account imply authority to move a domain to enforcement. ## Evidence to collect Create one working record for every client domain. The record should distinguish an observed sender from a sender the client merely remembers using. A marketing platform that sends only during a seasonal campaign needs a different review window from a daily support system. ```yaml client: example-client domain: yourdomain.com evidence: dmarc_record: checked monitoring_coverage: receiving-reports sender_inventory: reviewed message_sample: pending owner: client-dns-owner next_action: confirm-custom-dkim-with-marketing-platform review_on: 2026-12-01 ``` Collect these fields before placing a domain in an enforcement wave: - Client technical owner and business approver. - Domain and any subdomain scope that requires separate treatment. - DNS host, change owner, approval requirement, and rollback contact. - Current DMARC policy and a dated public DNS result. - Known marketing, CRM, support, billing, transactional, and application senders. - Sender status: confirmed legitimate, unauthorized, unknown, or awaiting client confirmation. - Authentication evidence from an actual delivered message where available. - Open SPF or DKIM alignment work, its owner, and its next review date. - Planned enforcement state, change window, rollback trigger, and post-change reviewer. Use the [DMARC checker](/tools/dmarc) to inspect an individual client's published DMARC record during intake. A DNS check cannot show every service using the domain, prove a sender's live alignment, or predict a mailbox provider's future delivery decision. Palisade's Senders List requires DMARC monitoring and incoming DMARC reports. Its pending-source view includes a documented [14-day email compliance measure](https://docs.palisade.email/page-breakdowns/senders-list), while its related sender-silence behavior uses a 90-day activity window. Those product indicators can organize review work, but an MSP should still retain the client disposition and evidence for each source before an enforcement change. ## How to run the workflow ### 1. Build a portfolio intake queue **Owner:** MSP service owner. **Input:** client domain list, client contacts, and DNS ownership details. **Output:** one complete working record per domain. Group the 50 domains by evidence state, not by client size or date added. Place domains with missing monitoring, an unknown DNS owner, or no client approver in a blocked intake state. These are not enforcement candidates. Do not set a fixed wave size as a technical rule. Palisade documents staged enforcement by domain, but does not prescribe a batch size for an MSP portfolio. Select only the number of domains your team can review, change, and support with the required client approvals. ### 2. Establish monitoring coverage and sender evidence **Owner:** MSP analyst, with client confirmation. **Input:** published DMARC record, aggregate-report coverage, and sender inventory. **Output:** a disposition for each observed source. At `p=none`, DMARC reporting can provide visibility without requesting delivery disruption. [Palisade's implementation guidance](https://docs.palisade.email/getting-started/implementing-dmarc) warns: "Do not skip straight to p=reject without completing the alignment steps." Compare observed sources against the client inventory. Confirm legitimate services with the person responsible for that system. Mark sources the client cannot identify as unknown until they are resolved, retired, or explicitly accepted as an exception. Do not classify a source as safe merely because it has low volume. ### 3. Assign authentication remediation **Owner:** sender owner, client DNS owner, or MSP where authorized. **Input:** a confirmed sender with an authentication or alignment issue. **Output:** an owner-specific remediation ticket and a verification request. Palisade documents tickets for unknown senders, SPF alignment failures, DKIM alignment failures, and SPF-record issues in its [authentication issue remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues). For SPF alignment failures, the Return-Path domain does not align with the From domain. For DKIM alignment failures, the signing domain does not align with the From domain. Send the remediation work to the party that controls the service. A DNS administrator can publish a record, but may not be able to enable custom DKIM signing in a marketing platform. A sender owner can configure the service, but may require the client or MSP to publish the generated DNS values. > Do not move a domain to enforcement because its DMARC record exists. A valid record does not correct an unaligned legitimate sender. Use a real delivered message from the affected production path to verify the repair. A public record check alone does not establish which identity the service used in the message. ### 4. Set the domain's quarantine exit criteria **Owner:** MSP service owner and client approver. **Input:** sender dispositions, open tickets, client risk acceptance, and rollback plan. **Output:** an approved quarantine change or a documented exception. Palisade recommends moving policy progressively: `none` to quarantine, monitoring for at least a week, then reject. Its guidance includes `pct=10` as an example of low-percentage quarantine. Treat that as a documented example, not a universal rollout setting. Record the exact proposed DNS change, the previous record, the person approving it, the publication owner, and the condition that would trigger a pause or rollback. A domain with an unresolved payroll, billing, or other business-critical sender stays out of the wave. ### 5. Publish the approved policy and validate the same path **Owner:** DNS owner publishes, MSP validates, client remains escalation owner. **Input:** approved change ticket and rollback record. **Output:** authoritative DNS evidence and a post-change review item. Validate at four layers: - **DNS:** Query the authoritative DNS service and at least one public resolver for the intended DMARC record. - **Vendor:** Confirm the sending service shows its configured authentication status where the service provides that status. - **Message:** Send or collect a real production-path message and review its authentication results. - **DMARC:** Review aggregate-report evidence after data accumulates. A green sending-platform status is not proof that a recipient received a passing production message. Likewise, aggregate reports cannot substitute for a client approval record. ### 6. Advance eligible domains to reject **Owner:** client approver authorizes, DNS owner applies, MSP records evidence. **Input:** quarantine review, resolved or accepted exceptions, and an approved rollback condition. **Output:** `p=reject` change record and scheduled post-change review. [Palisade's implementation guide](https://docs.palisade.email/getting-started/implementing-dmarc) says even the most elaborate implementations can typically reach reject within three months, while noting that timing varies by domain. The timeline must accommodate low-frequency senders and unresolved ownership, not a portfolio deadline. ![MSP operating record showing client approval, DNS owner, sender status, policy stage, rollback condition, and review date for each domain](/images/editorial/msp-move-client-domains-to-dmarc-reject/msp-move-client-domains-to-dmarc-reject-domain-record.webp "1200x639") *Source: Palisade.* ## Investigate this with your coding agent Use this when a redacted, version-controlled client-domain inventory and rollout runbook need a read-only readiness review. Prepare only domain status, ownership fields, ticket references, and planned policy stages. ```agent Problem: Classify a portfolio of client domains for DMARC quarantine or reject readiness without changing DNS or sender settings. Evidence: Redacted domain inventory, policy stage, monitoring status, sender dispositions, remediation ticket references, client approval state, DNS owner, and planned change wave. Repository scope: Inspect only the version-controlled client-domain inventory and DMARC rollout runbook. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, aggregate-report contents, DNS provider sessions, private keys, tokens, unredacted message headers, or customer data. Do not cross tenant boundaries or propose production DNS mutations. Requested output: A domain-by-domain diagnosis, minimal proposed inventory or runbook changes, rollback notes, and unknowns that prevent classification. Verification: Compare every proposed domain classification to the inventory fields and linked ticket evidence. Stop if: Any domain lacks monitoring coverage, sender disposition, client approval, a named DNS owner, credentials, private data, production mutation, or missing evidence is required. ``` ## Exceptions and escalation Use an exception register rather than forcing every domain through the same wave. Each exception needs an observable reason, a named owner, a next action, and a review date. Escalate when: - The client cannot confirm whether an observed sender is legitimate. - A legitimate sender has an unresolved SPF or DKIM alignment failure. - The DNS change owner or client approver is unknown. - A business-critical sender cannot be tested safely. - A vendor limitation prevents the required authentication configuration. - Monitoring data and the client inventory conflict. The MSP documents the evidence and coordinates the decision. The client accepts any remaining business risk. The DNS host controls publication. The sender controls its own mail configuration. Receiving providers retain control over their individual handling of messages. ## Reporting and success measures Use a regular portfolio review with a client-facing summary and an operational appendix. The summary should show domains by policy stage, blocked items by owner, approved changes, and decisions required from the client. Track process completeness rather than presenting a single security score: - Domains with a named client approver and DNS owner. - Domains receiving DMARC reports. - Observed senders with a documented disposition. - Open alignment tickets past their review date. - Domains in quarantine with completed post-change evidence. - Domains at reject with a dated review record. - Exceptions without a next action or client decision. These measures show whether the MSP can support a controlled workflow. They do not prove that every future message will authenticate or that every receiver will place mail in the inbox. ## Turn domain evidence into a repeatable MSP workflow A portfolio becomes difficult when every domain needs a separate sender review, owner handoff, approval, and policy decision. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes a next policy stage when the evidence indicates readiness. [See how Palisade supports managed service providers](/for-managed-service-providers) Palisade does not change a client's DMARC policy without human review and application, repair every sender automatically, or guarantee how receiving systems will handle future mail. ## Sources and further reading - [Palisade: implementing DMARC](https://docs.palisade.email/getting-started/implementing-dmarc) - [Palisade: locking down DMARC](https://docs.palisade.email/guides/locking-down-dmarc) - [Palisade: fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues) - [Palisade: Senders List](https://docs.palisade.email/page-breakdowns/senders-list) - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc7489) - [What does p=reject mean in a DMARC record?](/learning/glossary/dmarc-p-reject) ## Frequently asked questions ### How do I move 50 client domains to p=reject? Move 50 client domains to `p=reject` by maintaining a separate evidence record for each domain, then advancing only eligible domains through quarantine before reject. Confirm legitimate senders, assign alignment failures to their owners, obtain client approval, record DNS ownership, and keep unresolved domains in an exception register. ### How long does it take to get a client to p=reject? It varies by domain. [Palisade's implementation guide](https://docs.palisade.email/getting-started/implementing-dmarc) says even the most elaborate implementations can typically reach reject within three months, but infrequent and seasonal senders may require several weeks of observation before the MSP can assess their authentication and alignment state. ### What breaks when DMARC goes to reject? When DMARC goes to reject, legitimate mail can be quarantined or rejected when a legitimate sender has not been identified or when its SPF or DKIM identity does not align with the From domain. A staged review process reduces that risk, but it does not guarantee a receiving provider's handling of every future message. ### Can an MSP use the same enforcement date for every client domain? No. An MSP can use one operating framework, but each client domain needs its own sender evidence, client approval, DNS owner, and rollback condition. A shared calendar should not override an unresolved sender or business-critical mail path. ### Does a DMARC checker prove a client is ready for p=reject? No. A DMARC checker can inspect the published DNS record for one domain. It cannot prove that all production senders are known and aligned, that the client approved enforcement, or that a receiving mailbox provider will make a particular delivery decision. ### What should an MSP report after moving a domain to p=reject? An MSP should report the policy change, the approved DNS record, sender dispositions, open exceptions, post-change DNS validation, and the next evidence review date. The report should distinguish completed work from assumptions or unresolved client decisions.