Plan the way out before the way in
An authentication supplier can become a dependency long before anyone signs an exit notice. A delegated DNS subtree, vendor-hosted policy target, reporting mailbox or signing arrangement may continue influencing mail while the management dashboard is unavailable. Before granting control, identify what must keep working if the relationship ends unexpectedly. This guide proposes an exit assessment; it does not approve delegation or describe verified EmailAuth migration features.
Start with the business service rather than the vendor account. Record the domains used for employee mail, transaction messages, marketing and non-sending assets, then identify the systems that publish or consume their authentication data. A useful exit plan says who can restore each dependency, where the replacement configuration comes from and how the team will establish that legitimate mail still authenticates.
Draw the authority boundary accurately
Keep registration, authoritative DNS hosting and application administration distinct. Under RFC 1034, a zone cut delegates authority for a subtree. An NS delegation therefore has a different scope from a CNAME that makes a particular name depend on another name. Neither is merely permission to view a dashboard. Document the exact owner names, record types, targets, parent control and affected descendants before evaluating either arrangement.
Include dependencies that cross the apparent boundary. A selector alias can depend on a vendor's DNS and signing service. An SPF include can make authentication depend on records maintained elsewhere. A reporting destination may remain operational without controlling policy at all. For each connection, distinguish the supplier's ability to change an answer from the customer's ability to replace or withdraw the connection. If DNSSEC is deployed, commission a separate validated chain-transition plan rather than improvising DS changes during termination.
Make the exit package usable without the supplier
Specify the exports needed to operate independently: domain and sender inventories, published configuration, approval history, unresolved exceptions, report provenance and retention metadata. Ask for formats, field definitions, timestamps, completeness checks and a way to verify an export before cancellation. A spreadsheet of dashboard totals may be inadequate if the new operator needs original report identifiers and observation periods to avoid counting the same activity twice.
Current aggregate-reporting guidance addresses duplicate and overlapping reports. Preserve enough provenance to reconcile old and new collectors. Confirm who may receive exported information, how long it may be retained and who authorizes deletion. Do not put private signing keys or reusable account credentials in a general handover document. Where signing remains with another platform, record the custodian and approved transition process instead.
Design a transition that can be observed
Prepare the replacement before removing the old dependency, subject to the actual services and change approvals. A replacement DNS answer must express the intended policy or key, not simply recreate a convenient screen label. RFC 9989 makes authenticated identifier alignment central to DMARC; copying a record does not prove that an application's messages use an aligned identity.
Record the relevant authoritative and resolver observations, earlier cache lifetimes, scheduled changes and planned checkpoints. A newly lowered TTL does not shorten data already cached under an older value. Negative caching can also affect recently introduced names; RFC 2308 defines its own handling. Avoid a universal propagation deadline. State what evidence will justify advancing, pausing or recovering, including the possibility that the old supplier is no longer available.
A fictional example uses billing.example and a vendor-managed DKIM selector. The proposed exit requires the sending platform's owner to identify a replacement signing arrangement, the DNS owner to review the exact record change and the mail team to verify representative messages afterwards. No records, accounts or messages in this example were queried. Keeping the old public selector for an agreed transition may be appropriate, but a compromised key demands a different recovery decision.
Price responsibilities rather than a vague migration
Build a requirement-and-evidence matrix with one row per dependency. For each row, record the customer owner, supplier obligation, evidence requested, acceptance condition and unresolved issue. Include normal termination, supplier insolvency, loss of administrator access and emergency suspension. A requirement without a responsible party is an assumption, not an exit control.
Use transparent workload estimates rather than a fabricated migration fee. As a fictional planning calculation, reviewing twelve domains at twenty minutes each is four hours before testing, coordination, correction and sign-off. That arithmetic says nothing about actual EmailAuth effort or price. Show the assumed domain count, complexity, labor rate if approved, overlap subscriptions and any contractually verified export charge separately. Include a range for unresolved cases and identify which uncertainty could dominate the schedule.
NIST CSF 2.0 places supplier requirements in agreements and includes activities after a relationship ends in GV.SC-05 and GV.SC-10. Apply those outcomes through negotiated responsibilities; the framework does not promise a vendor's assistance, export entitlement or cancellation terms. Commercial and legal owners must verify the applicable agreement.
Set a grant and release decision
Before granting delegation, require evidence that the customer retains appropriate parent-zone control, that another qualified operator can use the exit package and that the proposed recovery path does not depend entirely on the departing supplier. Approve only the exact authority needed. Keep access revocation and data deletion sequenced so that evidence is preserved and continuity is checked before destructive steps.
The catalogue requirement remains open: A requirement-and-evidence matrix and transparent workload or cost assumptions. The map below is a proposed structure, not a completed customer matrix. Publication as a demonstrated supplier-exit case requires actual authorized inventory, contractual confirmation, reviewed assumptions and acceptance evidence. A documentary plan can expose the right questions now without claiming that a real migration has succeeded.