Connect a domain you already own — without losing your email

CP26 already has a “Connect domain” page. Observed It sits on a client environment, under Domains → Connect domain. It tells the customer to add a CNAME or an A record at their domain provider, then asks them to send the domain in so Ayuda can add it to the site and get a certificate issued.

That page never mentions email. Observed It does not ask where the domain’s DNS lives, it does not ask whether mail is live on the domain, and it names no mail record. The one case that can actually destroy a customer’s mail — moving the nameservers wholesale — is not described at all.

And it cannot tell anyone whether it worked. Observed The page says, in its own words, that Ayuda cannot see the provider’s settings and will not know the change has been made until the customer says so. After the customer sends the domain in, the only thing representing their cutover is a support request — and the request form’s type list has no domain option at all. On the operator side the entire progress vocabulary is four statuses: Open, In progress, Resolved, Rejected.

So the problem worth solving is not “build a connect-domain screen”. It exists. The problem is that the existing flow is blind to the customer’s second outcome (my mail keeps working), and that neither the customer nor the operator can establish whether either outcome was actually achieved.

Outcome	How you know it happened	Who can establish it
Visitors reach the new site at the domain	The domain resolves to the host, the host answers to that name, and HTTPS works. Three conditions, two systems.	Ayuda can check the last two. The first depends on DNS Ayuda may not hold.
Email keeps working	Not established by loading the website. It can fail silently, and the person who notices is usually not the person who made the change.	Nobody, today. Proposed capability

The existing page assumes one of these and describes only that one.

Circumstance	Who performs the change	Risk to mail
A. Ayuda already manages this domain’s DNS	Ayuda	Low mail records are already in the zone and an address record edit does not touch them
B. DNS lives at the registrar or another provider	The customer, or whoever holds that account	Contained only the records they edit
C. The customer moves the nameservers to Ayuda	Both, in order	High every mail record is replaced at once; one missed record kills mail silently

These are not three versions of one form. The actor, the point of verification, and the blast radius all differ. The prototype branches here and nowhere else.

• Customer — connect a domain. The existing page, revised so that it first establishes the circumstance and treats mail continuity as a step rather than a warning. Branches A, B and C are all exercisable, as is “I don’t know”.
• Customer — track the connection. What replaces a four-status ticket: five states, each labelled with how it was established and by whom. Includes the paths where it does not work.
• Operator — do the work. The same connection as a piece of operator work, with the mail checkpoint that branch C blocks on, and the certificate failure the customer must not be told is success.

Observed seen in the running CP26 portals, read-only, today.

Proposed does not exist today. This prototype is arguing for it.

Unresolved a decision for Ayuda, which this prototype deliberately does not make.

Every name, domain, address and number in this prototype is invented. No real customer data, hostname, IP or operator name appears anywhere in it.