A divestiture can transfer a domain without transferring every application that sends from it. It can also transfer email visibility to the wrong organization if report destinations and administrator access are left behind. Treat the handover as three coordinated changes: authority over the domain, authority to send, and authority to receive operational evidence. This guide proposes a technical transition plan, not legal advice about ownership or a contract.
Draw the boundary before changing DNS
Make one row per sending service. Record the current and future business owner, visible From domain, SPF-authenticated identity, DKIM signing domain and selector, DNS authority, reporting recipient and retention obligation. Mark whether the service transfers, remains with the seller or retires. A shared provider IP cannot settle that question. An accountable owner must identify the actual customer account and business process.
DMARC links an authenticated SPF or DKIM identifier to the author domain; it does not determine which company is entitled to use the domain. RFC 9989 supplies that protocol boundary. A transfer agreement and approved asset schedule supply the business boundary. Do not use a passing report as evidence that the legal or commercial handover is complete.
Plan coexistence and reporting separation
For each retained sender, choose an explicit future identity and establish its authentication before switching From addresses. Keep only the old signing and routing dependencies needed for approved transition traffic or already-signed delayed mail. A temporary authorization needs an owner, permitted purpose and expiry; a date without a removal test is not an exit plan.
Aggregate reports disclose sending observations. Review their destination separately from mailbox migration. Where reports go outside the policy domain, check the external-destination authorization procedure in RFC 9990. A DNS authorization record is not the business authorization to disclose data. Approve the recipient and retention scope, preserve the required historic export and remove former staff or supplier access through the relevant account process.
Build a concrete handover ledger
The following are proposed roles and reserved-domain identities, not an executed transfer or accepted assignment. All actual tests, approvals and exports remain missing.
- Payroll transfers: old From payroll@group.test, envelope bounce@group.test, DKIM d=group.test selector payroll1; proposed new equivalents at buyer.test with selector payroll2. Proposed buyer mail owner must obtain signing and trusted receiver evidence before exiting approved coexistence. Reports would move from reports@group.test to reports@buyer.test only with approved disclosure and working collection.
- Analytics remains with seller: old From analytics@group.test, envelope bounce@group.test, d=group.test selector analytics1; proposed new equivalents at seller.test with selector analytics2. Proposed seller mail owner must prove the new identity before removing old authority. Report access must follow the approved seller scope, not all transferred-domain traffic.
- Campaign retires: old From campaign@group.test, envelope bounce@group.test, d=group.test selector campaign1. No replacement sender is proposed. The campaign owner must confirm retirement and map shared dependencies before obsolete authority and access are removed.
Each row requires a real business-owner decision, an approved coexistence expiry or retirement date, an export reference with approved retention scope, exact DNS observations and permissions review. Those fields are explicitly not supplied. False, unknown or absent evidence blocks closure under this proposed gate. No local model or real-service test ran, and no legal transfer or ownership decision is implied.
Close without leaving invisible authority
Agree a change window and rollback decision-maker. Record which changes are reversible and which need fresh commercial authorization after transfer. A seller must not restore old signing access merely because an application fails. Escalate the business impact and use the agreed transition arrangement instead.
Close only when transferred services work, retained services no longer depend on the transferred domain, retired services have no unnecessary authority and reporting access follows the approved boundary. Preserve an exception register for anything unresolved. Revisit low-volume jobs at their actual schedule rather than declaring success after one quiet afternoon.