What Is a Subdomain? Uses, Setup, and Best Practices

The hostname decision comes before the service

When I bring up a new service during a night shift, I choose its hostname early. api.example.com and panel.example.com are not just readable labels; DNS, the web server, certificates, and access policies all meet there.

A subdomain is a name under a primary domain. If example.com is the main domain, then blog.example.com, panel.example.com, and api.example.com are subdomains.

Technically, a subdomain is a hostname below the primary domain in the DNS hierarchy. A separate DNS record can send it to another IP address, server, or service. You do not need to buy another domain. If you manage DNS for example.com, you can create vps.example.com there.

A subdomain is not a newly registered domain, but it can behave independently from the main domain in DNS, the web server, and the application. That distinction matters. A DNS record only says where traffic should go. Nginx, Apache, or the application on that server handles the request.

I use subdomains to keep services separate. In my Proxmox lab at home, monitoring, file sharing, and my password manager may run on the same machine, but giving each service its own hostname keeps certificate management and access rules much easier to follow.

Where a subdomain sits in the domain hierarchy

Take status.example.com and split it into parts. The rightmost com is the top-level domain. example is the registered domain, and status is the label below it. DNS also supports several levels:

dev.api.example.com

Here, api.example.com is a subdomain, while dev.api.example.com is another level below it. DNS has no problem with this structure. Longer hostnames do require more thought around certificate coverage, cookies, logging, and usability. Unless I have a clear reason, I avoid three- or four-level hostnames.

Several DNS record types can serve a subdomain:

• A record: Sends a hostname to an IPv4 address.
• AAAA record: Sends a hostname to an IPv6 address.
• CNAME record: Points one hostname to another hostname.
• MX record: Controls email delivery when a separate mail flow is needed for a subdomain.
• TXT record: Stores verification, SPF, DKIM, and ownership information required by various services.

If your VPS has the IPv4 address 203.0.113.20, you could create this record in your DNS panel:

Type: A
Name: app
Value: 203.0.113.20
TTL: 3600

This makes app.example.com resolve to that IPv4 address. Some providers expect only app in the Name field; others expect the complete hostname. Read the field description before pasting values. That small habit prevents surprisingly irritating DNS mistakes.

When a subdomain makes sense

A subdomain separates different functions while keeping them under one domain. Instead of buying a separate domain for every service, you create boundaries at the DNS and web-server layers.

Blogs, stores, and documentation

You might run the main homepage at example.com, the content section at blog.example.com, and a product catalog at store.example.com. If these parts use different applications or hosting accounts, a subdomain gives them a useful, readable boundary.

Moving every kind of content to a subdomain is not always the right choice. Search engines may treat blog.example.com as a site section separate from the main domain. If you want the content to grow as part of the same site structure, example.com/blog may be a better fit.

APIs and administration panels

A common layout is api.example.com for application endpoints, panel.example.com for the user dashboard, and status.example.com for a status page. In Nginx, you can define a separate server block for each service and keep rate limits and access rules independent.

Keep administration panels private where you can.

Development and staging environments

Names such as staging.example.com and dev.example.com are useful for environments separated from production. The word staging in a hostname does not make a system safe. I treat a test address as an internet-facing production service unless it has password protection, IP restrictions, or VPN-only access.

Connecting external services to your domain

A documentation provider, CDN, help desk, or status-page service may give you a CNAME target. If the provider gives you customer.example-service.net, create this record for docs.example.com:

Type: CNAME
Name: docs
Value: customer.example-service.net
TTL: 3600

Do not put an IP address in the value of a CNAME record. CNAMEs at the zone apex, meaning directly on example.com, are not supported by many providers or are handled through a provider-specific alternative. At the subdomain level, this is the usual use case.

A subdomain and a subdirectory are different things

example.com/blog is a subdirectory. blog.example.com is a subdomain. They may look similar in a browser, but they behave differently with DNS, cookies, TLS, and application deployment.

Choose based on architecture, not habit. If a separate team, server, and release cycle manage the blog application, a subdomain makes sense. For content categories inside one WordPress installation, a subdirectory usually needs less maintenance.

I once assumed that creating a subdomain automatically isolated an application. It does not. If the application still uses the same database, Redis instance, or broadly scoped session cookies, changing the hostname does not create a real boundary.

Creating a subdomain in DNS

Start by deciding what service the subdomain should reach. Use an A or AAAA record for a VPS, a CNAME for another hostname, and a TXT record for ownership or email-related verification. Do not choose the record type at random.

An A record for a VPS

To connect app.example.com to a VPS, the record might look like this:

app.example.com. 3600 IN A 203.0.113.20

After changing DNS, I check the result from the terminal:

dig +short app.example.com

If you see the expected IP address, the resolver you queried has the record. An empty response can mean a wrong record, a change that has not reached that cache yet, or a query going to a different DNS provider. When DNS gives me trouble, I run dig +short before refreshing a panel.

An external target with CNAME

With a CNAME, the output may look like this:

