A repeatable onboarding process starts with the customer boundary. Establish which legal entity, domains, applications and administrators are in scope before collecting reports or proposing DNS changes. A shared service should not infer customer authority from a domain appearing in a sales spreadsheet or a public DNS lookup.
Establish the service boundary
Name the customer sponsor, technical owner, DNS custodian, MSP analyst, change approver and incident contact. Record their responsibilities and backup coverage. Verify authority through the agreed onboarding process and grant only the scoped access needed for the current stage. Reading reports and changing authentication records are distinct permissions.
Create a sender register that includes business purpose, application owner, visible From domain, envelope domain, signing domain and expected activity cycle. Include scheduled and low-volume services. An absence in a short observation window is not evidence that a service is unused. RFC 9990 aggregate reports describe reported message activity; they are not an authoritative application inventory.
Move through staged acceptance
First accept inventory and evidence collection. Next evaluate known sending paths and explain failures. Then propose changes with an exact diff, approval and rollback conditions. Finally verify the intended flow with messages from the actual application and receiver-side results. DMARC relies on alignment as well as SPF or DKIM authentication under RFC 9989, so a generic pass label is not enough.
Do not move every domain to an enforcement policy simply because the template says onboarding is complete. Record exceptions, unresolved senders, forwarders and mailing-list paths. Define who accepts residual risk and when the evidence will be reviewed. Policy decisions must follow the customer's mail dependencies and authorization.
Keep two onboarding holds separate
Suppose a customer’s billing application has a current authorized aligned-pass sample, while its quarterly notifier has not run and its alternate DNS approver is unconfirmed. Accept the billing evidence for its tested scope, retain the notifier as untested, and resolve the approval fallback before relying on it. A completed intake checklist cannot turn those gaps into operational acceptance.
These are hypothetical onboarding decisions, not a supplied customer runbook or executed completeness check. For each stage, record the responsible person, exact acceptance evidence and unresolved conditions. At exit planning, require confirmation of access revocation through the responsible system rather than a promise that a future script will remove it. No customer approval, DNS write or report ingestion is asserted here.
Hand over operations and plan the exit
Give the customer a current domain register, approved configuration, open exceptions and escalation route. Specify report availability, monitoring coverage and retention responsibilities. Explain what the MSP can measure and what depends on customers, DNS hosts and receivers. Successful authentication does not promise inbox placement.
An exit plan should identify export format, authorized recipient, access revocation, retained audit evidence and deletion responsibilities. Do not automatically delete useful authentication records during offboarding: the customer may still depend on them. Transfer technical responsibility, test continued mail flow and retire access under an approved plan. Review the service whenever ownership, applications or business-critical flows change.