Updated 2 hours ago
A subdomain is just a DNS record. That's it.
When someone types blog.example.com into their browser, DNS looks it up exactly like it would look up example.com. There's no special subdomain system, no hierarchy magic—just another name that points to an address. The dot before your domain is convention, not mechanism.
This simplicity is liberating. Once you understand that subdomains are just DNS records you control, you can use them to organize your entire web presence: api.example.com for your backend, staging.example.com for testing, docs.example.com for documentation. Each one independent, each one pointing wherever you need it to go.
Creating a Subdomain
You create a subdomain by adding a DNS record. Two types matter:
A Record — Points your subdomain directly to an IP address.
Use A records when you know the IP address of your server. The subdomain resolves directly to that address, no intermediaries.
CNAME Record — Points your subdomain to another domain name.
Use CNAME records when pointing to a service that manages its own IP addresses. Your hosting provider, CDN, or cloud load balancer will give you a domain to point to. When their IP addresses change, you don't have to update anything.
The practical difference: A records are direct but brittle (IP changes require DNS updates). CNAME records are indirect but flexible (the target handles IP resolution).
Common Subdomain Patterns
www. — The original subdomain. Still used, though many sites now redirect it to the bare domain.
app. — The actual application, separate from marketing pages on the root domain.
api. — Programmatic access. Developers know exactly where to send requests.
staging. and dev. — Test environments that mirror production without affecting real users.
blog. — Content management, often running different software than the main site.
docs. — Documentation, frequently hosted on platforms like ReadTheDocs or GitBook.
cdn. — Static assets served from a content delivery network.
Each subdomain can point to a different server, a different service, or even a different company's infrastructure. They're all just DNS records under your control.
Routing Multiple Subdomains to One Server
If all your subdomains point to the same server (via A records to the same IP), your web server decides what to show based on the Host header in each request.
When a browser requests blog.example.com, it sends:
Your web server (Nginx, Apache, Caddy) reads this header and routes to the appropriate application. One server, many subdomains, each serving different content. This is called virtual hosting, and it's how a single $5/month server can handle dozens of subdomains.
Wildcard Subdomains
A wildcard DNS record uses an asterisk to match any subdomain that doesn't have an explicit record:
Now anything.example.com resolves to your server. user123.example.com. my-feature-branch.example.com. Infinite possibilities from one record.
This enables powerful patterns:
- Multi-tenant SaaS: Each customer gets
customer-name.yourapp.com - User profiles:
username.example.comfor personalized pages - Dynamic environments: Spin up
feature-xyz.example.comfor every pull request
But wildcards come with a cost. You've claimed infinite territory, which means infinite responsibility. Every possible subdomain now resolves to your server—including subdomains that don't exist, subdomains that look like phishing attempts, and subdomains designed to exploit vulnerabilities. Your application becomes the gatekeeper. If you're not ready to handle arbitrary subdomain requests safely, don't use wildcards.
SSL Certificates for Subdomains
Every subdomain needs HTTPS. You have three options:
Individual certificates — One certificate per subdomain. Simple but tedious as you add subdomains.
Wildcard certificates — A certificate for *.example.com covers all first-level subdomains: blog.example.com, api.example.com, anything. It doesn't cover the root domain (example.com) or nested subdomains (staging.api.example.com—that's two levels deep). Most wildcard certificates include both *.example.com and example.com to solve the root domain gap.
Let's Encrypt — Free certificates, including wildcards. Modern hosting platforms handle this automatically. If you're managing your own server, tools like Certbot will obtain and renew certificates for you.
The practical choice for most setups: Let's Encrypt with automatic renewal. Unless you have specific compliance requirements, there's no reason to pay for certificates anymore.
Verification
After creating DNS records, verify they work:
Or:
DNS changes typically propagate within minutes. The "24-48 hours" figure you'll sometimes see is a worst-case scenario from an earlier era of DNS infrastructure. If your record isn't resolving after an hour, double-check the configuration at your DNS provider—the issue is almost certainly misconfiguration, not propagation delay.
Once DNS resolves, test the actual HTTPS connection in a browser. Certificate issues will show up as warnings or errors—don't ignore them.
The Mental Model
Subdomains seem complex because we encounter them in complex contexts: enterprise architectures, cloud deployments, multi-tenant applications. But the underlying mechanism is simple.
You own a domain. DNS lets you create records for any name under that domain. blog.example.com is a name. api.example.com is a name. literally-anything.example.com is a name. Each name points somewhere.
That's subdomains. The rest is just deciding where to point them.
Frequently Asked Questions About Subdomains
Was this page helpful?