Custom Domains for SaaS: The Complete Guide (2026)

A practical guide for founders and engineers who need their users on their own domains.

If you run a platform where customers publish something to the world, a store, a help center, a status page, a portal, a landing page, they will eventually ask the same question: can we use our own domain? This guide explains what that feature really involves, why it is harder to build than it looks, and how to ship it without standing up a pile of infrastructure you did not sign up to run.

What are custom domains for SaaS?

Most SaaS platforms start by giving every customer a subdomain of your own domain. A customer named Acme gets something like acme.yourapp.com. That works and it is easy for you to run, because you already own yourapp.com and you already have a certificate for it.

The problem is that acme.yourapp.com is your brand, not theirs. A customer sending that link to their own users is advertising your product every time. When they are ready to look like a real business, they want app.acme.com or portal.acme.com, a hostname on a domain they bought. That is a custom domain. The customer keeps their branding, their SEO, and their trust, and your product quietly powers it underneath.

The feature shows up under a lot of names. You might call it custom domains, white-label domains, vanity domains, bring-your-own-domain, or domain mapping. They all mean the same thing: your customer points a hostname they own at your platform, and your platform serves it correctly over HTTPS.

Why should a platform offer custom domains?

There are a few reasons this feature keeps coming up, and they are worth being honest about.

• It is a revenue lever. Custom domains are one of the cleanest things to gate behind a paid plan. Customers who want their own domain are, almost by definition, customers who take the product seriously and are willing to pay for it.
• It reduces churn. Once a customer has published links, set up email, and pointed their marketing at app.acme.com, moving off your platform means changing their domain again. The switching cost quietly grows in your favor.
• It looks professional for the customer. A domain in the address bar that matches the company sending the link builds trust with their audience. That trust reflects well on you.
• It helps their SEO and yours. Content served on the customer's own domain accrues authority to that domain, which is what they want. You are not competing with your own customers for search traffic.

The catch is that the feature request sounds small and the implementation is not. That gap is where most teams get stuck.

Why are custom domains hard to build?

The demo version is easy. You add a hostname to your reverse proxy, point a test domain at it, request a certificate, and it works. Then you try to make it real for every customer and the edges start showing up.

Here is what you are actually signing up to handle.

• Ownership verification. You cannot issue a certificate for app.acme.com unless you can prove Acme controls it. Get this wrong and you have opened a door for one customer to hijack another customer's domain.
• DNS across many providers. Every customer uses a different registrar and DNS host. The record types, the apex handling, and the automation APIs are all different. There is no single way to "just add a record."
• Apex versus subdomain rules. Pointing app.acme.com is a CNAME. Pointing acme.com itself is not, because the DNS standard does not allow a CNAME at the root of a domain. Handling both correctly means understanding a real limitation, not just copying a record.
• Certificate issuance and renewal. Certificates from Let's Encrypt via the ACME protocol are free, but they expire every 90 days. Multiply that by thousands of domains and you now run a renewal system that cannot fall behind, because a lapsed certificate is a customer-facing outage.
• Multi-tenant TLS at the edge. Your servers need to present the right certificate for whichever hostname a visitor typed, on the fly, at scale. That is a specific and unforgiving piece of infrastructure.
• Rate limits and failure modes. Certificate authorities have rate limits. DNS changes propagate slowly and unevenly. Customers typo their records. You need retries, backoff, clear status, and a way to tell a customer exactly what is wrong.

None of this is impossible. Plenty of teams have built it. The honest question is whether custom-domain plumbing is the thing you want your engineers spending their quarters on, or whether it is undifferentiated work that should just run. See how it works for the version where this is handled for you.

What is multi-tenant TLS?

When a browser opens a secure connection, the very first thing it does is name the hostname it wants, using a field called SNI. Your edge has to look at that hostname and immediately hand back a certificate that matches it. For your own domain that is trivial, you have one certificate. For custom domains you might have thousands of hostnames, each needing its own valid certificate, and you do not know in advance which one a given visitor will ask for.

There are two broad ways to solve this.

• On-demand issuance. When a new hostname first connects or is registered, you obtain a certificate for it right then and cache it. Tools like Caddy with on-demand TLS work this way. It scales well but you have to guard it carefully so nobody can trigger issuance for domains you should not be certifying.
• Batched certificates. You pack many hostnames into wildcard or SAN certificates. This reduces the number of certificates but adds its own bookkeeping, because certificates have limits on how many names they can hold and every change means reissuing.

Either way, the renewal treadmill never stops. Certificates expire, domains get added and removed, and the edge has to stay consistent through all of it. This is the single most common place where a homegrown custom-domain feature quietly breaks months after launch.

Apex domains vs CNAME: what's the difference?

This one trips up almost everyone, so it is worth being concrete.

A subdomain is anything with a label in front of the root, like app.acme.com or portal.acme.com. Subdomains can use a CNAME record, which is an alias that says "send this hostname wherever this other hostname goes." You give the customer a target, they create a CNAME pointing to it, and traffic flows to you. Clean and standard.

An apex domain (also called the root, the naked domain, or the zone apex) is the bare acme.com with nothing in front. The DNS standard does not allow a CNAME at the apex, because the apex already has to carry other records that a CNAME would conflict with. So you cannot simply alias acme.com to your platform the same way.

The workarounds each have tradeoffs:

