You can serve your MCP connector from a domain you own, so users install https://mcp.yourco.com/mcp instead of a platform hostname. The setup is two DNS records: a TXT record that proves you control the domain, and a CNAME that points traffic at your app. Verification gates routing, and TLS certificates are issued and renewed automatically.
How do you connect a custom domain?
Four steps, three of which are copy-paste:
- Add the domain, say
mcp.yourco.com, to your project. You get back a verification token. - Create a TXT record at
_denkops-verify.mcp.yourco.comcontaining that token. - Create a CNAME from
mcp.yourco.comto your app's<slug>.denkops.hosthostname. - Trigger the verification check. Once the TXT record is found, the domain is verified, routing turns on, and a certificate is provisioned for HTTPS.
DNS propagation can take a few minutes depending on your provider, and re-checking is safe, so if the first verification attempt comes back negative, wait briefly and check again. Nothing else changes about your app: same code, same connector OAuth flow, same /mcp endpoint, now answering on your name.
Why does verification gate routing?
Because a domain should never serve traffic for someone who does not control it. The TXT record at _denkops-verify.<domain> is the proof: only someone with access to your DNS can create it. Until that proof exists, the platform will not route requests for the domain to your app, so nobody can claim mcp.yourco.com by just typing it into a form. Ownership first, traffic second. It is the same nothing-by-accident stance as auth by default, applied to naming.
Why give a connector a branded domain?
For a connector, the URL is the product surface. It is what users paste into their assistant when they add your connector to Claude, what your docs print, what a teammate forwards in chat. Two things follow.
First, trust. https://mcp.yourco.com/mcp tells a user exactly whose tools they are approving on the OAuth consent screen. A platform hostname works, but your own domain reads as yours.
Second, and this is the one that pays off later: a domain you own survives replatforming. Every installed connector, every doc page, every saved configuration points at mcp.yourco.com. If you ever move the backend, you move a CNAME, and every existing install keeps working. Publish a platform hostname instead, and migrating means asking every user to remove and re-add your connector. URLs outlive infrastructure decisions. Put the one you ask people to save on a name you control.
The certificate side needs no attention at any point. As the features page puts it, point your own domain at an app and HTTPS is set up for it automatically, issuance and renewal included.