Skip to Content

How to package custom domains in SaaS pricing plans

Include it in a tier, sell it as an add-on or set per-domain limits: how each model works, what a custom domain costs you to run, and how to explain it on a pricing page.
October 9, 2026 by
How to package custom domains in SaaS pricing plans
CustomDomain™, Weldon Makori

Sooner or later a customer asks to use their own domain, and someone on your team has to decide where that goes on the pricing page. There are three ordinary answers: put it inside a tier, sell it as an add-on, or sell a number of domains. You can combine them, but the mix matters less than two questions underneath it: what exactly is being counted, and what does each counted domain cost you to keep alive.

We make CustomDomain™, a product of EverJust Company in Minneapolis: a widget that SaaS platforms embed so customers can connect their own domains, with the DNS automation, certificate issuance and reverse proxy edge behind it. This post is on our blog and we sell the infrastructure being priced here, so read it with that in mind. We have tried to keep the advice useful whether or not you ever use us, and we have left out any numbers about other vendors because we have not verified them.

Three ways to package the feature

ModelHow it reads on the pricing pageWorks whenWatch for
Included in a tier"Custom domain" is a row in a comparison table, ticked from one plan upBranding is a reason customers upgradeA flat price for a feature whose cost grows with usage
Paid add-on"Add your own domain, priced per domain per month"Only some customers on any plan want itExtra billing logic and a second thing to cancel
Per-domain limitfor example "3 domains on Pro, 25 on Business"Customers run several brands or regionsDisputes over what counts as one domain

These are not exclusive. One shape that works is a tier that includes one domain, a higher tier that includes several, and an add-on for anyone who needs more than the tier allows. That is three mechanisms to build and explain, so add them one at a time.

Including it in a tier

Our own guide to custom domains for SaaS calls this one of the cleanest things to gate behind a paid plan, because customers who want their own domain tend to be the ones who take the product seriously. We still think that is right, with one caution: a tier that includes the feature has no natural brake. A customer who connects one domain and sends little traffic costs you little. One who sends a great deal costs you more, and the plan price does not move. Decide which tier first, then estimate what the heaviest plausible customer on it would cost you.

If you go further and let customers present a fully branded setup, that is a white label domain, a separate packaging question (on our pricing, white-label branding is an Enterprise feature by contract). The retention argument for putting plain custom domains in a tier is real too. Once a customer has published links and pointed their own marketing at their own hostname, moving away means changing that hostname again. We wrote about the retention side in when domain setup becomes a retention metric. It argues for including the feature where you most want customers to stay, not everywhere.

Selling it as an add-on

An add-on is honest when only a minority of customers on a plan will ever want the feature. You do not raise the price for everyone to cover it, and you can see directly how many customers value it. The cost is operational: a separate entitlement, a separate invoice line, and a separate thing a customer can cancel.

If you sell it per domain, say per domain per month, state the unit in the same sentence as the price. We have no data on which converts better, and we would distrust anyone who claims a general answer. Your own support tickets will tell you how many domains a typical paying customer wants.

Setting per-domain limits

A limit is only fair if customers can predict what counts toward it. Write down the unit before you publish the number.

Count hostnames, not "domains"

A customer who says "my domain" may mean acme.com, www.acme.com and app.acme.com as one thing. Your certificate and routing work treats them as three hostnames. Decide which view your limit uses. The CustomDomain™ pricing page (checked on 8 October 2026) counts each hostname once and gives the example that theirbrand.com and app.theirbrand.com are two connections. Counting hostnames is the version that matches your costs. Counting registrable domains is easier to explain but gives away the subdomains. Either works if the page says which. The difference between apex and subdomain setups is explained in our glossary entry on apex domains and CNAMEs.

Decide what happens at the limit

There are two sane behaviors. Block new domains and show an upgrade prompt, or allow them and bill for the overage. Whichever you pick, do not disable domains that are already live. A customer whose site goes dark over one hostname too many will blame you, and be right. The same page states the policy we follow: nothing already live is cut off over volume, and Starter is the only plan that is capped at its allowance.

Make retries free

Setups fail for ordinary reasons, like a typo in a record. If a failed attempt counts against the limit, customers stop trying and start emailing. Count the connection once, however many attempts it takes. Our pricing page says creating a connection is idempotent per application and domain, so a retry reuses the same one.

What actually drives the cost

Teams tend to price the feature from the build cost and forget the running cost. Three ongoing items matter, and each grows with domains rather than users.

