Domain Connect protocol

Domain Connect is an open standard that lets a SaaS app configure DNS at the customer's DNS provider through a consent redirect, instead of asking the customer to copy records into a control panel. The customer clicks "connect my domain," approves a screen at their provider that lists the records being added, and lands back in your app with DNS live.

It turns a six-step copy-paste process into two clicks, which matters because DNS setup is where custom domain onboarding actually leaks customers. The catch is not the protocol, which is well designed. It is discovery: finding out whether a given customer's domain can use it at all.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free.

The synchronous flow

1. You publish a Domain Connect template at a stable public URL, listing the records you want: a www CNAME at your edge, an apex ALIAS or A record, a _acme-challenge TXT for certificate validation.
2. The customer enters their domain in your UI.
3. You discover their DNS provider's Domain Connect endpoint.
4. You build a redirect URL carrying the template identifier, the variable values and a return URL.
5. The customer approves at their provider and comes back.
6. The records go live within the zone's TTL, subject to normal propagation.

Step 3 is where implementations break, and it is worth doing carefully.

Discovery keys on the DNS operator, not the registrar

The spec's first discovery path is a TXT record at _domainconnect.<customer-domain> naming the provider's API host. Queried live on 2026-08-26:

Domain	Nameservers	_domainconnect TXT
bluehost.com	cody.ns.cloudflare.com	api.cloudflare.com/client/v4/dns/domainconnect
hostgator.com	cody.ns.cloudflare.com	api.cloudflare.com/client/v4/dns/domainconnect
name.com	margaret.ns.cloudflare.com	api.cloudflare.com/client/v4/dns/domainconnect
networksolutions.com	Cloudflare	api.cloudflare.com/client/v4/dns/domainconnect
ionos.com	ns-1and1.ui-dns.de	api.domainconnect.ionos.com
1and1.com	ns-1and1.ui-dns.biz	api.domainconnect.ionos.com
godaddy.com	cns2.godaddy.com	(none published)
hover.com	ns2.tucows.com	(none published)
porkbun.com	ns-1328.awsdns-38.org	(none published)
gandi.net	dns4.gandi.net	(none published)

Four different registrars — Bluehost, HostGator, Name.com and Network Solutions — all return the Cloudflare endpoint, because their zones are hosted at Cloudflare. That is the single most useful thing to understand about this protocol:

"Does my customer's registrar support Domain Connect" is the wrong question. The record lives in the zone, so what matters is who operates the zone. A customer who bought at Namecheap and moved DNS to Cloudflare is supported. A customer who bought at Cloudflare and delegated DNS elsewhere is not. Detect via the NS records, not via where the name was purchased.

The gap in TXT-based discovery

The last four rows matter more than the first six.

godaddy.com publishes no _domainconnect TXT on its own nameservers, and GoDaddy originated the protocol and remains its largest implementer. Probing two plausible GoDaddy Domain Connect settings endpoints on 2026-08-26 returned 404 from this machine as well.

So a discovery routine built solely on the TXT record will conclude that GoDaddy-hosted domains cannot use Domain Connect. Given GoDaddy's share of the registrar market, that is a large fraction of your customer base falling through to the manual path for no reason.

The spec's second path is the fix: resolve the provider from the zone's nameservers, then fetch that provider's settings endpoint directly. Cloudflare's answers exactly as specified:

GET https://api.cloudflare.com/client/v4/dns/domainconnect/v2/name.com/settings

{
  "providerId": "cloudflare.com",
  "providerName": "cloudflare",
  "providerDisplayName": "Cloudflare",
  "urlSyncUX": "https://dash.cloudflare.com/domainconnect",
  "urlAPI": "https://api.cloudflare.com/client/v4/dns/domainconnect"
}

urlSyncUX is where you send the customer. urlAPI is where an async integration talks. Implement both discovery paths, try the TXT record first because it is one query, and fall back to a nameserver-to-provider mapping you maintain yourself.

The asynchronous flow

The sync flow needs the customer present. For changes you make later — rotating a DKIM key, re-validating a certificate, moving an edge target — Domain Connect also defines an OAuth-style flow: the customer consents once, you hold a token, and you apply template updates over the API without involving them again.

This is the better fit for a custom domain platform, since certificate and routing changes outlive the setup session. It also raises the stakes on scoping, because you are holding a credential that can write to a customer's zone. Scope the template narrowly to the records you actually need, and do not request apex control if www is sufficient.