• A or AAAA records at the apex. The customer points acme.com at a stable IP address you provide. Simple, but it ties you to specific addresses.
• Provider-specific apex flattening. Some DNS providers offer their own record type that behaves like a CNAME at the apex. It works, but only on providers that support it, which is why you cannot assume it.
• Redirect the apex to a subdomain. Send acme.com to www.acme.com or app.acme.com, then handle that subdomain with a normal CNAME.

The reason this matters for a SaaS is that your customers will want both. Some will map a subdomain, some will insist on the bare domain, and your feature has to guide each one to the correct record without making them read a DNS tutorial. Detecting the provider and writing the right record automatically is exactly the kind of thing a managed layer handles.

Should you build custom-domain support or buy it?

This is the real decision, so here is a plain comparison of what you own in each case.

The build path is a legitimate choice. If custom domains are the whole point of your company, you should own that stack deeply. For everyone else, the math usually comes out the same way: the feature is genuinely valuable to customers and genuinely undifferentiated for you to operate. Buying it turns a multi-quarter infrastructure project into an API call. You can see the full list of what the managed layer covers on the features page.

How does a managed custom-domain service work?

Here is the end-to-end flow, step by step, so you can see where each hard part goes.

• 1. The customer names their domain. Inside your app, the customer types the domain they want to use, like app.acme.com. This is usually a single field in a settings screen.
• 2. The service detects their DNS provider. It looks up where the domain's DNS is hosted and figures out how to configure it, across 25+ major DNS providers.
• 3. DNS records get written. For supported providers, it writes the records directly or drives a provider-hosted one-click consent so the customer just approves. For anything else, it gives exact copy-paste instructions.
• 4. Ownership is verified. The service confirms the customer actually controls the domain before anything is issued, which is what keeps one customer from claiming another's domain.
• 5. A certificate is issued. An HTTPS certificate is obtained via Let's Encrypt so the domain is secure from the first visit.
• 6. Traffic is routed. Visitors hitting app.acme.com pass through a reverse-proxy edge that presents the right certificate and forwards the request to your origin. Your app sees the traffic and responds as normal.
• 7. Renewal runs on its own. Certificates auto-renew before they expire, so nobody has to remember the 90-day clock.

From your customer's point of view it feels like one click. From your point of view, the verification, the per-provider DNS logic, the certificate lifecycle, the multi-tenant TLS, and the edge are all off your plate. Your app keeps doing what it does; the domain just arrives pointed at it.

How do you add custom domains with an API?

For engineers, the integration is built to stay out of your way. There are a few surfaces, and you pick the ones that fit your app.

• REST API. Create a domain against a customer or tenant, read its status, list domains, and remove them. Your backend never touches DNS or certificates directly; it just makes calls and reads state.
• Browser widget and SDK. Drop a prebuilt component into your settings page so customers can add and verify a domain without leaving your product. The widget handles the input, the instructions, and the live status. The SDK lets you wire it into your own UI if you prefer.
• Webhooks. Instead of polling, you get an event when a domain is verified, when a certificate is issued, or when something needs the customer's attention. Your app reacts to those events and updates its own records.

A typical integration is short. You add a domain field to your customer settings, call the API when they submit, render status from the widget or from webhook events, and flip the customer's domain to active once you get the verified event. There is no DNS code, no ACME client, and no certificate cron job in your codebase. The how it works page walks through the flow in more detail, and the blog has integration write-ups.

How do AI agents provision custom domains?

More products are being driven by AI agents now, not just human users in a browser. If a customer asks an agent to "put my store on shop.acme.com," the agent needs a way to actually do that. A hosted MCP server gives it one.

MCP is the standard that lets an AI agent discover and call tools. With a hosted MCP server for custom domains, an agent can:

• Register a domain for a specific customer or tenant.
• Read the DNS instructions and either apply them or hand them back to the user.
• Check verification and certificate status and wait until the domain is live.
• Confirm the domain is serving before reporting success.

The point is that provisioning a custom domain becomes something an agent can do end to end, programmatically, with the same guardrails as the API. For platforms building agent-driven experiences, that turns a multi-step human chore into a single instruction. Details are on the AI agents page.

What does a good custom-domain experience feel like?

It is worth naming what "good" looks like, because it is easy to ship a version that technically works but frustrates everyone.

• One field, one action. The customer should not have to understand DNS to succeed. They enter a domain and follow one clear instruction.
• Clear status the whole way. Pending, verifying, issuing, live. When something is wrong, the message says exactly which record is missing or misconfigured.
• Fast to live. Once the record is in place, verification and certificate issuance happen in minutes, not hours of mystery.
• Silent after that. Renewals happen on their own. The customer never hears about the certificate again, and neither do you.

That is the bar. A managed layer exists to hit it consistently, across every provider and every customer, without your team becoming DNS support.

Where custom domains are heading

The direction is steady and unglamorous, which is usually a good sign. Custom domains are moving from a premium extra that a few customers request to a baseline expectation for any product a business puts in front of its own audience. At the same time, the way the feature gets used is widening. It used to be a person in a settings screen; increasingly it is an API call inside another workflow, or an AI agent setting up a domain as one step in a longer task. The plumbing underneath, verification, DNS, certificates, edge routing, is not getting simpler, but the layer you build on top of it is getting further from that plumbing. The teams who win the next few years will treat custom domains as something their product simply has, not something their engineers maintain. Whether you build that layer or reach for a managed one, the goal is the same: your customers on their own domains, secure and live, with the hard parts handled and out of sight.