Disclosure first. We build CustomDomain, a managed custom-domain service, and we also publish 18 Domain Connect templates to the standard's public registry. At the registry's August 2026 HEAD, commit 8059a9d, it held 1,120 templates across 695 distinct providerIds, and ours is the second-highest template count of those 695, behind Entri's 77. We sell the managed alternative and we help maintain the standard. Nothing on this page is an argument against Domain Connect.

This page is the build-versus-buy decision: implement the protocol yourself, or buy the flow built around it. One paragraph of protocol is enough for that. A service publishes a template, a JSON file declaring the DNS records it needs, and a DNS provider that hosts the protocol shows the customer a consent screen and, in the synchronous flow, writes those records into the zone itself. No API token, no pasted CNAME. Our glossary entry on the Domain Connect protocol covers the rest, including the asynchronous flow, which matters further down this page.

What implementing Domain Connect actually costs

Entri wrote the well-known version of this argument, in a post called Domain Connect Alternative: How to Simplify Domain Setup for Users, which we read in August 2026. Its cost list is largely accurate. It says a self-built integration needs a front end, template authoring, contact with individual DNS providers, legal review that can run for months, QA, and ongoing monitoring. It notes that some providers charge for access, and that the protocol is "only supported by certain providers". Every item there is real work. We would weight it differently.

The template is the cheap part

A Domain Connect template is a JSON file. Ours declare the records a connected domain needs, with variables for the host. Writing the first one and opening a pull request against the public repository is an afternoon. Keeping eighteen of them correct as record sets change, and as providers change how they consume them, is the part that recurs, and it is still the small end of the bill.

There is no vendor to contract with and no fee to publish, which is not the same as no review. Maintainers check submissions against binding quality rules and a template linter, and the repository's contribution guide says pull requests submitted without test results from the online editor will not be reviewed at all.

Where Entri is plainly right is the per-provider work, and the standard says so itself. Service providers using the asynchronous OAuth flow "must register as an OAuth client with each DNS provider", which the spec calls "a manual process", and the templates repository says onboarding for that flow "is never automatic". Publishing a template is free; access on a given provider's side is a separate matter, and it is what Entri's post means when it says some providers now charge.

The fallback path is the expensive part

What costs real money is everything you build for customers whose DNS provider does not present them with a consent screen: the ownership check, per-provider record instructions, the polling that tells you when records appeared, the retry when they appeared wrong, certificate issuance and renewal, the apex versus CNAME problem, and the support queue behind all of it. None of that is in the protocol. Domain Connect writes records into a zone; it does not verify ownership, it does not issue certificates, and it does not notice when one of those records disappears six weeks after launch. You are building the manual path regardless, so the real question is what share of your users it has to carry. That is a coverage question, not an engineering one. We cover the wider version of it, including apex handling, propagation delays, and the support load, in why custom domains are hard.

How much of our own coverage runs on the protocol

Here is our own number, in the least flattering form we have. We run a live census of the 63 DNS and registrar providers CustomDomain supports, at api.customdomain.ai/v1/providers/census, split by the rail our integration uses:

• 17 via provider API tokens
• 6 via one-click OAuth
• 2 via provider-hosted Domain Connect
• 38 guided manual, with automatic verification

So 25 of 63 providers are automated in some form, and Domain Connect is the rail for 2 of them, IONOS and NameSilo. We publish the second-highest template count of the registry's 695 providerIds, and the protocol still carries a small minority of our own automated coverage. Those counts come from that endpoint, not an estimate.

Two caveats, both cutting against us. This measures our integration surface, not the protocol's adoption anywhere else, and a different provider list would give a different ratio. It also counts the rail we chose, which is sometimes an engineering judgment rather than a hard constraint.

You cannot audit the other direction from outside, which constrains what anyone in this market can honestly tell you. We tried. IONOS exposes a public template-discovery endpoint at domainconnect.ionos.com. In August 2026 it answered HTTP 200 with an HTML page titled "Domain Connect - Error 404" for every query we made: our own customdomain.ai/website, goentri.com/duda, microsoft.com/o365, and bogus.invalid/nope, a providerId and serviceId we invented as a control. All four responses were identical, down to the byte count. We may be calling that endpoint wrong, and the conclusion holds either way: a check that answers the same for a real template and a fabricated one cannot tell you which is which. We therefore make no claim about which templates are live at which provider, ours included, and we read any vendor's coverage table, ours included, as a description of maintained integrations rather than a measurement of the standard.

