We publish 18 Domain Connect templates. Here is what that does not buy you.

We publish 18 Domain Connect templates. That is the second-highest template count of the 695 provider IDs in the public registry, behind Entri's 77. Clone Domain-Connect/templates at commit 8059a9d, dated 16 August 2026, parse all 1,120 template files, and you get the same two numbers.

Rows 3 and 4 are the same company: the secureserver.net entries carry the provider name SecureServer and the sync key domain domain-attach.api.godaddy.com. Counted as one company, GoDaddy publishes 27, which puts it ahead of us. Counting by provider ID is not counting by company; the ranking above is the former.

We are telling you this because it is the one claim on this site you can check without trusting us. We are also telling you it will not decide anything you are building. We make CustomDomain, a product of EverJust Company in Minneapolis: a widget that SaaS platforms embed so their customers can connect their own domains, plus the DNS automation, certificate issuance and reverse-proxy edge behind it. This post is on our blog and it reaches a conclusion that suits us. Read it that way.

What follows is about the registry those 18 files live in — what a merged template proves, what it does not, and how far the protocol reaches once you go looking. The protocol itself is explained end to end on our Domain Connect glossary page. This is not that.

What merging a template proves

Getting a template into the registry is not a formality. A pull request has to pass a JSON Schema the README states is required for acceptance, clear a published linter with numbered diagnostics, satisfy ten rules the README calls binding rather than suggestions, and link to results from the online editor — without which, in its words, the pull request will not be reviewed. Rule 1 requires syncPubKeyDomain, the field that lets a DNS provider cryptographically verify an apply request. All 18 of ours set it.

What merging is not is distribution. The registry validates the template and publishes it. It does not push anything to DNS providers, and it has no mechanism for reporting which providers have loaded which templates. Each provider ingests on its own schedule, under its own review. A merged template is a published record, and it does not become a live integration by being merged.

The claim we are not going to make

We wanted to publish a table showing where our templates are live and where anyone else's are. We could not. The test we would have used cannot tell a real answer from a fabricated one.

The obvious instrument is the public template lookup endpoint IONOS operates at domainconnect.ionos.com/v2/domainTemplates/providers/{providerId}/services/{serviceId}. On 19 August 2026 we sent it five requests: two for our own templates, one for a competitor's well-known service, one for microsoft.com/o365, and one for bogus.invalid/nope, a control we invented on the spot that cannot exist anywhere. All five returned HTTP 200 with the same 2,680-byte HTML page, titled "Domain Connect - Error 404".

So we make no claim about live template availability at any DNS provider, ours or anyone else's. We got this wrong twice in our own drafts before catching it. When you read a page asserting that a template is live at a named provider, the useful question is how they measured it.

How far the protocol reaches

There is a published answer to that, and it is not ours. domainconnect.org maintains a DNS Providers page listing the providers whose implementation is live. On 19 August 2026 it named nine: IONOS, Cloudflare, Domain Chief, Glauca Digital, GoDaddy, NameSilo, Plesk, Vercel and WordPress.com. That is the standard's own account of its reach on the DNS side.

Six of those nine are among the 63 DNS providers and registrars in our live census, published at api.customdomain.ai/v1/providers/census. We route two of them through Domain Connect. The other four we route somewhere else.

So the number we have used ourselves — Domain Connect is the rail for 2 of our 63 providers — describes our routing, not the protocol's adoption. More than two of the 63 implement it; we use it at two, because where a provider offers its own OAuth or a usable API alongside Domain Connect, the other path has worked better for us.

Both numbers count providers, not domains, and that difference runs in the protocol's favor. DNS is concentrated. GoDaddy, Cloudflare and IONOS each sit in front of an enormous number of zones, so nine providers can cover a far larger share of real customer domains than nine of anything sounds like. What these numbers tell you is that Domain Connect will not be the rail for most of the providers you have to support. They do not tell you what fraction of your customers it reaches. Before you size the work, look at where your existing customers' NS records actually point. That distribution is the input, and ours is not yours.

The registry is candid about the same friction. Of the asynchronous flow, its README says that "only a fraction of DNS providers support the async flow, the integration is more complex, and onboarding is never automatic — it requires an explicit OAuth setup with each provider."

