What is a subdomain: the DNS mechanics, explained properly
A subdomain is a domain name that sits one level below a parent domain, created by adding a label to the left of it, so that support.example.com is a subdomain of example.com. To the Domain Name System it is not a special kind of object. It is simply a longer name, resolved by the same rules as any other.
How does a subdomain work?
A domain name is a sequence of labels separated by dots, read right to left from the root. In claims.eu.example.com, the labels are com, example, eu and claims. Each step to the left is one level deeper in the hierarchy, and every level below the second is a subdomain of what sits to its right.
RFC 1035 sets the size limits: each label is at most 63 octets, and the complete name is capped at 255 octets including the length bytes. There is no protocol limit on nesting depth beyond what those two constraints imply, though anything past three or four levels tends to be a sign of a naming scheme that got away from someone.
Making one work requires a record in the parent zone. Three routes are common:
- An A or AAAA record pointing the subdomain straight at an IPv4 or IPv6 address.
- A CNAME record aliasing it to another name, which is how nearly every hosted third party service asks you to set things up. CNAME cannot coexist with other records at the same name, which is why it works at a subdomain but not at the apex of your domain.
- NS records delegating the subdomain to a different set of nameservers, handing authority for that branch to another party entirely. This is real delegation rather than a pointer, and it is how large organisations split DNS control between teams.
A wildcard record such as *.example.com answers for any label that has no more specific record. Useful for multi tenant products handing every customer their own name, and a liability if you ever wanted unknown names to fail loudly rather than resolve.
Try Venta Capture on your own process
Build one flow for your highest-volume case type. Free, no credit card.
Subdomains and TLS certificates
Each subdomain needs certificate coverage in its own right. A certificate for example.com does not cover app.example.com unless that name appears in the Subject Alternative Name list.
Two ways round it. A wildcard certificate for *.example.com covers every single label subdomain, but not two levels down: it will not cover a.b.example.com. Or you issue per name and automate renewal, which is what most platforms do now that certificate automation is routine. Ask any vendor offering a branded domain which of the two they run and who is responsible when renewal fails.
Subdomain versus subdirectory
A subdirectory is a path on an existing host: example.com/blog. A subdomain is a separate hostname: blog.example.com. Technically they behave very differently.
- Routing. A subdomain can point at completely separate infrastructure with one DNS change. A subdirectory has to be handled by whatever serves the parent host, usually through a proxy rule.
- Cookies. Cookies set on example.com are available to its subdomains if the Domain attribute allows it, but a subdirectory shares the origin outright. For same origin browser security, a subdomain is a different origin.
- Operational ownership. Subdomains let a separate team run a separate stack without touching the main site's deployment path. That is usually the real reason one gets created.
The SEO argument, which is not settled
This question has run for over a decade and deserves an honest answer rather than a confident one.
Google's public position is that it does not matter much. Search Advocate John Mueller has said repeatedly, including in Google Search Central videos, that Google Search is fine with either subdomains or subdirectories, and his practical advice is to pick the structure you can sustain and to use a subdomain when the content is genuinely a different thing.
Practitioners keep pushing back. Agencies including Backlinko have published correlational analyses of large search result sets arguing that subdirectories outperform subdomains on competitive terms. Those studies show association, not causation, and the confound is obvious: content moved to a subdomain is often also under separate ownership, updated less, and linked to less from the main site.
The defensible summary is that Google says it treats them the same, that a good deal of field observation disagrees, and that nobody has produced a controlled experiment settling it. If the content is core to your main site and you have no operational reason to split it, a subdirectory is the lower risk default.
Subdomain example: a branded link for customers
A dealer group runs its site on Webflow and its customer document upload on a hosted platform. Rather than sending customers to a vendor address, it creates capture.dealergroup.com with a CNAME pointing at the vendor, and the vendor issues a certificate for that name.
The customer sees the dealer group's domain, colours and logo. That familiarity is one of the practical arguments for pairing a subdomain with white label branding on any process that starts with an unexpected link, such as guided photo capture.
The mistakes worth knowing about
- Dangling DNS. A CNAME pointing at a service you stopped paying for can be claimed by whoever registers that name next, and they then serve content on your subdomain. Subdomain takeover is a well documented attack class. Remove the record when you remove the service.
- Cookie scope by accident. Setting Domain=example.com exposes that cookie to every subdomain, including ones you do not control.
- Certificate renewal nobody owns. The most common outage on a branded subdomain is an expired certificate, and the ownership question is rarely asked until it happens.
- Naming that outlives its purpose. new.example.com is a name someone regrets for years. Name for function, not for phase.
Try Venta Capture on your own process
Build one flow for your highest-volume case type. Free, no credit card.