Skip to Content
CUSTOM DOMAIN

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, prove you own the name, and let the platform issue a TLS certificate. Done properly it takes about 30 seconds of user effort; done by hand it is the single largest source of onboarding support tickets.

This page covers what "connect" actually means, the three 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, an ownership check, and a certificate. It is the step this page is about.

The three 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.

  1. 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. Domain Connect lists nine live provider implementations.
  2. One-click via provider OAuth. Same outcome, different mechanism: the provider exposes an API with an OAuth flow, the user authorises, the records are written for them.
  3. Manual records. Everything else — and this is the majority case, not a rare fallback. In a 63-provider census, 38 have no automated write rail. 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 best available rail, automatic TLS, and drift detection after go-live.

See the connect widget Compare with Entri