Three paths, side by side

Entri figures come from its pricing page, its homepage, and its blog, all checked in August 2026. Check their site before relying on them.

When building on Domain Connect yourself is the right call

These are cases where we would tell you not to buy anything.

You are the DNS provider

If you run a registrar, a DNS host, or a hosting control panel, you are on the other side of this protocol. Implementing the provider half is not a build-versus-buy question at all: it is the open way for third-party services to configure your customers' zones without you negotiating a separate integration with each of them, and a managed custom-domain service is not a substitute.

Your users concentrate at a small number of providers you have measured

If most of your signups arrive on a handful of DNS hosts, the work is bounded and the payoff shows up in your own funnel. The word carrying that sentence is "measured": log the nameservers of the domains people actually connect for a month before you write any code. Teams guess this wrong routinely, usually by assuming customers look like their own engineering team.

You ship software that other people operate

Open-source and self-hosted products cannot embed a vendor's API credentials in a distribution, and asking every operator to sign up for a third-party service is a bad install experience. A template plus an applyTemplate URL travels with the software and costs the operator nothing. That is one reason we publish templates rather than treating the protocol as a competitor.

A third party must not hold write credentials to customer zones

In Domain Connect's synchronous flow, the DNS provider applies the change after the customer consents, and no outside party holds a credential for that zone afterwards. If your security review will not approve a vendor holding write access to customer DNS, that flow is the design that clears the review, and buying will not change the answer.

Check which flow your providers implement before you carry that into a review. The spec defines a second, asynchronous flow in which the DNS provider hands the service an OAuth access code, which the service exchanges for a bearer token and uses to apply templates over time. That is a stored credential with a different shape, not the absence of one, and it is not hypothetical for us: of our two Domain Connect providers, IONOS runs the asynchronous flow.

Your record set is simple and stable

Templates describe a fixed set of records with variables substituted in. Two CNAMEs and a TXT fit that shape well. Record sets that vary by tenant plan, region, or mail configuration fit poorly, and you will spend your time resubmitting templates instead of shipping.

If two or more of those describe you, build.

When a managed service is the right call

The inverse cases are about spread, and about what happens after the records exist.

Your users are spread thin across providers. If connected domains land on thirty different DNS hosts with a long tail, the protocol covers a slice and the fallback path carries the rest. You are then maintaining a custom-domain product as a side project, which is the expensive version of this decision rather than the cheap one.

TLS is the actual problem. DNS is the visible step. Certificates are the part that fails quietly, between issuance, renewal, rate limits, and per-tenant isolation at the edge, and the protocol does not touch any of it. We cover the mechanics in automating TLS for customer domains, multi-tenant TLS, and on-demand TLS.

You want the flow, not the protocol. What most teams are buying is the connection experience: the widget the customer sees, and what it says when the record is wrong. We ship that as an embeddable widget with customdomain-js and @customdomain/react, a 67-endpoint REST API, and an MCP server that has been in the official MCP registry since July 2026 with 12 tools. The full path is on our how it works page.

The work does not stop at go-live. Domains break after launch, usually because somebody else changed something. Monitoring, alerting, and a support path for "it worked last week" is a standing function, and Entri is right to list it as a DIY cost.

Where our pricing is the wrong shape

Both price lists are in the table above, ours in full on our pricing page and Entri's on theirs. Two honest limitations on our side.

Our tiers are flat blocks of included volume rather than per-domain metering. That is simpler to budget and it can cost more at awkward in-between volumes; if that is your shape, price it against metered vendors before you commit, and our comparisons of Approximated and Cloudflare for SaaS carry their published rates and the dates we checked them.

And 38 of our 63 providers are still guided manual: the customer copies a record and we verify it automatically rather than writing it for them. We publish that ratio because the alternative is a coverage table that quietly treats "supported" and "automated" as the same word.

The short version

Domain Connect is a good standard, we contribute to it, and it is not a coverage strategy on its own. The parts of a custom-domain feature that cost money are mostly the parts the protocol does not cover. Build on it if you are a DNS provider, if your users concentrate at a few hosts you have measured, if you ship software other people operate, or if a third party cannot hold credentials to customer zones. Buy if your users are spread out, or if TLS and monitoring are the real work. Our guide to adding custom domains to your SaaS takes the same decision from the product side, and you can book a walkthrough against your own provider mix.

What a merged template does and does not mean, and why the count is a poor proxy for coverage, is the subject of what 18 Domain Connect templates do not buy you.