One-click DNS setup: a domain connected in about 30 seconds

The moment a customer types their own domain into your product is a trust test. If the next screen shows a table of CNAME records, a warning about propagation, and a "check again later" button, some of those customers quietly leave. One-click DNS setup removes that entire step. Your customer picks their DNS provider, approves the connection, and Custom Domain writes the records, verifies ownership, and issues the TLS certificate automatically. The domain is typically serving traffic over HTTPS in about 30 seconds.

This page walks through how one-click provider authorization actually works, the three connection methods behind it, why coverage across 63 DNS and registrar providers changes your support load, and how to put the whole flow inside your product with a widget or the REST API. For the broader picture, start with custom domains for SaaS.

What happens during one-click provider authorization

From your customer's side, connecting a domain looks less like DNS and more like a single sign-on prompt. Behind that one click, five things happen in sequence:

1. Provider detection. Your customer enters their domain. Custom Domain reads the domain's nameservers and identifies which of the 63 supported providers hosts its DNS.
2. Authorization. The customer lands on their provider's own login and consent screen and approves access scoped to this setup. No passwords or API keys pass through your product, and none pass through ours.
3. Automatic DNS configuration. Custom Domain writes exactly the records the connection needs: a CNAME for a subdomain, or the right apex records where the provider supports them. Nothing else in the zone is touched. Not sure which applies to you? See apex domain vs CNAME.
4. Ownership verification. Verification runs automatically the moment the records resolve. The customer never copies a TXT token or hunts for a "verify now" button.
5. TLS issuance. The edge requests and installs a certificate for the domain, then renews it on schedule for as long as the domain stays connected. See on-demand TLS for how issuance works.

All of this runs on a control plane that manages records, verification, and certificates, plus a reverse proxy edge that terminates TLS and routes each hostname to the right tenant, with strict isolation between tenants. The how it works page covers the architecture in more depth.

Three ways a domain connects

One-click authorization is the headline, but it is one of three methods. Every domain your customers bring fits one of them, and all three end in the same place: verified ownership, live records, and a managed certificate.

1. One-click provider authorization

The customer approves the connection on their provider's own consent screen and everything else is automatic. This is the fastest path and the one most customers hit first, because the providers that support it host a large share of the domains people actually bring.

2. API token

Some providers expose a DNS API rather than a consent flow. Here the customer, or your team for domains you manage, pastes a scoped API token once, and Custom Domain writes and maintains records through the provider's API from then on. This suits technical customers and agencies operating many domains, since one token can cover a whole portfolio. If that sounds like you, the agencies and white label page goes deeper.

3. Guided manual with automatic verification

For every other provider, the flow degrades gracefully instead of failing. The customer sees the exact records to add, with instructions written for their provider's dashboard, and Custom Domain watches for the records to appear. The moment they resolve, verification completes and TLS issues on its own. There is no "I added the records, now what?" limbo, and no button the customer has to remember to press.

Why 63 providers is the number that matters

DNS hosting is fragmented. A slice of the market sits with a few large providers, and the rest spreads across dozens of registrars, hosts, and legacy control panels. Every provider your connection flow does not recognize becomes a support ticket, and domain tickets are among the slowest to close because they involve a third party's dashboard that neither you nor your customer knows well.

Coverage across 63 providers means the automated paths catch most domains, and the guided path catches the rest with real instructions instead of guesswork:

Connection method	Providers	What your customer does
One-click authorization	6	Signs in at their provider and approves. Records are written automatically.
API token	16	Pastes a scoped token once. Records are written and managed through the provider's API.
Provider hosted	3	Approves a preconfigured setup flow hosted by their DNS provider.
Guided manual	38	Copies exact records from instructions written for their provider. Verification runs automatically.
Total	63

And if a domain sits with a provider outside the 63, the guided manual flow still works: generic record instructions plus the same automatic verification. Coverage decides how smooth the path is, never whether there is one.

About that "48 to 72 hours" warning

Most registrar dashboards still warn that DNS changes "may take 24 to 48 hours to propagate", and plenty of setup guides stretch it to 72. For a new record written correctly, that is a myth worth retiring.

DNS does not push changes around the world on a schedule. Resolvers simply cache answers for as long as a record's TTL tells them to. A brand new record has no cached answer anywhere, so resolvers fetch it the first time anyone asks. That is why one-click domain setup through provider authorization is typically live in about 30 seconds: the records are written by API, correctly, with sensible TTLs, and verification starts checking immediately.

The long waits people remember come from the failure modes of manual setup: a typo in a record value, a CNAME added at the wrong level, an old conflicting record left in place, or an existing record replaced while resolvers still hold the old value under a long TTL. That last case is the one honest caveat. If a customer is changing an existing record rather than adding a new one, caches can serve the old answer until its TTL runs out, and nothing shortens that after the fact. Custom Domain surfaces this state in monitoring instead of hiding it behind a spinner, so you and your customer can see exactly where the domain stands.

Put the flow inside your product

You can ship this two ways, and both sit on the same platform:

• The widget. An embeddable "connect your domain" component drops into your settings page with a few lines of code. It handles provider detection, authorization, and live status, and ships with an SDK for deeper control. The integration guide walks through it end to end.
• The REST API. Everything the widget does is available as endpoints: create connections, read and write records, watch TLS status, receive webhooks when a domain verifies or a certificate renews, and search and purchase domains at the registrar level. The full reference lives in the docs.

There is also an MCP server, so an AI agent can connect and manage domains the same way your dashboard does. If your product is built around agents, start with connecting domains with AI agents or the AI agents overview. And for the certificate side of the story, see automating TLS for customer domains.

Try it with one domain

The fastest way to evaluate one-click DNS setup is to run it once. Pricing starts at $0, so you can create an account, connect a real domain, and time the 30 seconds yourself. The features and pricing pages cover what scales from there, and if you would rather talk it through with a person first, book a demo.