DNS allows up to 127 levels of nesting, so api.staging.eu.example.com is entirely legal and will resolve fine. The thing that stops people is never DNS — it is that a wildcard TLS certificate covers exactly one level, so every additional level of nesting needs its own certificate.
That single constraint shapes almost every real decision about subdomain structure. Understanding it, plus how cookies scope across nesting levels, is enough to design a domain layout you will not have to unpick later.
Table of contents
- The actual DNS limits
- The wildcard certificate rule
- How cookies scope across levels
- Subdomains against paths
- A structure that stays manageable
- Getting it wrong is expensive to undo
- How this fits the rest of the stack
- FAQ
The actual DNS limits
The rules, which are more generous than people assume:
- 253 characters total for a fully qualified domain name.
- 63 characters maximum per label — a label being one dot-separated segment.
- 127 levels of nesting, which follows from the character limits rather than being a separate rule.
So a.b.c.d.e.f.example.com is valid DNS. Every resolver on the internet will handle it. There is no technical DNS reason to avoid deep nesting, which is why explanations that stop at DNS miss the point entirely.
The limits that bite are all above DNS: certificates, cookies, and the humans who have to remember which environment lives where.
The wildcard certificate rule
This is the constraint that governs everything. A wildcard certificate for *.example.com covers exactly one level of subdomain:
api.example.com— covered.staging.example.com— covered.api.staging.example.com— not covered. This needs a separate wildcard for *.staging.example.com.
The asterisk matches one label, not any number of labels. This is defined behaviour, not a limitation of a particular certificate authority, and there is no wildcard syntax that matches multiple levels.
So every level of nesting you add multiplies your certificate management. A three-level structure with four second-level environments needs five certificates: one for *.example.com and one for each of *.dev.example.com, *.staging.example.com, and so on.
This is much less painful than it used to be. Automated certificate issuance handles per-hostname certificates without wildcards at all, and if certificates are issued and renewed automatically, the wildcard rule stops being a constraint on your architecture and becomes an implementation detail. The pain is real only when you are issuing and renewing by hand.
How cookies scope across levels
The second constraint, and the one that causes security problems rather than inconvenience.
A cookie set with Domain=example.com is sent to example.com and every subdomain beneath it, at every depth. A cookie set without a Domain attribute goes only to the exact host that set it.
The implications:
- A session cookie scoped to the parent domain is readable by every subdomain, including any you do not control. If you let customers have subdomains, a parent-scoped session cookie is a serious vulnerability.
- A subdomain cannot set a cookie for a sibling. staging.example.com cannot set a cookie that api.example.com will receive, except by scoping it to the shared parent.
- There is no way to scope a cookie to some subdomains and not others. It is one host, or the whole tree beneath a domain.
The practical rule: scope cookies as narrowly as the application allows. Set Domain only when you genuinely need sharing across subdomains, and never on a domain whose subdomains are not all yours.
There is a related detail worth knowing: the Public Suffix List determines where the browser stops allowing cookies to be set. You cannot set a cookie for .com, and you cannot set one for .co.uk, because both are on that list. Some hosting providers add their own domains to it precisely so that customer sites on shared subdomains cannot set cookies for each other.
Subdomains against paths
The prior question is often whether to use a subdomain at all. app.example.com and example.com/app are different architectural choices, not stylistic ones.
Subdomains give you a separate origin, which means separate cookie scope by default, separate CORS boundaries, and the ability to point the hostname at completely different infrastructure with a DNS change. They cost you a certificate entry and a CORS configuration when the parts do need to talk.
Paths keep one origin, so cookies and storage are shared automatically and there is no CORS to configure. They require whatever sits at the root to route the path to the right backend, which means a routing layer that knows about both.
A useful heuristic: use a subdomain when the thing behind it is operationally separate — different deploy cadence, different team, different infrastructure. Use a path when it is one application with a section. A marketing site and an application are usually subdomains. A settings page is a path.
There is an SEO dimension too, though it matters less than it used to. Search engines treat subdomains as somewhat separate properties, so content you want consolidated under one authority is generally better on a path. Documentation and blogs sit on the boundary and reasonable people put them either way.
A structure that stays manageable
Most teams end up somewhere near this shape, and it works because it stops at two levels:
example.com— the marketing site.app.example.com— the application.api.example.com— the API.docs.example.com— documentation.
One wildcard covers all of it. Cookies scope cleanly because each host sets its own. Nobody has to remember an ordering convention.
For environments, the fork in the road is whether staging becomes a third level. api.staging.example.com is tidy and needs its own wildcard. staging-api.example.com stays flat, stays inside the existing wildcard, and looks slightly worse.
For a small team the flat version is usually the better trade. For a larger organisation the third level is worth the extra certificate because it makes the environment boundary structural — you can point *.staging.example.com at entirely separate infrastructure with one DNS change, which is much harder when the environment is a hyphenated prefix.
Getting it wrong is expensive to undo
The reason to think about this before you need to is that domain structure is one of the harder things to change once it is live. Every changed hostname needs a redirect, and redirects need to stay in place effectively forever because links persist.
Two decisions worth making deliberately at the start:
- Whether www is canonical. Either is fine; being inconsistent is not. Pick one, redirect the other, and be aware a cookie set on the bare domain reaches www and every other subdomain.
- Whether user content gets subdomains. customer.example.com is a significant commitment — it constrains cookie scope forever and puts untrusted content inside your domain tree.
The second is the one that is genuinely hard to reverse. Once customers have subdomains under your domain, you can never safely scope a cookie to the parent domain again.
How this fits the rest of the stack
Domain structure is one of those decisions that is cheap on day one and expensive on day four hundred, because every hostname you publish becomes something you have to keep answering. The parts that make it manageable are automated certificates and redirects you declare rather than maintain. Custom domains and certificates on RunxBuild covers attaching hostnames and issuing certificates, and redirects are declared rules rather than application code, which matters when a structure change means a redirect that has to outlive the decision. When you are sizing what those sites and their APIs cost together, the RunxBuild hosting calculator breaks it into line items.
Useful related references:
- Matrix Multiplication in Python: Use NumPy and the @ Operator, Not Nested Loops
- Authorized Domains: The Production Checklist Most Apps Forget
- Custom domains and certificates on RunxBuild
FAQ
How many levels of subdomain are allowed?
DNS permits up to 127 levels, with a 253-character total limit and 63 characters per label. In practice the limit is never DNS — it is wildcard certificate coverage and human comprehension.
Does a wildcard SSL certificate cover nested subdomains?
No. A certificate for *.example.com covers api.example.com but not api.staging.example.com. The asterisk matches exactly one label, so each nesting level needs its own wildcard certificate.
Can a subdomain read cookies from the parent domain?
Yes, if the cookie was set with a Domain attribute naming the parent. That cookie reaches every subdomain at every depth. Cookies set without a Domain attribute go only to the exact host that set them.
Should I use a subdomain or a path?
Subdomains for things that are operationally separate — different deploys, teams, or infrastructure. Paths for sections of one application, since they share an origin and avoid CORS configuration entirely.
Are subdomains bad for SEO?
Search engines treat subdomains as somewhat separate properties, so content you want consolidated under one authority generally does better on a path. The effect is smaller than it once was and rarely decisive on its own.