To use SaaS Custom Domains effectively, you need to know about three different domain types we support — root domains, subdomains, and wildcard domains.

Let's learn what they are, how they are useful, and the differences between them.

A root domain, also known as the apex or naked domain, is the core URL of your website without any subdomains or prefixes. It's what users type into their browsers to access your site directly. For instance, saascustomdomains.com is an apex domain, free from any www or other subdomain prefixes.

Website-builder platforms are the perfect fit for using custom root domains.

These platforms come in lots of different flavours. Some focus on building general websites — WordPress, Wix, and Squarespace fall into this category. Others focus on building E-commerce shops — think Shopify or BigCommerce. And many others specialize in niches like marketplaces, blogs, or job boards, e.g. Job Boardly.

What's cool about website-builder platforms is that they let anyone, and their grandma, build their websites.

Instead of having your grandma's marmalade shop at something generic like granny-jelly.webbuilder.com, it would be much cooler if you put your grandma's E-commerce shop at granny-jelly.com.

This might seem like a small detail, but it's a crucial one. It gives your grandma's shop a professional edge and makes it easier for people to remember and find her marmalades online. Also, web search engines like Google or Bing will rank your grandma's website much higher.

If you are running a web-builder platform, supporting custom root domains is an absolute must.

A subdomain is a part of a larger domain. It's a way to organize and navigate the hierarchy of a website, and it typically reflects specific content or functions of the site.

For example, in the domain blog.example.com, blog is the subdomain of the root domain example.com.

Subdomains can be used to separate different areas of a website, such as a blog, shop, or support section. They are helpful in organizing content and can be managed separately, allowing for different hosting, security settings, or even branding.
​

Plenty of different SaaS businesses use custom subdomains. Here are just some of the potential use cases:

Applications like Intercom Articles that allow businesses to create dedicated help centres are a perfect use case for custom subdomains. A company might use a custom subdomain like help.example.com for its help centre. This makes the help centre easy to find and remember but also keeps it distinct from the main site while maintaining brand consistency.

Visit help.saascustomdomains.com to see a custom subdomain in action.

Businesses that want to separate their main website from their blog can use custom subdomains, such as blog.companyname.com. This approach allows for a clear distinction between the company's primary offerings and its editorial content, improving navigation and user experience.

SaaS platforms that serve multiple clients (tenants) often use custom subdomains for each client's dashboard or login portal, such as clientname.saasplatform.com.

This allows the SaaS platform to move traffic for certain customers to a specific datacentre, e.g. by using subdomains you can direct EU customers' traffic to EU datacentres.

Development teams often use subdomains to host staging or testing versions of their websites, such as dev.companyname.com or staging.companyname.com. This allows for thorough testing without impacting the live site.

E-commerce businesses that manage multiple product lines or geographically distinct stores can use custom subdomains to separate these sections clearly. For example, us.storename.com and uk.storename.com could be used to tailor the shopping experience to different regions.

For temporary events, marketing campaigns, or product launches, custom subdomains offer a way to create dedicated spaces without having to set up entirely new domains. Something like event.companyname.com can be a great way to focus user attention on the event while keeping it connected to the main brand.

Universities, colleges, and online educational platforms might use custom subdomains for different departments or courses, such as engineering.universityname.com or course.platformname.com. This helps in organizing content and making it more accessible to students.

For larger organizations, internal portals for employees, HR resources, or department-specific sites can be hosted on custom subdomains like hr.companyname.com or sales.companyname.com. This keeps internal and external content separate and makes navigation easier for employees.

In each of these cases, custom subdomains let you expand and organize a business or project's online presence, enabling better navigation, branding, and user experience without additional root domains.

Wildcard domains are like the Swiss Army knife in the domain world. Maybe it's not the best analogy because, unlike the Swiss Army knife, wildcard domains are truly useful in the real world.

By using an asterisk * as part of the domain name, like *.example.com, wildcard domains catch all requests for subdomains that haven't been explicitly defined within example.com. This feature opens up a myriad of possibilities for businesses and developers.

As you may imagine, wildcard domains are useful in similar situations where custom subdomains are useful. There's an overlap and you'll have to decide which one is the right choice for you.

Here are a few use cases you cannot handle with custom subdomains and where wildcard domains shine:

Sometimes, users could mistype a subdomain or try to access a non-existent subdomain, and you still want to direct them to a relevant place, like your main site or a custom error page. Wildcard domains make this possible by catching all these requests and allowing you to handle them gracefully, improving the overall user experience and potentially capturing leads that might have otherwise been lost.

With wildcard domains, you can also request a wildcard certificate. That single certificate will cover all the possible subdomains.

Why would you use a wildcard certificate? There are a few reasons, but mostly it's about speed, ease of use, and compliance.

Every time you create a certificate, it may take anywhere between a few seconds to even a few hours for the certificate to be issued. This is due to DNS changes sometimes being slow to propagate. Because of that, verifying domain ownership to issue a certificate becomes slow too. By issuing a wildcard certificate, you only issue a certificate once at the beginning and all the subdomains are ready to go instantly.

Instead of creating thousands of CNAME records that point subdomains like alice.yourcompany.com to SaaS Custom Domains servers, you can create a wildcard CNAME to direct the traffic for all subdomains at once, e.g. *.yourcompany.com CNAME in.saascustomdomains.com

Also, instead of handling thousands of certificates for thousands of different subdomains, you will only have a single certificate to think about.

Certain businesses are not allowed, or simply do not want to, create a new certificate for every user. Their only option is to use a wildcard custom domain with a wildcard certificate.

Alright, let's land this domain plane.

Think of root domains as online headquarters, the main spot where the digital world kicks off. Subdomains? They are specialized zones — from the blog library to the shop corner, each with its own vibe but still part of the bigger picture. Wildcard domains are the fishing nets, catching any stray digital tunas and sending them straight to your fish market.

​Until next time, keep building!

Need more help? Reach out via the Intercom chat widget and we'll be right with you!