Cost driverGrows withWhat it looks like in practice
CertificatesNumber of hostnamesIssuance, renewal and failure handling for every hostname, on a schedule that never stops
DNS supportNumber of new connectionsCustomers who stall on the DNS step and write in
Edge trafficRequests and bandwidth per domainIf you proxy, every visit to a customer's hostname passes through your servers

Certificates

Certificates from Let's Encrypt are free but expire every 90 days, so each hostname you add is a renewal job that cannot fall behind. A lapsed certificate is a visible outage for your customer. Certificate authorities also apply rate limits, which matters when many customers connect at once; see Let's Encrypt rate limits for custom domain platforms. The certificate fee is zero. The system that gets and renews it is the cost.

DNS support

This is the line most often left off the spreadsheet. We have published a figure of roughly half of paying customers stalling at the DNS step of a manual setup. It is our own figure, not an independent survey, so treat it as a prompt to measure yours. Each stalled customer becomes a ticket, and the tickets repeat; we described the pattern in kill your DNS support tickets. If your setup is manual, price the feature with a support allowance built in.

Edge traffic

If you proxy customer hostnames, their visitors' requests use your bandwidth and servers. We cannot give you a number for this one, because it depends on what your product serves: a status page and a video-heavy storefront cost very different amounts per domain. Measure it from your own logs for a month before you decide a flat price is safe.

Cost per domain from a published ladder

To show the arithmetic, here is a published ladder worked through. On the CustomDomain™ pricing page (checked on 8 October 2026), Startup is $149 a month for 600 domain connections a year. Over twelve months that is $1,788, or about $3 per included connection at full use. Growth is $649 a month for the same 600 plus overage in 1,000-domain blocks, with the reverse proxy edge and automatic HTTPS included. At full use that is about $13 per connection. The method is the point, not the totals: take what the infrastructure costs you per year, divide by the connections you expect, and compare that with what the customer pays for the plan that contains the feature.

If you are weighing a build against a service, the cost drivers above are what you take on in a build. We went through that decision in should you build or buy custom domains.

Explaining it on your pricing page

Customers scan a pricing page for the row and the number. A few habits make the row hard to misread.

Put the row in the comparison table with a number or a clear word in every cell. A blank cell reads as unknown, so write "Not included" or "1 domain".

Define the unit once, beside the table, in plain words: "Each hostname you connect counts once. acme.com and app.acme.com are two."

Say what the limit does when it is reached. "New domains are blocked until you upgrade; existing ones keep working" is a complete sentence and it will answer a support ticket before it is written.

Say whether setup is included. If a customer must hire someone to configure DNS, the real price is higher than the page shows.

Avoid promising that there is no limit. If you proxy traffic, there is one, even if you never enforce it, and an unqualified promise is the sentence customers quote back to you later. A high limit stated plainly is more credible.

Finally, keep the page consistent with what the product enforces. Our own rows come from the same plan catalog the API serves. If yours cannot, compare your entitlement code with the page once a quarter and fix whichever is wrong.

Frequently asked questions

Should custom domains be included in a plan or sold as an add-on?

Include it when branding is a reason customers move up a tier, and sell it as an add-on when only a minority on any plan will want it. One workable pattern is one domain on a mid tier, with extras sold separately. Check the support and traffic cost of the heaviest plausible customer on the plan before you decide.

What should count as one custom domain?

Pick a unit and state it on the pricing page. Counting hostnames matches how certificates and routing work, so acme.com and app.acme.com are two. Counting registrable domains is simpler to explain but includes every subdomain for free.

What does it cost to support a custom domain?

Three things recur: certificate issuance and renewal for each hostname, support for customers who stall on DNS setup, and the bandwidth and compute of proxying their traffic. The first two scale with domain count, the third with usage. We cannot give you a figure for the third because it depends on what your product serves.

What happens when a customer reaches their domain limit?

Either block new domains with an upgrade prompt or bill for the overage. Do not switch off domains that are already live. Say on the pricing page which behavior you chose.

How does CustomDomain™ price custom domains?

As flat tiers with included volume, each with a 14 day free trial on Starter, Startup and Growth. The current prices and volumes are on the pricing page; those are the only source we recommend for numbers.

White label email sending domains: SPF, DKIM and DMARC alignment
How to send mail from a customer's own domain: what alignment means, the SPF and DKIM rules that trip platforms up, and what the Google and Yahoo requirements say.