Connecting a domain you own
The five steps
The panel in Settings → Domain & DNS states the whole sequence in one line:
Add domain → publish TXT token → verify → point traffic → set primary.
Nothing here happens on a schedule. Each step waits for you.
Add the hostname
Type the hostname exactly as you want it used — example.com,
www.example.com, or pay.example.com. It is lowercased, any port or
trailing dot is stripped, and it is checked for shape: two labels minimum,
letters, numbers, dots and hyphens only, no segment over 63 characters, no
segment starting or ending with a hyphen.
A hostname can be attached to exactly one site, platform-wide. If somebody else has it attached already, you are told it is taken rather than given a half-working second claim.
Publish the ownership TXT record
Adding the hostname generates a verification token. Publish it as a TXT record in your DNS:
| Value | |
|---|---|
| Type | TXT |
| Host | bd-site-verification for an apex domain, or bd-site-verification.www for a subdomain |
| Value | The token shown in the panel |
| TTL | 300, or Auto |
The check accepts the token on either the verification label or on the hostname itself, because DNS interfaces disagree about how to express "the apex". Whichever your provider makes easy is fine.
Verify
Click the DNS check. BusinessDash reads your TXT records and looks for the token. The result is recorded on the domain along with the time of the check, so you can tell "never checked" from "checked and failed".
If it fails, the panel says the token was not found on the requested hostname. That is almost always propagation — wait and check again — or the host field being wrong.
Point traffic at the platform
Verification proves the domain is yours. It does not move any traffic. For that you add one more record:
| Your hostname is | Record type | Host |
|---|---|---|
A subdomain (www.example.com) | CNAME | the subdomain label |
The apex (example.com) | ALIAS, ANAME, or a flattened CNAME | @ |
The value is the platform's delivery hostname, shown in the panel. An apex
needs aliasing support from your DNS provider, because a plain CNAME is not
legal at the apex of a zone.
Set it primary
A verified hostname can serve your site. Making it primary is what makes it the address BusinessDash treats as canonical — the one used for canonical links and the public URL of the site.
Only a verified domain can be made primary, and setting one primary clears the flag from the others, so a site always has exactly one.
Verification states
| State | Meaning |
|---|---|
pending | The hostname is on record and the check has not passed yet |
verified | The TXT token was found. The hostname can serve the site and can be made primary |
failed | The last check ran and did not find the token |
The platform subdomain your site was created with skips all of this: it is inserted already verified, because the platform owns that domain and there is nothing for you to prove.
Resetting the token
If the token was published somewhere public, or the DNS was wrong and you want
a clean slate, reset the verification. That mints a new token and puts the
hostname back to pending. The old token stops being accepted.
Resetting only applies to a hostname you connected. The platform subdomain has no token to reset.
Detaching, and the three-day cooldown
Removing a hostname from a site detaches it: the domain stops serving, its
verification goes back to pending, and it is stamped with a cooldown that
ends three days later.
You cannot remove the primary domain. Promote another one first — a site with no primary address is a site with no canonical URL.
During the cooldown the hostname cannot be claimed by a different site. That window exists because a hostname is a global claim: without it, a detached domain could be picked up by another workspace while your DNS still pointed at the platform, and their pages would answer at your address.
Re-attaching it to the same site is not blocked by the cooldown. The cooldown is about somebody else claiming it, not about you changing your mind.
What gets recorded
Every attach, verification check, primary change and detach is written to the site's domain event history, with who did it and when. If an address stopped working and nobody remembers touching it, that history is the answer.
What is not surfaced yet
- Certificate status. Certificates are issued by the hosting layer once a verified domain is added to it. There is a field for certificate state on the domain record, but nothing writes it, so the panel cannot tell you where a certificate is in its lifecycle. In practice: if the domain verifies and your routing record is correct, HTTPS follows.
- Redirecting extra domains to the primary. A site can have several
verified hostnames, and each one serves the site directly. There is a
redirect to primaryflag on the record, but nothing reads it yet — soexample.comandwww.example.comboth serve, rather than one redirecting to the other. If you want only one address answering, connect only one.