Add Domain Connect to your SaaS: one-click domains

Custom domains are one of the most valuable things you can offer customers, and one of the most painful to set up. "Create a CNAME record pointing to..." is exactly where a lot of onboarding flows quietly lose people. Domain Connect fixes that, and BeeRanked is now a Domain Connect provider: customers on a supported DNS host can connect their domain to BeeRanked with a single click, with no DNS editing by hand.

This post explains what that means, then walks through exactly how you can add Domain Connect to your own product, using what we built for BeeRanked as the worked example.

What Domain Connect is

Domain Connect is an open standard, backed by GoDaddy, IONOS, Cloudflare and around twenty other DNS providers, for applying DNS changes on a user's behalf with their consent. Instead of telling a customer "create a CNAME record for content pointing to connect.beeranked.online", you send them to a single link. Their DNS provider shows a consent screen listing the exact records, they click apply, and the records appear. No copy-paste, no support ticket.

There are three roles, and knowing which one you are matters:

The DNS provider hosts the customer's domain (Cloudflare, GoDaddy, and so on). They implement the protocol.
The service provider is you, the SaaS that needs records added. You publish a template describing those records.
The user owns the domain and clicks one button.

To offer one-click setup, you become a service provider. Here is how.

Why it is worth doing

Asking a non-technical customer to hand-edit DNS is the single biggest drop-off in most custom-domain flows. Domain Connect removes the typos, the wrong record types, and the "where do I even paste this" support tickets. Your customer goes live in seconds, on the DNS provider they already use, and you get fewer failed setups to chase.

Step 1: Decide exactly which records you need

Keep it minimal. For BeeRanked it is a single record: a CNAME at the customer's chosen subdomain (for example content) pointing to connect.beeranked.online, the host that terminates TLS and serves their content. Most SaaS setups are one CNAME, sometimes a CNAME plus a TXT for verification. Write down the type, host, and target. That is your template.

Step 2: Write the template

A Domain Connect template is a small JSON file. The fields that matter:

providerId: your domain, for example beeranked.online. It becomes part of the apply URL.
providerName: your brand name, shown on the consent screen.
serviceId: a short id for this specific setup, for example content.
serviceName and description: what the user reads before approving.
records: the array of records to apply, each with type, host, pointsTo, and ttl.
hostRequired: true: required by the schema whenever you place a CNAME at the root host (@) and let the user pick the subdomain at apply time. Leave it out and the template fails validation.

The file is named providerId.serviceId.json, so ours is beeranked.online.content.json.

Step 3: Test it in the official editor

Before anything else, paste your template into the Domain Connect online template editor and run its tests. This is not optional: the registry will not review a submission that does not link to editor test results. Fix whatever the JSON-Schema check or the template linter flags.

Step 4: Publish it to the registry

For providers to recognise your template, it has to live in the public Domain Connect template registry. Open a pull request that adds your providerId.serviceId.json to the root of the repository, with the link to your editor test results. It needs to pass the schema, the linter, and a short list of quality guidelines. Once it is merged, providers can sync it.

Step 5: Sign your requests (recommended)

Signing lets providers verify a request genuinely came from you, and it unlocks the smoothest flows. Generate an RSA key pair, keep the private key on your server, and publish the public key as a DNS TXT record at _dck1.<your-providerId>. For BeeRanked that is _dck1.beeranked.online. Then sign the apply URL's query string with your private key and pass sig and key parameters.

One gotcha that cost us real time: a 2048-bit public key is longer than a single DNS TXT string can hold, which is capped at 255 characters. The fix is to split the key across two TXT records at the same name, each tagged with its part: p=1,a=RS256,d=<first half> and p=2,a=RS256,d=<second half>. Do not put multiple strings inside one record. Some providers re-chunk those at 255 characters and break the per-part header.

Step 6: Get providers to actually adopt it

This is the part the documentation glosses over. Merging your template into the registry does not instantly make it work everywhere. Some providers auto-sync the public registry on their own schedule, including GoDaddy, IONOS, 1&1 and Plesk. Others, notably Cloudflare and Squarespace, do not ingest third-party templates automatically. They onboard them directly.

For Cloudflare we emailed domain-connect@cloudflare.com following the instructions at developers.cloudflare.com. They reviewed and onboarded our template, and switched it live globally. If a meaningful share of your customers are on Cloudflare, and many are, plan for that conversation rather than assuming the merge is enough.

Until a given provider has loaded your template, the apply URL returns a 404. That 404 is upstream of signing: it means the provider has not synced your template yet, not that your key is wrong. Worth knowing when you are debugging.

Step 7: Wire the one-click flow into your app

With the template live, the in-app flow looks like this:

1. Discover the provider. Query the _domainconnect TXT record on the user's domain (we do it over DNS-over-HTTPS). It points at the provider's Domain Connect settings.

2. Read the settings to get the provider's urlSyncUX, the base of their apply screen.

3. Build the apply URL: <urlSyncUX>/v2/domainTemplates/providers/<providerId>/services/<serviceId>/apply?domain=<their-zone>&host=<chosen-subdomain>, plus your sig and key if you sign.

4. Send the user there. They see the consent screen, click apply, and the records are written.

5. Poll for live. Watch for the record to resolve and your certificate to issue, then flip the UI to "connected".

Always keep a manual fallback. Show the raw record (type, host, target) for users whose provider does not support Domain Connect, or has not adopted your template yet. One-click is the upgrade, not the only path.

Two hard-won tips

Never truncate the sig value when you log or share an apply URL. A chopped signature makes the provider say "this URL is not verified", which looks like a key failure but is not.
Keep the template's pointsTo in sync with whatever your edge actually expects. If you ever change the target host, re-submit the template.

Where BeeRanked fits

This is exactly the flow behind BeeRanked's one-click custom domains. If you publish content with BeeRanked, connecting it to a subdomain of your site is a single click on a supported provider, and a single copy-paste record everywhere else. And if you are building your own SaaS, the steps above should save you the week of trial and error they would otherwise cost.