Mirrored CP26 portal pages for a proposed experience. Static HTML — no backend, no network calls, no connection to any running system. All names, domains, addresses and records below are invented.
A customer wants their existing domain to reach a new site here, and their existing email to keep working. CP26’s Connect domain page tells them to change their bare domain’s A record at their provider. It never mentions email — not the records that carry it, not the provider wizards and nameserver moves that wipe them.
The second half is that the portal is blind on purpose. The page says it: “We can’t see your provider’s settings from here, so we won’t know you’ve made the change until you tell us.” But reading a domain’s public DNS needs no access to the customer’s provider at all. That single read is what lets the portal name the email records out loud, hand the operator a before/after, and replace “tell us when you’re done” with a status the customer can watch.
What this proposes: make the email records a named, preserved checkpoint in the middle of connecting a domain, and carry that check through to the operator as a gate on finishing the job.
| Connect domain, today | Observed | Client portal. A faithful mirror of the existing tab, with a note on what it does not do. |
| Connect a domain | Proposed | Client portal. Four steps: name the domain → read what it does today → change two records and nothing else → hand a structured request to ops. The email checkpoint is step 2. |
| Connection status | Proposed | Client portal. What the customer watches afterwards, including the case where their provider wiped the mail records. |
| Request drawer, today | Observed | Ops portal. What an operator gets now: a title, a Details box, a status dropdown. |
| Domain connection request | Proposed | Ops portal. Structured request, DNS read-back, mail-safety gate, and the three actions in order. |