# Connection paths by provider > How CustomDomain™ picks the way in for each domain: provider sign-in, one-click setup, secure sign-in, an API key, records added by hand or DNS hosting. Source: https://docs.customdomain.ai/docs/dns/providers When a customer enters a domain, we look up its nameservers to see who hosts its DNS, then offer the easiest way in that works at that provider. There are six [ways to connect](/docs/concepts/glossary#ways-to-connect), and the first five are offered in this order: 1. **Sign in with the provider** (OAuth) or **approve access at the provider**: one click and nothing to paste. Whether the sign-in is kept afterwards depends on the provider (see below). 2. **One-click setup** (Domain Connect): the provider applies our signed template after the customer approves it on the provider's site, then sends the customer back. 3. **Secure sign-in**: for a provider that offers no sign-in a third party can use. The customer signs in to the provider in a temporary browser, and where the provider allows it our software makes a lasting API key there; otherwise it edits the provider's DNS page for that one domain. A change that only adds records goes ahead by itself; one that replaces or removes a record waits for the customer's approval. Offered to selected workspaces for now (see [With secure sign-in](#with-secure-sign-in)). 4. **An API key**: the customer creates a scoped credential at the provider and pastes it; we write the records for them. At Amazon Route 53 an **access role** comes first: the customer lets our AWS account change the zone, with no secret to paste. 5. **Add the records**: the exact rows to copy, with provider-specific steps and a link to the provider's DNS page. This works at every provider. The sixth, **DNS hosting**, is offered beside these rather than after them: the domain's owner changes its nameservers once, where the domain was bought, and CustomDomain™ hosts the zone and writes every record. Your customers are offered it only when your application turns it on. See [Managed DNS](/docs/dns/managed-dns). CustomDomain™ knows more than 200 DNS hosts, registrars and domain platforms, among them every one of the 100 largest registrars (by domains under management in ICANN's registry reports for May 2026), and names most of them from the domain's nameservers. Knowing a provider is not the same as writing its records: most registrars give no third party a way to change DNS, so for them adding the records, with that provider's own steps (or a secure sign-in where one is offered), is the way in. The tables below are what the hosted service offers as of 2026-10-09. On 2026-10-31 the census lists 217: 73 have an automatic path (6 provider OAuth, 1 Domain Connect, 66 scoped API key) and the other 144 are connected by hand. The adapters are a separate count: `GET /v1/providers` lists 77, and every one of them belongs to a provider the census lists. The console and the widget read the same verdict from `POST /v1/domains:check` (its `rails` block and `recommended_rail`), so they never disagree about what to show. `GET /v1/providers` lists every adapter and `GET /v1/providers/census` routes every known provider to its mode. Root domains (`acme.com` rather than `www.acme.com`) depend on what the provider can hold at the zone apex; see [Root domains](/docs/dns/root-domains). For records only you know (SES DKIM, a verification `TXT`), see [Bring your own records](/docs/dns/bring-your-own-records). ## One click, nothing to paste | Provider | How it connects | Notes | | --------------------------------------------------------------------- | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cloudflare | **Sign in with Cloudflare** | A root CNAME is fine: Cloudflare flattens it. | | DigitalOcean, DNSimple, Linode (Akamai Cloud), Netlify, WordPress.com | **Sign in with the provider** | Netlify writes need the domain on Netlify DNS. | | Azure DNS | **Sign in with Azure DNS** | Use a Microsoft account that can edit the domain's public zone; we find the subscription and resource group that hold it. Users in other organizations see an unverified publisher warning, and an organization that limits user consent needs an admin to approve the app. A subscription ID, a resource group and an access token work too. | | Google Cloud DNS | **Sign in with Google Cloud** | Use the Google account that can edit the domain's public Cloud DNS zone; we find the Google Cloud project that holds it. Until Google finishes reviewing the app, Google may show a notice that it has not verified the app yet. A project ID and an access token work too. | | Vercel | **Install CustomDomain™ on Vercel** | The sign-in is our Vercel integration: install it on the Vercel team that owns the domain. | | Porkbun | **Approve access at Porkbun** | Porkbun adds an API key named for CustomDomain™ to the account. Porkbun only lets the API change domains that have API Access turned on. | | Dynadot, Unstoppable Domains | **Sign in with the provider**, through the provider's own MCP server | Dynadot lets you sign in only once MCP is on: in Dynadot, open **Tools**, **API**, click **Unlock your account** and switch **MCP Enabled** on. Dynadot also connects with an API key. | | NameSilo, Glauca Digital, Domain Chief | **One-click setup** (Domain Connect) | These providers serve our templates. | | Amazon Route 53 | **Access role** (recommended) | Create a role in your AWS account that lets us change this zone; nothing secret to paste. An IAM access key works too. | On the hosted service, a sign-in or approval at Cloudflare, DigitalOcean, DNSimple, Linode, Netlify, Porkbun, Vercel or WordPress.com is kept by default as an encrypted grant, so we can put the records back later and remove them when the domain is disconnected, without asking again. In the console, untick **Keep this sign-in** to use it once instead; the widget tells the customer the permission is kept. Every other sign-in (Azure DNS, Dynadot and Unstoppable Domains) is used once to write the records and then dropped, which means we cannot repair those records later without asking again. See [Managed connections](/docs/connect-flow/managed-connections#managed-sign-in-grants). ### Built, but not switched on yet These sign-ins exist in the product but are not offered on the hosted service today, so none of them appears in the console or the widget: * **Grant access at OVHcloud**: a consent page limited to the domain's zone, which needs an OVHcloud application for each region a deployment serves. The hosted service has none, so OVHcloud connects with an application key. * **Sign in through the provider's MCP server** (Hostinger, Namecheap, Spaceship, XServer Domain and Muumuu Domain): the provider's own MCP server signs the customer in and its DNS tools write the records. Each one is switched on only after the provider approves CustomDomain™ and a live test passes. Until then Hostinger, Namecheap and Spaceship connect with an API key (Namecheap only for accounts that qualify), and XServer Domain and Muumuu Domain take the records by hand. ### Speaks one-click setup, but has not onboarded our templates GoDaddy, IONOS, Aruba and Squarespace answer Domain Connect discovery but have not onboarded our templates, so the console does not offer a one-click button that would end on the provider's error page. Cloudflare and Vercel answer too and serve none of our templates, and WordPress.com has not onboarded them either; for those three, the sign-in is the one-click path. Until each provider onboards the templates, GoDaddy and IONOS connect with secure sign-in, where it is offered, or an API key; Squarespace connects with secure sign-in, where it is offered, or by hand; and Aruba takes the records by hand. ## With secure sign-in Secure sign-in is for providers that offer no sign-in a third party can use. The hosted service has it on at eight of them, for the workspaces it is switched on for: Namecheap, GoDaddy, IONOS, Name.com, Squarespace, Hover, Spaceship and Hostinger. At six of them it also makes a lasting API key on the provider's own API page (Namecheap, GoDaddy, Name.com, Spaceship, Hostinger, and IONOS's US site), and the domain is then connected through the provider's API like any other key. At the others, and wherever no key can be made, our software edits the provider's DNS page for that one domain once the customer approves the changes. Network Solutions and Wix are not offered yet. `POST /v1/domains:check` says per domain whether it runs (`rails.cloud_browser`), and where it makes a key, `rails.cloud_browser.key` says what the key can do beyond DNS (`rights`) and when it ends. See [Secure sign-in](/docs/guides/secure-sign-in#which-providers), and [GoDaddy](/docs/dns/provider-setup#godaddy) and [Namecheap](/docs/dns/provider-setup#namecheap) for those two. ## With an API key The console asks for each part as its own labeled field, links the page where the credential is created, and lists the steps; see [Provider setup](/docs/dns/provider-setup) for every provider's steps. | Provider | What you create | Before you start | | -------------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | GoDaddy | Personal Access Token with `domains.domain:read` and `domains.dns:update` | Any account that holds a domain can create one. One-click setup is waiting on GoDaddy's onboarding. Secure sign-in makes the token for you, where it is offered. | | Namecheap | API key (and your username) | Only accounts with 20 or more domains, a $50 balance, or $50 spent in the last 2 years; whitelist `100.48.24.176`. Not for domains on Namecheap hosting DNS. Secure sign-in turns the API on for you, where it is offered. | | Amazon Route 53 | IAM access key (plus the session token for temporary `ASIA` keys) | The access role above is the recommended alternative. | | Alibaba Cloud DNS | RAM AccessKey ID and secret (plus an STS security token for temporary credentials) | The domain must already be a zone in Alibaba Cloud DNS. | | 101domain | API key with the DNS read and DNS write scopes | Only the account's primary user can make one. The domain must use 101domain's nameservers. | | ALL-INKL.COM | KAS login and password (plus the one-time code with two-factor login) | Used once and never stored. | | Arsys | Hosting domain and DNS API password | Activate the DNS API in the Panel de Control. Used once and never stored. | | Azure DNS | Subscription ID, resource group and an access token | Tokens expire within about an hour, so they are used once. Sign in with Azure DNS is the easier way in. | | Azion | Personal Token | The token needs access to Edge DNS, and the domain must already be a zone in your Azion account. | | Binary Lane | API token | A token can manage your whole account, so it is used once and never stored; delete it in mPanel afterwards. The domain must use Binary Lane's nameservers. | | Bunny DNS | Account API key | | | ClouDNS | API user (or API sub-user) and password | API access comes with ClouDNS's paid plans. | | Combell | API key and secret (a combell.nl account chooses its own site) | The API comes with Reseller Hosting. Allow `100.48.24.176` under IP restrictions. The domain must use Combell's nameservers. | | Constellix | API key and secret key | | | cPanel hosts | cPanel username, API token and server hostname | For hosts that run cPanel; we connect on port 2083. | | deSEC | API token | | | DigitalOcean | Personal access token with the domain scopes | Or sign in with DigitalOcean. | | DirectAdmin hosts | DirectAdmin username, Login Key and server hostname | For hosts that run DirectAdmin; we connect on port 2222 (or 443 when you add `:443` after the hostname). The server must be reachable from `100.48.24.176` and use a certificate a browser trusts. You choose it yourself, since nothing detects DirectAdmin from nameservers. | | DNSimple | Account API access token | Or sign in with DNSimple. | | DNS Made Easy | API key and secret key | | | Domeneshop | API token and its secret | The domain must use Domeneshop's DNS service (ns1 to ns3.hyp.net). | | DreamHost | API key with the `dns-*` functions | | | Dynadot | Production API key and its API secret | Whitelist `100.48.24.176` in Dynadot's API settings. With the key alone, records can only be added, not changed or removed. Or sign in with Dynadot. | | easyDNS | REST API token and key | | | Epik | API signature | Allow `100.48.24.176` in Epik's API settings. | | Exoscale | IAM API key and secret, from a role that allows only the DNS service | The domain must already be added under DNS. You choose it yourself: its zones use DNSimple's nameservers, so a domain there is detected as DNSimple. | | Gandi | Personal access token with "Manage domain name technical configurations" | | | Gcore | Permanent API token | The token can change every zone in your account. The domain must use Gcore's nameservers. | | GleSYS | API key with Domain access, and the project ID | | | Google Cloud DNS | **Sign in with Google Cloud**, or a project ID and an access token | The sign-in finds the project that holds the zone. Tokens expire within an hour, so they are used once. | | Hetzner | Hetzner Console project API token (Read & Write) | Tokens from the old DNS Console no longer work. | | hosting.de | API key with Display and Edit under DNS Service, Zones | The domain's DNS zone must be at hosting.de. | | Hostinger | hPanel API token | | | Huawei Cloud DNS | IAM Access Key ID and Secret Access Key | Use a sub user's key with only DNS record permissions. | | Infomaniak | API token with `dns:read` and `dns:write` | The zone must be at Infomaniak. The API allows 60 requests a minute. | | Internet.bs | API key and API password | Allow `100.48.24.176` under API allowed IP address(es). | | INWX | Username and password of a sub account with only the DNS role | No Mobile TAN. Used once and never stored. | | IONOS | API key (public prefix and secret) | | | Joker.com | DMAPI API key from a free Joker.com reseller account | The domain must be in that account and use Joker.com's own nameservers. A write replaces the whole zone, so a zone with a record type the API cannot write back is refused. | | Linode | Personal access token with Domains read/write | Or sign in with Linode. | | Loopia | API user and password | Needs LoopiaDNS or web hosting. Used once and never stored. | | LuaDNS | API key and account email | Turn on API access first. | | Metaname | Account reference and API key | The key can change every zone in the account. The domain must use Metaname's own nameservers. | | Moniker | API key and password | API access is activated by Moniker support; give it `100.48.24.176` when you request the key. | | Mythic Beasts | API key ID and secret | The domain must use Mythic Beasts DNS (ns1 and ns2.mythic-beasts.com). | | Name.com | API token and username | With two-step verification on, also switch on Name.com API Access. | | NameBright | API application (account, application name, secret) | NameBright grants API access on request; whitelist `100.48.24.176` on the application. | | NameSilo | API key | Or use one-click setup. | | netcup | API key alone for CloudDNS, or the customer number, a Legacy API key and the API password for the classic nameservers | The domain must use netcup's own nameservers. | | Netlify | Personal access token | Or sign in with Netlify. | | Njalla | API token | | | NS1 | API key secret with the DNS permission Manage zones | The domain must be a primary zone of the account. If the account or the key has an IP allow list, include `100.48.24.176`. | | Openprovider | API token from `/v1beta/auth/login` | API access must be enabled for the user; tokens last 48 hours, so they are used once. | | OVHcloud | Application key, application secret and consumer key (Europe, Canada or United States) | Grant access at OVHcloud works only where a deployment has registered OVHcloud applications; the hosted service has not. | | Plesk hosts | Plesk username, password and server hostname | For hosts that run Plesk; we connect on port 8443 (or 443 when you add `:443` after the hostname). The server must be reachable from `100.48.24.176` and serve a trusted certificate. Used once and never stored. You choose it yourself, since nothing detects Plesk from nameservers. | | Porkbun | API key and secret key | Turn on API Access for the domain. Or approve access at Porkbun. | | Scaleway | Secret key of an IAM API key | Needs the permission set `DomainsDNSFullAccess` on the Project that holds the domain. | | Simply.com | API key and account number | | | Spaceship | API key and secret with the DNS record scopes | | | Subreg.cz | Subreg login and password | Used once and never stored. Allow `100.48.24.176` if Subreg refuses the address. | | Tencent Cloud DNSPod | Tencent Cloud API key (SecretId and SecretKey), ideally from a CAM sub-user allowed only the DNSPod record actions | Choose the China or International site the account is on. Records are written on the Default line; other lines are left alone. | | TransIP | Access token | Switch off the token's whitelisted IP option, or whitelist `100.48.24.176`. | | united-domains | DNS API key | Needs the DNS API add-on. | | Vercel | Access token | Or install CustomDomain™ on Vercel. | | Vultr | API key | Add `100.48.24.176/32` under Access Control. | | webnames.ca | API user and API key | Needs the Domain and Account Management Toolkit add-on and DNS Hosting. Writes only A, AAAA, CNAME and TXT records. | | Websupport | API key and secret | The key can change every domain in the account, so make one just for this. | | WEDOS | Account email and a separate WAPI password | WAPI must be turned on with `100.48.24.176` allowed in the client panel. | | Wix | Account level API key and the Account ID | Only the account owner can make the key. The domain must be registered at Wix or connected to a Wix site by nameservers. | | Zone.ee | ZoneID username and API key | The key can change every zone in the account, so make one just for this. | `100.48.24.176` is the address the hosted service's DNS writes come from (the control plane's `CONNECT_CLIENT_IP`). Plesk, DirectAdmin and Exoscale are chosen by the customer, and nothing detects them from a domain's nameservers. Plesk and DirectAdmin run on a hosting company's own servers, which carry that company's nameservers, the same as cPanel hosts; an Exoscale DNS zone uses DNSimple's nameservers, so a domain there is detected as DNSimple. The census also lists PowerDNS as an API key provider. PowerDNS is software people run on their own servers, and the hosted service has no way to be told where a customer's server is, so it is not a provider the hosted service can write to. Of the 77 adapters, the hosted service writes records through 74: the other three are PowerDNS and the two sign-ins through a provider's MCP server (XServer Domain, Muumuu Domain) that are built but switched off. Since 2026-10-21 the census also lists the eleven providers with an adapter that it used to leave out: Azure DNS, Bunny DNS, Constellix, deSEC, DNS Made Easy, GleSYS, Akamai Cloud (Linode), LuaDNS, Njalla, PowerDNS and Vultr, each as an API key provider. ### Using a provider token through the API The BYO-token rail writes a connection's records with the customer's own credential: ```bash curl -X POST https://api.customdomain.ai/v1/connections//apply \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "provider": "cloudflare", "credential": { "token": "" } }' ``` `credential.token` carries every part of the credential in one string. The console builds it from the separate fields; through the API you send it yourself: | `provider` | `credential.token` | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `godaddy` | the Personal Access Token (a classic `key:secret` pair still works) | | `namecheap` | `apiUser:apiKey`, optionally `:userName` and `:clientIp` | | `route53` | `accessKeyId:secretAccessKey`, plus `:sessionToken` for temporary keys | | `alidns` | `accessKeyId:accessKeySecret`, plus `:securityToken` for STS credentials | | `allinkl` | `login:password`, plus `:otp` with two-factor login | | `arsys` | `hostingDomain:apiPassword` | | `azuredns` | `subscriptionId:resourceGroup:accessToken` | | `cloudns` | `authId:password`, `sub:subAuthId:password` or `subuser:subAuthUser:password` | | `combell` | `apiKey:apiSecret`, prefixed with `nl:` for a combell.nl account | | `constellix`, `dnsmadeeasy`, `spaceship` | `apiKey:secret` | | `cpanel`, `o2switch` | `user:token:host` | | `directadmin` | `user:loginKey:host` (the host may carry a port, 2222 or 443) | | `dnspod` | `secretId:secretKey`, prefixed with `intl:` for a Tencent Cloud International account | | `domeneshop` | `token:secret` (the secret may contain colons) | | `dynadot` | `apiKey:apiSecret` (the key alone still adds records, but cannot change or remove them) | | `easydns` | `token:key` | | `exoscale` | `apiKey:apiSecret` | | `gcpdns` | `projectId:accessToken` | | `glesys` | `projectId:apiKey` | | `huaweicloud` | `accessKeyId:secretAccessKey` | | `internetbs` | `apiKey:apiPassword` | | `inwx` | `username:password` (the password may contain colons) | | `ionos`, `uniteddomains` | `publicPrefix.secret` (one key, prefix and secret joined by a dot) | | `loopia` | `apiUser:apiPassword` (the API user ends in `@loopiaapi`; the password may contain colons) | | `luadns` | `email:apiKey` | | `metaname` | `accountRef:apiKey` (split on the first colon, so the key may contain colons) | | `moniker` | `apiKey:password` | | `mythicbeasts` | `keyId:secret` (split on the first colon, so the secret may contain colons) | | `namebright` | `account:appName:secret` | | `namecom` | `username:token` | | `netcup` | `customerNumber:apiKey:apiPassword` on the classic nameservers (the password may contain colons), or the API key alone on CloudDNS | | `ovh` | `appKey:appSecret:consumerKey`, prefixed with `ca:` or `us:` outside Europe | | `plesk` | `login:password:host` (the password may contain colons; the host may carry a port, 8443 or 443) | | `porkbun` | `apiKey:secretApiKey` | | `simply` | `accountNumber:apiKey` | | `subreg` | `login:password` (an admin account uses `ADMIN#LOGIN`; the password may contain colons) | | `webnamesca` | `apiUser:apiKey` (split on the first colon, so the key may contain colons) | | `websupport` | `apiKey:secret` (split on the first colon, so the secret may contain colons) | | `wedos` | `login:wapiPassword` | | `wix` | `apiKey:accountId` | | `zoneee` | `username:apiKey` | | every other provider | the single token or key | ## By hand, with provider-specific steps Every provider can be connected by adding the records the console shows, with a link to the provider's DNS page where we know it. For 135 providers and platforms the widget also shows that provider's own steps (where the DNS page is, what the Name field wants for the root, and the pitfalls): 123 Reg, Akamai Cloud (Linode), Alibaba Cloud DNS, ALL-INKL.COM, Amazon Route 53, Arsys, Aruba.it, Atak Domain, Azure DNS, BigCommerce, BigRock, Bluehost, Bolt (bolt.new), Bunny DNS, Canva, Cloudflare, ClouDNS, Constellix, Cosmotown, cPanel, Crazy Domains, deSEC, DigitalOcean, Directnic, DNSimple, DNS Made Easy, Domain Chief, Domain.com, DomainDiscount24, DonDominio, DreamHost, Dynadot, easyDNS, Elementor, eName, Enom, Epik, Fasthosts, Fastmail, FatCow, Freename, Gabia, Gandi, Glauca Digital, GleSYS, Gname, GoDaddy, Google Cloud DNS, GreenGeeks, Hetzner, HighLevel (LeadConnector), home.pl, HostGator, Hosting.com, Hostinger, Hostpoint, Hover, Infomaniak, InMotion Hosting, Internet.bs, IONOS, iPage, isimtescil.net, iwantmyname, Jimdo, Joker.com, Juming, Just Host, Kajabi, Locaweb, Lovable, LuaDNS, METUnic, Microsoft 365, Mijndomein, Moniker, Name.com, NameBright, Namecheap, NameMart, NameSilo, Namify, Natro, Netlify, Network Solutions, NiceNIC, Njalla, Now\.cn, o2switch, Odoo Online, Onamae.com, one.com, Openprovider, OpenSRS, OVHcloud, Papaki, Porkbun, PowerDNS, REG.RU, Register.com, Register.it, Registro.br, ResellerClub, RU-CENTER, Sav.com, Shopify, Simply.com, SITE123, SiteGround, Spaceship, Square Online (Weebly), Squarespace Domains, STRATO, Strikingly, Subreg.cz, Tencent Cloud DNSPod, TransIP, Tumblr, Turbify (formerly Yahoo Small Business), Turkticaret.Net, united-domains, Unstoppable Domains, Vercel, Vultr, Web.com, Webcentral, Webnode, West.cn, Wix, WordPress.com, World4You, Xinnet, xneelo, Yola and Yuqu. Any other provider gets the same records with general steps. Wholesale, corporate and drop-catch registrars rarely give the end customer a DNS panel of their own. Their entries in `GET /v1/providers/census` say who edits the records instead: the reseller that sold the domain, the company's domain administrator, or NameBright for a domain won at DropCatch. ## Domains bought through a site builder or shop Site builders, shops and email suites often sell the domain inside their own product, and then the records go in on that product's DNS screen. Twenty platforms where people buy or keep a domain (mostly those, plus DomainDiscount24 and Just Host) are recognized with their own steps: * **With nameservers of their own**, named from the nameservers: Microsoft 365, Fastmail, Turbify, SITE123, BigCommerce, Jimdo and DomainDiscount24 (which registers domains bought when signing up for Google Workspace), plus Just Host, whose zones are named Bluehost because Just Host now sends its customers there. * **On another provider's nameservers**, offered in the widget's provider list with their steps: Canva, Strikingly, Webnode, Lovable, Bolt, HighLevel, Kajabi, Elementor, Tumblr, Square Online, Yola and Odoo Online. Where a platform keeps its domains on another provider's nameservers, detection would name that provider, whose sign-in or API key cannot reach a zone held in the platform's account. So when the root also points at an address only that platform hands out, detection names the platform instead and shows its steps: a Shopify store on Google Cloud DNS's nameservers, a Tumblr domain on WordPress.com's, and a Canva domain on OpenSRS's shared DNS. The domain is then connected by adding the records in the platform's own settings. ## Where keys are kept Sign-ins and one-click setup store nothing unless the connection is [managed](/docs/connect-flow/managed-connections). On the hosted service a sign-in at Cloudflare, DigitalOcean, DNSimple, Linode, Netlify, Porkbun, Vercel or WordPress.com is kept that way by default (in the console, untick **Keep this sign-in** to use it once). An API key is used for the write and kept only when the customer leaves **Remember this key** ticked in the console (through the API, only when it is connected as a [provider account](/docs/connect-flow/provider-accounts)). A kept key or sign-in is encrypted with AES-256-GCM, used only server-side, and revocable any time on the console's **Connected accounts** page. Account passwords, short-lived tokens and tokens that cannot be limited to DNS (ALL-INKL.COM, Arsys, Binary Lane, Google Cloud DNS, Azure DNS, INWX, Loopia, Openprovider, Plesk, Subreg) are never kept. See [Remembering a key](/docs/dns/provider-setup#remembering-a-key-optional). ## One-click setup (Rail A) One-click setup uses the provider-hosted Domain Connect protocol and is redirect-based: the customer is sent to their provider, which applies a signed template and returns. There is no server-to-server token. Discovery is via `TXT _domainconnect.` and the provider's settings endpoint. Both the synchronous redirect and the asynchronous variant are supported (`POST /v1/connections/{id}/domainconnect:start`). The button is only offered for providers that serve our templates. Every template we publish names our return domains (`syncRedirectDomain`: `api.customdomain.ai`, `app.customdomain.ai` and `customdomain.ai`), since version 2 of the templates was merged into the public Domain Connect template repository on 2026-09-29. So a synchronous apply always carries a signed return link: after the customer approves (or cancels) at the provider, the provider sends the browser back to us, the window closes, and the widget or console that opened it learns the result. The records still count only once public DNS shows them; a return that says "done" is never taken as proof.