CUSTOM DOMAIN
A customer connects their domain, sees a green success message, and closes the tab. Ten minutes later they open the site and the browser throws a certificate warning. Nothing is technically broken. The domain points where it should. But there is no valid HTTPS certificate yet, and now the customer is staring at a scary red screen wondering what they did wrong. They did nothing wrong. The flow asked them to do one thing and quietly needed two.
If you host apps or sites on customer-owned domains, you have met this problem. Pointing the domain is the visible step. Getting a working certificate for it is the invisible one. And the invisible one is where onboarding goes to die.
The certificate is a second step nobody signed up for
For a custom domain to serve HTTPS, your platform needs a TLS certificate issued for that exact domain. Getting one usually happens after the customer points their domain, as a separate action, on a schedule you do not fully control. The customer thinks they are done. Your system knows they are not.
The common way to prove the platform is allowed to hold a certificate for a domain is to answer a live challenge over the domain itself. The certificate authority reaches out to the domain, expects a specific response, and issues the certificate if it gets one. That works fine once everything is wired up. During initial setup it has a timing problem baked in.
The race nobody is watching
The customer points their domain, and your system tries to get the certificate right away because you want the site working now. But DNS has not propagated yet, so the challenge lands on nothing and the request fails. It fails quietly, in the background, with no one watching. The customer already left. By the time DNS settles, the moment has passed, and whether the retry succeeds depends on timing you are hoping goes your way.
The domain points correctly and there is still no certificate. To the customer that reads as "the product is broken," and it is your support queue that hears about it.
Validate against DNS, not against live traffic
There is a cleaner way to prove control of a domain: put a specific record in the domain's DNS and let the certificate authority read it there. This is DNS-based validation, and it sidesteps the race entirely. It does not wait for traffic to reach your server. It does not care whether the site is live yet. It only checks that the right record exists in DNS.
- Needs working DNS before it can succeed
- Runs during the exact window DNS is still settling
- Fails quietly in the background
- Success depends on retry timing
- Reads a record instead of hitting your server
- Does not care whether the site is live yet
- Ready the instant the records land
- No propagation race to lose
That distinction is the whole game. Live-traffic validation is a chicken-and-egg problem: you need working DNS to get the certificate, and you are trying to get the certificate during the exact window when DNS is still settling. DNS-based validation removes the egg. The proof lives in the same place the customer just authorized changes, so it is ready the instant the records land.
Both records, one consent
This is where the one-click flow earns its keep. When Custom Domain detects the customer's DNS provider and asks for a single approval, we do not write just the record that points the domain. We write both records at once, and you can see how a one-click connection works end to end.
| Purpose | Type | What it does |
|---|---|---|
| Routing | CNAME / A | Points the domain at your platform |
| Certificate proof | TXT | Validates the TLS certificate for that domain |
Both go in under the same consent, at the customer's own provider, in one approval. The customer never types a record and never learns what a validation record is. And because the validation proof is placed in the same moment as the routing record, certificate issuance can begin immediately. There is no second visit, no "come back in an hour," no silent retry loop you are quietly praying resolves itself.
- Approve one screen. The customer confirms a single plain-language consent at their own DNS provider.
- Both records land together. The routing record and the validation record are written in the same moment, not in sequence.
- The certificate issues. With the proof already in DNS, issuance begins immediately and HTTPS comes up on its own.
The customer performs one action. On your side, pointing the domain and proving the certificate happen together instead of in sequence.
Renewals without a return trip
Issuing the first certificate is only half the job. Certificates expire, and a renewal that fails is just as bad as an initial setup that fails, except now it hits a customer who has been happily live for months. The usual answer is to send them back to their DNS panel, or to ask for credentials so you can make changes on their behalf. Both are bad. One annoys the customer, the other makes you hold keys you should not be holding.
Delegation ends the return trips
During that first setup, the customer's DNS is arranged so the validation records live on infrastructure we run. From then on, renewals happen on our side, on our schedule, indefinitely. The customer never returns to their DNS panel, no credentials change hands, and the certificate keeps rotating quietly the way a certificate should.
What changes when the certificate stops being a step
The old flow was a two-step dance where the second step was invisible and optional-looking, and it was exactly where people used to fall down. Fold the validation into the first step and the dance disappears. The customer clicks approve once. The domain points, the certificate issues, HTTPS comes up, and it stays up on its own. Connecting a domain and having a working secure site become the same single action instead of two, and the one that used to break is gone. If you want that for your own onboarding, you can start connecting domains in one click today.
Custom domains, on autopilot
Let your customers connect their own domain in one click. We detect their DNS provider, write the routing and validation records together, verify ownership, and issue HTTPS, while they just approve one screen.
Get started