How to reassign a warmed client domain when IT rotates the mailbox owner

Client IT swaps the Google Workspace owner on a domain you spent six weeks warming. Overnight, OAuth breaks, DKIM selectors look fine in DNS, and one sequence starts bouncing soft.

The domain reputation is still there. The identity path is not. Agencies that treat "rotate the user" like a password reset burn weeks of warm-up for no reason.

What actually moves when IT changes the owner

A warmed outbound domain has three layers that do not travel as one object:

1. DNS auth — SPF, DKIM, DMARC, tracking CNAME
2. Mailbox identity — the specific user/seat that sends and receives
3. Tool connection — OAuth or SMTP path into your outbound workspace

White-label email handoff checklists keep warning that authentication records and dedicated-domain reputation do not "copy" when the admin seat changes. PlusVibe's agency onboarding SOP is blunt on the opposite direction too: reconnect with OAuth under the new owner, revoke the old path, and do not assume the old app password still represents the domain you warmed.

SpamCipher's multi-account rotation notes make the identity point concrete: each mailbox needs its own sending identity and reply routing. Changing the Workspace owner without re-binding the tool is how you get "domain looks green, mail fails."

Do this before IT flips the switch

Pause cold sends on that client workspace first. Keep warm-up traffic if your stack supports it, but stop campaign volume so a half-broken reconnect does not spike soft bounces into an active sequence.

Document, with the client IT contact:

• Exact SPF / DKIM / DMARC host + value pairs currently live
• Which mailbox addresses are in the rotation pool
• Who will be the new Workspace admin and the new sending users
• Whether DNS stays with the client (it should) or with a registrar the agency still watches

Prospecting Manual's multi-client scaling guide is useful framing: every client keeps dedicated domains with no overlap. The reassignment stays inside one client's isolated domain set. You are not "moving reputation" across clients. You are rebinding seats on domains that already belong to this client.

Rebind without pretending warm-up resets to zero

Sequence that usually survives:

1. Create or confirm the new mailbox seats on the same domain before disabling the old ones.
2. Connect OAuth as the new owner in the outbound tool. Prefer OAuth over shared app passwords.
3. Prove SPF, DKIM, DMARC on test mail from each new seat. Read Authentication-Results, not a DNS lookup alone.
4. Run a seed / placement check before restoring cold volume. Green DNS with bad placement is still a fail.
5. Shift volume gradually from old seats to new seats over several days if both can overlap. DMARCPal's IP-migration guidance maps cleanly here: leave the healthy path carrying traffic while the new path ramps, then retire the old path only when the new one is stable.
6. Revoke the old OAuth / app passwords only after the new seats are sending and receiving cleanly.
7. Update reply ownership in the shared inbox so positives do not land in a disabled user.

Do not wipe the domain's warm-up history in the tool if the domain and prior healthy sending pattern are intact. You are changing seats, not launching a brand-new domain. If IT also changed the primary domain or rotated DKIM selectors carelessly, treat it as a fresh auth event and ramp like a new path.

Failure modes to watch for 72 hours

• Soft bounces clustered on one new seat
• DMARC fail because a selector or include was edited during the owner swap
• Reply threads still routing to the old user's mailbox
• Warm-up paused accidentally when campaigns were paused
• Client primary domain accidentally used for cold (never do this; keep dedicated outbound domains)

PlusVibe's offboarding-adjacent checklist still applies mid-engagement: export suppression, confirm reply handling, and keep credentials out of shared docs.

What to tell the client

We are rebinding sending seats on your existing warmed outbound domains. DNS stays yours. We will pause cold volume, prove auth on the new seats, seed-test, then ramp. Warm-up age on the domain is not thrown away if auth and placement stay clean.

GTM runs email + LinkedIn inside client-isolated workspaces with send windows, domain limits, and a compliance gate that requires a verdict before send. Owner rotation is an ops event inside one workspace, not a reason to merge identities across clients.

If you want per-client domain and mailbox ops without mixing seats, join the waitlist.