Tenant Offboarding: Handing DMARC Back to the Client

DMARC

Introduction

The end of an MSP engagement is rarely the cleanest moment, and DMARC makes it more complicated than most service lines. The DNS records the MSP published during the engagement stay published unless someone changes them; the RUA endpoint receiving aggregate reports stays pointed at the MSP's platform unless someone updates it; the operational discipline that kept the policy at p=reject for the last two years vanishes the moment the engagement ends. None of this is a problem at the moment of signing the offboarding paperwork. All of it is a problem six weeks later when the client wonders why they're not getting reports anymore — or worse, when the policy silently stops being effective because the operational rhythm stopped.

This article is the offboarding companion to the DMARC for MSPs pillar and the practical mechanics of doing the handover well. Done right, the client leaves the engagement with everything they need to keep DMARC working on their own (or to onboard with a different provider); the MSP leaves with a clean exit and a reference customer rather than a soured relationship.

Why this topic matters

Most service-line offboardings are simple. The MSP stops doing the work; the client takes over or finds someone else. DMARC offboardings are different because there's a permanent artefact (the published DNS records) that outlives the engagement, and a permanent operational rhythm (the report review, the change control, the policy maintenance) that needs an owner.

The cleanest engagements are the ones where the offboarding mechanics are defined in the MSA / SOW at the start. The article below walks through the operational mechanics either way — whether you defined them upfront or you're figuring them out now.

What survives the engagement

The artefacts the client owns after termination, regardless of how the offboarding goes:

• The DNS records. SPF, DKIM, DMARC TXT records published on the client's domain. These belong to the client; they remain when the MSP leaves.
• The DKIM private keys for any DKIM keys the MSP generated. The client controls the DNS where the public keys are published; the private keys live wherever they were generated (the client's M365 tenant, their Workspace admin, etc.).
• The sender inventory. The list of every legitimate sender the discovery surfaced during the engagement.
• The change-control history. A list of changes the MSP made during the engagement — DKIM rotations, policy escalations, SPF includes added, etc.
• The operational runbook. The document describing the per-client steady-state work.

The artefacts the MSP retains:

• Platform configuration on the MSP side. The tenant configuration inside the MSP's multi-tenant DMARC platform. The MSP can keep this or delete it depending on the offboarding terms.
• Internal notes and tooling. Anything the MSP team built internally to manage this client; not part of the handover.

The hand-over deliverables are what bridge between the two: the documentation that lets the client (or a new provider) pick up the operational work.

The four mechanics that have to happen

Four concrete steps in the offboarding, in order:

1. RUA endpoint cutover

Aggregate DMARC reports flow to whatever address is in the client's _dmarc TXT record's rua= tag. During the engagement, that's typically a tenant-specific address at the MSP's DMARC platform. At offboarding, this has to change to something the client (or the new provider) controls.

Options for the cutover:

• Client takes over reporting directly. Point rua= at a mailbox the client controls. Works for clients who plan to look at raw XML (rare) or who have their own DMARC platform.
• Client onboards with a new provider. Point rua= at the new provider's RUA endpoint. The new provider supplies the address.
• Client lets reporting lapse. The least-good option but sometimes the choice — point rua= at a black-hole mailbox or remove the rua= tag entirely. The DMARC enforcement still works; the visibility is gone.

The DNS change is one TXT record update. Allow 24-48 hours for propagation before assuming the cutover is complete.

2. Documentation handover

Hand the client a written artefact summarizing the engagement state. The format that holds up:

• Current policy state per domain. "clientco.com: p=reject, pct=100, last verified 2026-06-08."
• Authenticated sender inventory. Every legitimate sender currently authenticated, with the DKIM selector name and rotation status if applicable.
• SPF record current state. The full SPF record including the lookup count.
• Active integrations. Anything the MSP set up that the client needs to maintain (DKIM rotation calendars, SaaS-platform DKIM configurations, etc.).
• Known issues and watch items. Open items the engagement was tracking but hadn't resolved.
• Recommended operational cadence. What needs to happen monthly, quarterly, annually to maintain the current posture.

Format the handover as a single PDF or markdown document. Client signs an acknowledgment that they've received it; the acknowledgment is the proof-of-handover for any later dispute about what was or wasn't transferred.

3. Platform decommissioning

What happens to the client's data inside the MSP's DMARC platform after offboarding.

• Historical aggregate reports. Hand a copy to the client if they want it (most don't). Delete from the MSP platform after a retention period defined in the MSA.
• Platform user accounts. Remove client-side users from the tenant (if any existed).
• Platform integrations. Revoke any API tokens, OAuth grants, or platform-to-client integrations the engagement used.
• Internal alerts and dashboards. Remove the client from the MSP's internal alerting flow.

The decommissioning step protects both sides: the client gets data hygiene; the MSP avoids continuing to hold client data after the engagement ends.

4. The "did this work?" verification

After all the above, verify that the cutover actually worked.

• Pull the current DNS records for every covered domain. Confirm the _dmarc rua= points where you intended.
• Verify the new provider (if any) is receiving reports. Wait 24-48 hours after cutover and confirm reports are flowing to the new address.
• Confirm the MSP platform has stopped receiving reports for the offboarded domains.
• Send a final summary email to the client confirming offboarding is complete, with a timestamp.

The verification is not a courtesy — it's the moment that turns "we handed over" into "the handover is complete and observable." Without it, you find out three months later that the RUA cutover never propagated correctly and no one was watching.

The "what to keep monitoring" question

A common edge case: the client wants the MSP to keep monitoring something even though the engagement is ending. Usually it's one of:

• Phishing-impersonation alerts for the brand. "If you see brand spoofing in your aggregate reports for any of your other clients, tell us." Cheap to do; usually fine to offer informally; document as informal best-effort, not as a continuing service.
• A grace period of report forwarding. "Forward the reports for 30 days while we figure out our own setup." Reasonable for one-month transitions; longer than that and it's a continuing engagement.
• One-time questions during transition. "What did you mean by X in the runbook?" Reasonable as transition support; document a defined cutoff.

The pattern: anything continuing is either documented as a continuing service (with its own fee) or has a defined end date. "Just keep an eye on it" with no defined end is how MSPs accumulate orphaned work they're not being paid for.

When to cut hard

Some offboardings should be clean cuts with no continuing relationship:

• Termination for cause. Material breach by the client (non-payment, abuse of MSP staff, etc.) — clean cut, no informal support.
• Migrations to a competitor. Pleasant but firm; do the cutover, do the handover, end the relationship. No grudge, no continuing-support backdoor.
• Client going internal. The client building their own internal team — clean handover, no continuing support. They need to own it.

When to keep a soft connection:

• Client downsizing. They're cancelling because they can't afford the service this year; might be back next year. Cordial offboarding, occasional check-in.
• Acquisition by a strategic partner. Different commercial situation; the offboarding is more of a transition than an exit.

Common offboarding pitfalls

• No RUA cutover. The most common pitfall. Reports keep flowing to the MSP platform after the engagement ends; nobody acts on them; the client has no visibility. Always update the DNS record.
• Documentation handover delivered as a Slack message. Doesn't survive the engagement. Use a formal artefact (PDF, signed acknowledgment).
• Continuing to pay for the client tenant on the MSP platform after offboarding. Some platforms continue billing until the tenant is explicitly decommissioned. Audit.
• DKIM keys with no rotation owner. If the MSP rotated DKIM annually during the engagement, the client needs to know that's still required and who's responsible.
• Hanging change orders. Scope additions that hadn't been formally accepted at time of offboarding. Close them out — accepted (so client owes) or void (so neither side owes).
• Implicit "we'll keep watching" promises. Avoid. Either it's a service or it's not.

Step-by-step offboarding

1. Confirm the termination paperwork. Termination notice received, end date confirmed, offboarding scope defined (per MSA).
2. Schedule the offboarding window. Typically 30-60 days from termination notice. Use the window to do the work properly, not the last 48 hours.
3. Identify the cutover target. Where is rua= going to point? Confirm with client; confirm with new provider if applicable.
4. Build the handover documentation. Per-domain state, sender inventory, runbook, watch items.
5. Execute the DNS cutover. Update _dmarc records; allow propagation; verify.
6. Deliver the documentation. Formal handover; signed acknowledgment.
7. Decommission the MSP-side platform configuration. Per retention policy.
8. Send the final summary. Confirm offboarding complete with timestamp.
9. Charge the offboarding fee. Per MSA.
10. Move on. Don't keep loose ends; clean offboarding protects future business.

Best practices

• Define offboarding in the MSA / SOW. Knowing how the exit works at signing makes the exit easier.
• Charge for offboarding. It's real work and the fee disincentivizes casual churn.
• Documentation handover in writing. Slack messages don't count.
• Verify after cutover. 24-48 hours later, confirm reports are flowing to the new destination.
• Clean platform decommissioning. Don't keep billing for empty tenants.
• Define what continues, if anything. Informal "we'll keep an eye on it" is the worst-case shape.

Recommended next step

If your current MSA doesn't define offboarding mechanics, add them on the next renewal. The conversation is easier at signing than at termination. If you have an offboarding in progress, work through the four mechanics above explicitly — RUA cutover, documentation, platform decommissioning, verification.

FAQ

What happens to the DMARC policy after offboarding?

The DNS records stay published. The policy continues to be enforced — p=reject keeps rejecting spoofed mail whether the MSP is monitoring or not. What stops is the operational work around the policy: sender discovery, change control, rotation, monitoring.

Does the client need to update SPF and DKIM at offboarding?

Only if those records reference MSP infrastructure (they shouldn't, in a well-run engagement). SPF should reference the client's own senders. DKIM should be on the client's own tenants. If anything points at the MSP, fix it before offboarding.

How long should the offboarding window be?

30-60 days is typical. Less than 30 is rushed; more than 60 invites scope creep. The MSA should specify.

What if the client doesn't want documentation handover?

Offer it anyway and ask them to acknowledge declining. The acknowledgment protects you from later "you never told us about X" claims.

Can the client stay on the MSP platform after offboarding as self-serve?

Sometimes. Some MSP DMARC platforms support a "self-serve" or "billing-only" tier that lets the client log in and view their own data without the MSP doing operational work. Discuss with the platform vendor; this is sometimes a useful transition mode.

What about the platform's billing during offboarding?

Pro-rate. The client pays through the termination date; the MSP stops charging the day the offboarding completes. Per-active-Premium-domain pricing is friendliest here because inactive domains don't draw cost.

Do I need to forward aggregate reports during the transition?

If the SOW promised this, yes. Otherwise, hand off the RUA endpoint as part of the cutover and stop. Forwarding indefinitely creates continuing operational obligation you're not being paid for.

Final thoughts

The offboarding is the last impression the client takes from the engagement. Done well, the client leaves with everything they need and good feelings about the MSP. Done badly, the client tells the next provider (or, worse, the next prospect) about the messy exit.

Spend the time on the offboarding. It's the cheapest reference customer you'll ever generate.