dig +short docs.example.com
customer.example-service.net.
198.51.100.40

The first line is the CNAME target, and the next line may be the target’s A record. DNS clients commonly follow the chain for you. Seeing only an IP address does not tell you whether the original record was an A record or a CNAME. To query the record type directly, use dig docs.example.com CNAME.

TTL and propagation

TTL determines how long a DNS response may remain in a cache. Lowering the TTL before a planned change can make a migration easier, but responses previously cached with a high TTL do not disappear immediately. The phrase “DNS has not propagated” often means that different resolvers are still serving an older cached response.

Do not shut down the old server because one resolver shows the new value. During migrations, I leave both systems available for a transition window and query several resolvers as well as the authoritative nameservers directly.

DNS is not enough: configure the web server

When a subdomain reaches an IP address, the connection does not automatically go to the application you intended. The web server selects a configuration based on the request’s Host header and, for HTTPS, the SNI information.

Here is a simple HTTP virtual host in Nginx:

server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;

    root /var/www/app/public;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

The server_name value must match the hostname in DNS. I do not reload Nginx until I have checked the active hostname; a change made on what I thought was staging but was actually production taught me that habit the hard way. Test the configuration first:

sudo nginx -t
sudo systemctl reload nginx

Run the second command only after the first reports output similar to syntax is ok and test is successful. A reload refreshes the configuration while preserving existing connections as far as possible. Nginx’s syntax test cannot catch every logical problem, such as an incorrect upstream or application path.

With Apache, the equivalent job is done through a VirtualHost definition. Correct DNS does not guarantee that the web server will serve the right site. If the default page appears, the problem is often the server_name, virtual-host matching, or configuration order rather than DNS.

HTTPS, certificates, and wildcard subdomains

Every subdomain must be covered by the HTTPS certificate being served. A certificate issued for example.com does not automatically cover app.example.com. The same applies to www.example.com; it must be included separately.

For one subdomain, you can request a Let’s Encrypt certificate with Certbot if the Nginx plugin is installed:

sudo certbot --nginx -d app.example.com

For several names:

sudo certbot --nginx -d example.com -d www.example.com -d app.example.com

Before allowing Certbot to modify the Nginx configuration, I keep a copy of the current file and test renewal:

sudo certbot renew --dry-run

I have covered DNS validation, Nginx configuration, and renewal checks in How to Install an SSL Certificate on a VPS with Let’s Encrypt.

When do you need a wildcard certificate?

A wildcard certificate for *.example.com covers subdomains at one level, such as app.example.com and panel.example.com. It does not cover the apex domain example.com; add that name separately if you need it. It also does not cover dev.api.example.com, because a wildcard matches only one label level.

Wildcard certificates generally use DNS-01 validation. A temporary TXT record is added to DNS during validation. If you do not want to store a DNS API key with broad permissions on the server, consider issuing the certificate in a separate process and distributing only the required certificate files.

Security details that are easy to miss

A subdomain is not a security boundary. It separates naming and routing, but application permissions, network rules, and authentication still need their own design.

• Keep administration panels behind a VPN, an allowlist, or an additional authentication layer where possible.
• Do not use real customer data in staging subdomains. If you must, mask it first.
• Open only the ports and upstreams each subdomain actually needs.
• After removing a DNS record, verify that the service is no longer reachable on the old server.
• Remove unused DNS records to reduce the risk of subdomain takeover.
• Manage application secrets through secure configuration and access policies, not merely according to the hostname.

Forgotten CNAME records deserve particular attention. If an external service account has been closed but its DNS record remains, somebody else may be able to register the same target and claim the hostname. The exact conditions differ between providers, but keeping unused records clean is a cheap precaution.

Cookie scope is another commonly missed detail. If an application sends a cookie with Domain=.example.com, that cookie can be sent to other subdomains below the domain. If the panel and the user-facing application have different trust levels, host-only cookies with no Domain attribute provide a narrower scope.

The SSH, firewall, and service-reduction checks in 10 Essential Steps to Secure and Harden Your Linux Server still apply regardless of your subdomain design. A different DNS name does not fix an exposed SSH service or a weak password.

Wildcard DNS for multi-tenant applications

Sometimes every customer or user needs a separate subdomain, such as company-a.example.com and company-b.example.com. Instead of creating an A record for every tenant, you can use wildcard DNS:

Type: A
Name: *
Value: 203.0.113.20
TTL: 300

This sends subdomains without a more specific DNS record to the same IP address. It does not override existing records. DNS routing does not select the tenant for you; Nginx or the application must inspect the incoming Host value and decide which customer to display.

With wildcard DNS, a mistyped hostname may also reach the application. The application should accept only known tenants and return a 404 or another safe default for unknown hostnames. Otherwise, one configuration mistake could make one customer’s content appear under another hostname.

Common subdomain problems

DNS resolves, but the site does not open

Start with dig +short and verify the IP address. If it is correct, check that the server is listening on ports 80 and 443, the firewall allows the traffic, the Nginx server_name is correct, and the application is running.

