Measured nightly · state as of 2026-10-15
State of Domain Connect
Which DNS providers serve DoDomain's 5 registry templates, the ones behind one-click custom-domain setup, and which of those one-click applies have actually been proven on a real zone. 4 of 8 watched providers serve every one of them today. Every cell is a measurement; nothing here is a claim a provider made to us.
| Provider | Probe | custom-subdomain-cname | domain-verification | custom-subdomain-cname-with-verification | apex-a-with-verification | email-authentication |
|---|---|---|---|---|---|---|
GoDaddy domainconnect.api.godaddy.com | API answers control 200 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 |
IONOS api.domainconnect.ionos.com | API answers control 200 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 |
1&1 api.domainconnect.1and1.com | API answers control 200 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 |
Domain Chief domain.chief.app/api/domainconnect | API answers control 200 | served since 2026-07-28 v1, matches registry apply not yet proven | served since 2026-07-28 v1, matches registry apply not yet proven | served since 2026-09-11 v1, matches registry apply not yet proven | served since 2026-09-11 v1, matches registry apply not yet proven | served since 2026-09-11 v1, matches registry apply not yet proven |
Cloudflare api.cloudflare.com/client/v4/dns/domainconnect | API answers control 200 | served since 2026-09-02 v1, matches registry apply proven 2026-09-25 | served since 2026-09-02 v1, matches registry apply proven 2026-09-25 | served since 2026-09-18 v1, matches registry apply proven 2026-09-26 | served since 2026-09-18 v1, matches registry apply proven 2026-09-26 | served since 2026-09-18 v1, matches registry apply proven 2026-09-26 |
Glauca dns.glauca.digital/connect/api | API answers control 200 | served since 2026-08-06 v1, matches registry apply proven 2026-08-12 | served since 2026-08-06 v1, matches registry apply proven 2026-08-06 | served since 2026-09-11 v1, matches registry apply not yet proven | served since 2026-09-11 v1, matches registry apply not yet proven | served since 2026-09-11 v1, matches registry apply not yet proven |
Vercel vercel.com/api/domain-connect | API answers control 200 | served since 2026-10-15 v1, matches registry apply not yet proven | served since 2026-10-15 v1, matches registry apply not yet proven | not served probe answered 404 | not served probe answered 404 | not served probe answered 404 |
NameSilo www.namesilo.com/domainconnect | API answers control 200 | served since 2026-10-15 version not reported apply not yet proven | served since 2026-10-15 version not reported apply not yet proven | served since 2026-10-15 version not reported apply not yet proven | served since 2026-10-15 version not reported apply not yet proven | served since 2026-10-15 version not reported apply not yet proven |
Registry reference: custom-subdomain-cname v1 · domain-verification v1 · custom-subdomain-cname-with-verification v1 · apex-a-with-verification v1 · email-authentication v1. Probed 2026-10-15 12:27 UTC.
Proven one-click applies
A provider serving a template is what the matrix measures. This ledger is the stronger claim: a real signed apply accepted by the provider, the record written, and verified against the zone's authoritative nameservers, on a zone DoDomain controls, with every hop real.
- Glaucadomain-verification2026-08-06
Signed apply accepted, TXT written by HexDNS, verified on all four authoritative nameservers, session completed and webhook delivered.
- Glaucacustom-subdomain-cname2026-08-12
Same zone, CNAME template, after Glauca fixed their CNAME apply bug (AS207960/hexdns#9), which had 500'd every CNAME apply until then.
- Cloudflaredomain-verification2026-09-25
Signed apply accepted on Cloudflare's consent page, TXT written to a Cloudflare-hosted zone and live within 30 seconds, session verified. Cloudflare switched all five DoDomain templates to live mode for every customer the same day.
- Cloudflarecustom-subdomain-cname2026-09-25
Same zone, CNAME template: the first live exercise of the key-before-signature URL order Cloudflare requires.
- Cloudflarecustom-subdomain-cname-with-verification2026-09-26
CNAME plus the ownership TXT under the same host, both written in one approval, verified on the authoritative nameservers, session verified.
- Cloudflareapex-a-with-verification2026-09-26
Apex A plus the ownership TXT. Cloudflare listed the zone's existing apex A for removal and asked for the zone name to be typed before applying; both records verified, session verified.
- Cloudflareemail-authentication2026-09-26
Every group applied and verified: DKIM as CNAME and as TXT, DMARC, and the SPF merge, where Cloudflare folded our include into the zone's existing SPF record and kept its other terms.
Domain Chief and NameSilo serve every template but no apply has been proven on a zone at either yet, Vercel serves the two original templates without a proven apply, and Glauca HexDNS serves the three multi-record templates without a proven apply; until one is proven, DoDomain does not describe that template as one-click on that provider. Everywhere else, and on any provider whose apply fails, the connect flow falls back to guided manual records verified the same way.
How the proven applies were reached, the spec's silence on where sig and key sit, a provider's exponentiation bug, chunked public keys, and why a template probe answering 200 is not a working integration, is written up in Domain Connect field notes.
How the matrix is measured
For each provider the watch first asks its Domain Connect API for a widely-onboarded control template (google.com / domain-verification). Only when that answers 200 is a 404 on a DoDomain template believed; otherwise the provider is marked unchecked, never not served. A 200 carries the served template version, which is compared with the registry master's; a mismatch is drift and shows in red. A provider whose 200 carries no version (NameSilo's does not) shows "version not reported", and drift cannot be judged there. A provider that once served a template and stops is regressed. The probe runs nightly and this page is rebuilt when the measured state changes.
Frequently asked questions
What is Domain Connect?
An open protocol (domainconnect.org) that lets a DNS provider apply a pre-registered set of DNS records to a user's domain after the user approves one screen at the provider, no manual record entry. A service publishes templates to a public registry; each DNS provider chooses which templates it serves. DoDomain's two templates were merged into the registry on 2026-07-24.
What does served mean in the matrix?
That the provider's Domain Connect API answered 200 for the template's support probe that night, with a control probe (a widely-onboarded google.com template) also answering 200 so a 404 could be trusted. It means the provider has enabled the template. It does not, on its own, mean a real apply has been exercised there; that is the separate, dated ledger below the matrix.
What is template version drift?
A provider caches the templates it serves. When the registry copy moves to a new version and the provider keeps serving the old one, users at that provider get the stale records: Cloudflare served a five-week-stale template for another vendor in 2026 (Domain-Connect/Templates#1570). The watch compares the version each provider serves with the registry master's every night and marks a mismatch here, in red.
Why are GoDaddy, IONOS and 1&1 listed as not serving the templates?
Their Domain Connect APIs answer the control probe, so the watch can see them, and they return 404 for DoDomain's templates: they onboard registry templates selectively and have not enabled these yet. On those providers a DoDomain connect flow falls back to guided manual records, which works; it just takes the user a copy and a paste.
How is this page kept current?
A scheduled job probes every listed provider each night at 05:10 UTC and commits the result as a machine-readable JSON file; this page is rebuilt from that file. The date at the top is the date the measured state last changed. A regression (a provider dropping a template it served) or a drift opens an issue for the team the same night.
Check a domain
The provider detector runs this same template probe against the provider serving any domain you type in, and says whether one-click setup would be available there. Building custom domains into a product? Start free.