None of that is measured by a template count. A wider product surface produces more template files by construction; 77 and 18 describe how many separate configurations Entri and we each support, and say nothing about the demand side.

Entri's argument, taken seriously

We did not sit the standard out. We wrote the templates, we maintain them, and we run the protocol as one of four rails in the product. The object of the word "alternative" here is the integration path and the adoption ceiling, never the standard itself.

Entri's post, Domain Connect Alternative: How to Simplify Domain Setup for Users, is the best-known writing on this subject; we fetched it on 19 August 2026. It is a good post and its cost list is largely right. Building the front end, authoring and maintaining templates, handling providers that never implemented the protocol, contacting DNS providers individually, legal review, QA and ongoing monitoring are all real line items. We have paid most of them, and its estimate that legal review in particular runs to months rather than weeks matches our experience.

One point of fact, and it is our mistake rather than Entri's. Entri correctly locates the legal work with the individual DNS providers. There is no organization behind Domain Connect to contract with at all: as of 19 August 2026 domainconnect.org describes it in its own words as an open standard published under the MIT license, designed and maintained by a community of developers across multiple companies, and submitted to the IETF as a draft. Our own glossary page invented a governing body and named it seven times before we corrected it in August 2026.

The observation that does carry weight is what the post leaves out. Entri is the single largest contributor of templates to Domain Connect, with 77 of the 1,120 in that 16 August 2026 snapshot. The post calls the standard Entri's "open protocol predecessor" and never mentions the 77. Nothing in it is false as far as we can check, and no company is obliged to volunteer its registry position. But the piece argues that Domain Connect is the thing you would use instead of Entri, and the reader is never told that Entri is the protocol's heaviest publisher. We would rather lead with our 18 than have someone else find it.

People ask about price. Both ladders are on our Entri comparison page, next to ours; check each company's own site before committing to either.

What Domain Connect is good at

When a customer's domain sits at one of those nine providers, the flow is the shortest one available to them. They authenticate where they already have an account, read a plain-language summary of the records about to be written, approve it there, and type nothing. Nobody reads a TXT value aloud on a support call. No other path in our product asks less of the customer.

In that flow the DNS provider writes the records under its own authentication. You never hold the customer's DNS credentials, so there is nothing of theirs in your database. Compare the API-token rail, where 17 of our providers work by the customer handing over a token with real authority over their zone. We handle those carefully and would still rather not have them.

So implement it. We did, and we would again: a template is declarative and reviewable, so a DNS provider or a security team can read exactly what will be written before approving it. Just do not plan your onboarding around it.

What we do for the rest

For 6 providers we use the provider's own OAuth: the provider has implemented an authorization server and a DNS write API — more work than Domain Connect, not less — the customer approves there, and we write the records. For 17 we accept a scoped API token. For the remaining 38 we run a guided flow that generates the exact records, handles the apex versus CNAME problem, watches propagation, and verifies automatically instead of asking anyone to click "I've done it".

Around all four rails sit the parts that are not DNS: certificate issuance and renewal, a multi-tenant reverse-proxy edge, and monitoring that keeps checking after the domain goes live, because customer domains break later, usually when someone else edits the zone. You reach it through an embeddable widget, a REST API or an MCP server. One-click DNS setup covers how the automated rails differ, how it works covers the whole path, and the build-versus-buy version of this decision is on our Domain Connect comparison page.

The limitation we are not going to write around

38 of the 63 providers in our census are guided manual: 60% of the providers we support, where the customer still creates the records by hand. We generate them, verify them automatically, and monitor them afterwards, but we do not write them. Ours is a large automated subset. It is not the whole.

The measurement problem above applies to us too. We can watch our own connections succeed at the providers we integrate with, which is how we know the two Domain Connect rails work, but we cannot enumerate which templates any DNS provider has ingested, ours included. So: we publish 18 templates, we maintain them to the registry's rules, and we will not tell you they are live anywhere.

If your customers' domains cluster at the nine providers with live implementations, build on the protocol directly and skip us. If they are spread across the long tail, which is what we see, Domain Connect is one lane of four and the other three are the work.