sudo ss -ltnp | grep -E ':80|:443'
curl -I http://app.example.com
curl -Ik https://app.example.com

curl -I requests headers only. The HTTP status code, redirects, and responding web server usually point you in the right direction. When I see a 502, I check the Nginx error log and the upstream socket before returning to the DNS panel.

The wrong site or default page appears

This usually means DNS is working but the web server did not find a matching virtual host. Check the spelling of server_name, the symbolic link for the active Nginx configuration, and the certificate blocks used for HTTPS.

The certificate appears invalid

The certificate may not contain the subdomain, or the client may still be following an old redirect or holding old certificate-chain information. You can inspect the certificate’s subject and SAN values with:

openssl s_client -connect app.example.com:443 -servername app.example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

The -servername option matters here. When several HTTPS sites share one IP address, SNI tells the server which hostname’s certificate you want.

The subdomain cannot receive email

A web subdomain and an email domain are not the same thing. Pointing mail.example.com at a web server does not create an MX setup for [email protected]. If you need email on a subdomain, configure MX, SPF, DKIM, and DMARC records separately according to your provider’s requirements.

My order for migrations and daily work

When I create a new subdomain, I follow this order:

1. Write down the hostname’s purpose and who will own it.
2. Verify the target IP, CNAME, or external service.
3. Create the DNS record and check the authoritative response with dig.
4. Add only the configuration belonging to this hostname on the web server.
5. Run nginx -t, then reload.
6. Issue the HTTPS certificate and test renewal.
7. Update the application’s canonical URL, callback URLs, CORS, and cookie settings.
8. Add HTTP status, TLS expiry, and, where possible, content checks to monitoring.

I still remember one night when I nearly skipped the hostname check. I was cleaning up an old test VPS and had typed an rm -rf command. When I pressed Tab to complete the target directory, the production hostname appeared in the shell prompt. I stopped before pressing Enter.

Since then, I check the output of hostname and the active terminal tab before dangerous operations. A small pause is cheap.

During a migration, leave a short transition window instead of deleting the old DNS record immediately. Application sessions, webhook callback URLs, OAuth return URLs, and third-party integrations may use more than the homepage. Changing a subdomain can affect much more than the page visible in a browser.

Choosing subdomains for SEO

The SEO decision cannot be reduced to “are subdomains or subdirectories better?” Consider the relationship with the main site, whether separate teams publish the content, the backlink structure, and your capacity to maintain the technical setup.

If a blog, help center, or language version is an inseparable part of the main brand, a subdirectory may provide a more unified structure. If you run a separate product, platform, or community, a subdomain can provide a cleaner boundary.

Whichever structure you choose, keep canonical tags, sitemaps, robots.txt, HTTPS, and internal links consistent. Creating subdomains only to place more keywords in hostnames increases maintenance without providing an automatic search advantage.

Check your analytics and Search Console setup as well. Whether you track traffic in one property or several depends on your reporting needs and cookie scope.

Questions to ask before creating a subdomain

Does this name represent a separate application or security policy? If it only points to a different directory on the same server, a subdirectory may be simpler. A separate team, deployment process, IP address, or access policy makes a subdomain more meaningful.

Think about its life cycle too. If old-staging.example.com remains forgotten for months, certificate renewals, DNS records, and attack surface all grow for no good reason. I now add a removal date to temporary records. A calendar note is cheaper than a DNS investigation months later.

Standardize names early. Names such as api, panel, status, and staging are clear to everyone. As the number of servers grows, names like app1-new-final may seem useful for a week, but they stop explaining anything after a few months.

If a VPS sits behind the subdomain, plan its resources separately from the hostname. Consider CPU, RAM, disk, and backup requirements using the basic distinctions in VPS Hosting Explained: What Is a VPS and What Is It Used For? A DNS record is one small line; the application behind it may involve an entire server operation.

When I’m testing a new subdomain and it unexpectedly returns NXDOMAIN, I use this guide on how to fix the DNS_PROBE_FINISHED_NXDOMAIN error to check propagation, nameservers, and local DNS settings.

Frequently asked questions

Do I need to buy another domain to create a subdomain?

No. If you can manage DNS for the primary domain, you can create the subdomain records you need. The hosting account, VPS, or external service behind the subdomain still needs its own configuration.

Does a subdomain need a separate SSL certificate?

If the subdomain is not included in the certificate being served, you need a separate certificate or a new multi-domain certificate. A *.example.com wildcard covers one-level subdomains, but the root domain must be included separately.

Should I use a subdomain or a subdirectory?

Use a subdomain when you need a different server, application, team, or access policy. For content that is part of the main site, a subdirectory is often simpler. Consider SEO, cookies, and maintenance together.

I added the DNS record. Why does the subdomain still not open?

Run dig +short sub.example.com and verify that it returns the correct IP address. If the IP is right, inspect the web server’s server_name, firewall, ports, application logs, and HTTPS certificate in that order.