Connect a Domain Chief domain

This page covers what is specific to Domain Chief: where the records live in their panel, what they call the fields, and the one ordering problem that will take your domain down if you get it wrong.

Add a custom domain covers the parts that are the same everywhere: adding the domain to your project, the two values you copy, verification and SSL. Read that first and keep it open, because the values below come from there.

Records live under Domains → your domain → DNS → Manage DNS records. The field deploybase calls a value, Domain Chief calls Content.

Point a subdomain at your project

To connect blog.example.com:

Type	Name	Content	TTL
CNAME	blog	your domain’s CNAME target	5 minutes
TXT	_deploybase-verify.blog	your verification token	5 minutes

Name takes the relative part only, so enter blog and Domain Chief appends .example.com. Entering the full blog.example.com creates a record for blog.example.com.example.com.

A five-minute TTL keeps a mistake cheap while you are setting up. Raise it once the site is live.

Point a root domain at your project

Domain Chief supports ALIAS natively, so the root domain case needs no workaround:

Type	Name	Content	TTL
ALIAS	empty, or @	your domain’s CNAME target	5 minutes
TXT	_deploybase-verify	your verification token	5 minutes

An empty Name and @ both mean the domain itself. Remember that the root and www are separate domains in deploybase with different CNAME targets: copying one into both records is the usual reason one hostname works and the other does not.

Redirect one hostname to the other

Domain Chief’s redirects answer over HTTPS, so https://example.com reaches visitors without a certificate warning. Open Manage redirects and mail forwarding, then create redirect. Leaving Subdomain empty covers both the root and www.

A redirect takes over the address records at that hostname, so if the name is currently serving your site, Domain Chief shows a Review changes conflict preview first. Read it before confirming. Their redirect guide covers path and query handling.

Check what resolvers actually see

If verification does not pass, their DNS checker tells you what public resolvers are returning before you start changing records. It separates a propagation delay from a record that went in wrong.

Delegating DNS to deploybase instead

Letting us host the zone is the other route, and it has a Domain Chief specific trap.

Remove DNSSEC first, and allow 24 hours

Domain Chief manages DNSSEC while the domain uses its nameservers, so your domain is probably signed even if you never switched it on. Our zone is unsigned, so delegating while the DS record is still published makes validating resolvers reject every answer, and the domain goes dark for a large share of visitors even though the nameservers are correct.

Manage nameservers → Use custom nameservers removes their managed keys, but that change can take up to 24 hours to reach the registry. Do it as its own step, wait a full day, confirm the domain no longer publishes a DS record, and only then enter the deploybase nameservers. Their nameserver guide gives the same ordering.

Keeping the zone at Domain Chief with an ALIAS record avoids this entirely, and is what we would do.

Automating it

Domain Chief has a REST API and an MCP server at https://domain.chief.app/mcp, so an agent can register a name and wire it up in one pass alongside ours. DNS writes need the domainchief:dns:write scope.

Review what an agent proposes before it applies a change. A wrong record is quick to write and slow to propagate away.

While you are building an integration, point it at one of their free .example domains: they run the real workflows and never reach a public registry.

---

Any provider with ALIAS, ANAME or CNAME flattening works the same way. See the DNS provider comparison for which European providers qualify, and for our disclosure about Domain Chief.