Coverage, and why the manual path stays

Support is real but partial. Cloudflare and IONOS both answer live, as the table shows, and GoDaddy implements it as originator. Notable absences among providers customers commonly use: Namecheap has no native support, Route 53 has none, and several registrars that resell DNS elsewhere inherit whatever their upstream does.

Two practical consequences:

• Build the manual flow first. It works for every customer on every provider. Domain Connect is an accelerant on top, not a replacement, and a platform that only supports the fast path cannot onboard the rest.
• Detect, then branch. Look up the customer's nameservers, resolve to a provider, offer the one-click flow when it is available and show copy-paste records when it is not. Never present the one-click option and then fail into an error — that is worse than never offering it.

Whichever path a customer takes, verify the result rather than trusting the redirect. Confirm the CNAME resolves to your target and watch the propagation window before telling them setup is complete. The same verification step protects both paths.

Where it sits among the three onboarding models

Domain Connect is one of three ways to get a customer's domain pointing at you, and the choice is usually presented as a preference when it is really a trade of control against friction:

	Manual records	Domain Connect	Delegated nameservers
Customer effort	Copy 2-4 records	Two clicks	Change NS at registrar
Works everywhere	Yes	No, provider-dependent	Yes
You can change records later	No, ask again	Yes, with async consent	Yes, you own the zone
Customer keeps their other records	Yes	Yes	Only if you migrate them
Blast radius if you break something	One record	The records in the template	Their entire zone, mail included

The third column is why delegated nameservers look tempting and are rarely right for a SaaS. Taking over the zone gives you total control and makes you responsible for the customer's MX records, their SPF, everything. One bad migration takes down their email, not just their site.

Domain Connect is the middle position: you get scoped write access to the records you asked for, and the customer keeps the zone. That is the right shape for multi-tenant custom domains in almost every case.

What the customer actually sees, and where it goes wrong

The consent screen renders your providerName, your logo and the literal record list from the template. Three things routinely make it fail in ways your app never hears about:

• The customer is signed out. They hit a login wall at their provider before the consent screen, sometimes with 2FA, and abandon. Your app sees no callback and cannot distinguish this from a decline.
• The domain is on a different account. Common with agencies and with domains bought by someone who has left the company. The provider cannot find the zone under the account they logged into.
• A conflicting record already exists. Some providers refuse rather than overwrite, and the refusal happens after consent.

Because the return leg is a redirect, treat it as a hint and not as proof. Poll for the records yourself and let the state come from what DNS says, not from which URL the customer landed on. A setup marked complete on the redirect alone will show green for customers who are actually broken.

FAQ

What is Domain Connect? An open standard for configuring DNS at a customer's provider through a consent redirect. The SaaS publishes a template of records, the customer approves it at their DNS provider, and the records are applied — no manual copying, and no credentials shared with the SaaS.

How do I detect whether a customer's domain supports Domain Connect? Query the _domainconnect TXT record on their domain first, and fall back to resolving their nameservers to a known provider and fetching that provider's /v2/<domain>/settings endpoint. The TXT path alone is not sufficient: measured on 2026-08-26, godaddy.com publishes no such record despite GoDaddy having created the protocol.

Does support depend on the registrar or the DNS host? The DNS host. The discovery record lives in the zone, so a domain registered anywhere but hosted at Cloudflare gets Cloudflare's Domain Connect endpoint — bluehost.com, hostgator.com, name.com and networksolutions.com all resolve to it. Detect from the NS records, not from the registrar.

Which providers support Domain Connect? GoDaddy, Cloudflare, IONOS and Network Solutions among the larger ones, plus a number of smaller hosts. Namecheap and Route 53 do not support it natively. Coverage is meaningful but well short of universal, which is why the manual instructions have to exist.

Do I still need manual DNS instructions? Yes. A large share of customers will be on providers with no Domain Connect support, so the copy-paste path is the one that has to work for everyone. Build it first and add the one-click flow as an enhancement for the providers your customers actually use.

Is Domain Connect a security risk? The sync flow is not — the customer approves a visible list of records at their own provider and no credentials reach you. The async OAuth flow gives you a token that can write to their zone, which deserves the same care as any delegated credential: request the narrowest template that does the job, and do not ask for apex control you do not need.