Guide
How to connect a custom domain
To connect a custom domain, you point DNS you control at a host you do not: create a CNAME (or an apex alias) at your DNS provider that resolves to the platform's edge, let the platform check that the record resolves, and let it issue a TLS certificate.
This page covers what "connect" actually means, the four ways records get written, and how to tell when a domain is genuinely live. If you want the step-by-step mechanics instead, read how to set up a custom domain.
Connecting vs. registering vs. setting up
These get used interchangeably and they are not the same thing.
- Registering
- Buying the name from a registrar. You now own it. Nothing points anywhere yet.
- Setting up
- Configuring DNS for the name generally: mail, apex, subdomains, whatever the name is for.
- Connecting
- Attaching the name to one specific product so that product serves it over HTTPS. That is a record pointing at the product's edge, a check that the record resolves, and a certificate. It is the step this page is about.
The four ways a record actually gets written
Every custom-domain flow reduces to one of these. Which one a customer gets depends entirely on who runs their DNS.
- One-click via Domain Connect. The provider implements an open standard, so the user is sent to their own provider, signs in, sees exactly what will be written, and approves it. Nothing is typed and no credentials are shared with the platform. On October 30, 2026, domainconnect.org marked 11 implementations as live on its DNS Providers page.
- Sign in with the provider (OAuth). Same outcome, different mechanism: the provider exposes an API with an OAuth flow, the user authorises, the records are written for them.
- Scoped API key. The customer gives the platform a credential for their provider's API, usually an API key limited to DNS where the provider allows it, and the records are written with it. It is the most common automatic path: 66 of the 73 in the census below.
- Manual records. Everything else, and this is the majority case, not a rare fallback. 189 providers known. 73 have an automatic path. The other 116 get the exact records with that provider's steps. (Provider census, October 2026.) A manual path that detects the provider, gives provider-specific instructions, warns about conflicting records before the user hits them, and verifies the result is a completely different product from a table of values.
What breaks, and why
- The user goes to the wrong panel. Registrar and DNS operator are different roles. A domain bought at GoDaddy but delegated to Cloudflare is edited at Cloudflare. Check with
dig +short NS example.com. - The root domain will not take a CNAME. RFC 1034 forbids other data alongside a CNAME, and the apex must carry SOA and NS. Use a subdomain, a provider alias (CNAME flattening, ALIAS, ANAME), or A records.
- A CAA record blocks the certificate. DNS looks perfect and HTTPS still fails, minutes later, inside the CA. Check with
dig +short CAA example.com. - Checking too early makes it slower. There is no propagation event. Query a name before the record exists and the resolver caches the negative answer for the SOA minimum, often an hour.
Connect domains inside your own product
Embed the widget and your users connect their own domain without leaving your app: provider detection, the records written for them where their provider allows it, drift detection after go-live and, on Growth and up, automatic TLS on our edge.