How to Add a Subdomain to Your Domain
A subdomain is a prefix appended to a root domain that creates a distinct, independently addressable namespace under the same domain name. For example, given the root domain example.com, the hostname blog.example.com is a fully qualified subdomain where blog is the third-level label. Subdomains are resolved through DNS records β typically an A record pointing to an IPv4 address, an AAAA record for IPv6, or a CNAME record aliasing another hostname β and they require no additional domain registration fee.
From a practical standpoint, subdomains allow you to run separate web applications, staging environments, regional sites, or microservices under a single registered domain, with independent document roots, SSL certificates, and server configurations. This guide covers the complete technical process: DNS record creation, hosting configuration, SSL provisioning, propagation verification, and common failure modes that most tutorials omit.
What Is a Subdomain and How Does It Differ from a Subdirectory
Before touching DNS, it is worth understanding the architectural difference between a subdomain and a subdirectory, because the choice affects SEO, server configuration, and SSL scope.
| Feature | Subdomain (`blog.example.com`) | Subdirectory (`example.com/blog`) |
|---|---|---|
| DNS record required | Yes (A, AAAA, or CNAME) | No |
| Separate document root | Yes | Optional |
| Independent SSL certificate | Yes (or wildcard) | Shared with root domain |
| Treated as separate site by Google | Often, depending on content | No |
| Separate server / VPS possible | Yes | Requires reverse proxy |
| Session / cookie scope | Separate by default | Shared |
| Setup complexity | Moderate | Low |
| Ideal for | Apps, staging, regional sites | Blog sections, product pages |
Google's John Mueller has confirmed that Google generally treats subdomains as part of the same site when the content is clearly related, but the crawl budget, indexing, and link equity behavior can differ. For tightly integrated content such as a company blog, a subdirectory is often the lower-friction choice. For a separate application β a customer portal, an API gateway, or a staging environment β a subdomain is the correct architectural decision.
Common Use Cases for Subdomains
- Staging and QA environments:
staging.example.comordev.example.comβ isolated from production, often protected by HTTP Basic Auth or IP allowlisting. - API endpoints:
api.example.comβ allows independent deployment, rate limiting, and TLS termination. - Customer portals or SaaS dashboards:
app.example.comβ separate authentication context and session cookies. - Regional or language-specific sites:
de.example.com,us.example.comβ supportshreflangtargeting and geo-specific server routing. - Documentation and support:
docs.example.com,support.example.comβ often served from platforms like GitBook, Zendesk, or a self-hosted wiki. - CDN or media delivery:
cdn.example.com,static.example.comβ CNAME-pointed to a CDN edge network. - Mail infrastructure:
mail.example.comβ used as the hostname for SMTP/IMAP services, distinct from MX records.
Step 1: Access Your DNS Management Interface
DNS records for a domain are managed wherever the domain's authoritative nameservers are hosted. This is not always the same place as your web hosting. The authoritative nameserver is defined by the NS records at your domain registrar.
Determine where your DNS is managed:
dig NS example.com +shortIf the output shows nameservers belonging to your registrar (e.g., ns1.registrar.com), manage DNS at the registrar. If it shows nameservers belonging to a hosting provider or a service like Cloudflare, manage DNS there instead.
Once you have identified the correct control panel:
- Log in to the DNS management interface.
- Locate the DNS Zone Editor, DNS Management, or Zone File section.
- Select the domain for which you want to create the subdomain.
If your domain is registered through AlexHost Domain Registration, the DNS zone editor is accessible directly from your client area dashboard.
Step 2: Create the DNS Record for the Subdomain
You will create one of three record types depending on your infrastructure.
A Record β Pointing to an IPv4 Address
Use an A record when the subdomain resolves to a specific server IP address. This is the most common scenario for subdomains hosted on a VPS or Dedicated Server.
| Field | Value |
|---|---|
| Type | A |
| Name / Host | blog (not blog.example.com) |
| Value / Points to | 203.0.113.42 (your server's public IP) |
| TTL | 3600 (or 300 during initial setup for faster iteration) |
Critical detail: Enter only the subdomain label in the Name field β blog, not blog.example.com. Most DNS interfaces append the root domain automatically. Entering the full FQDN will create a record for blog.example.com.example.com.
AAAA Record β Pointing to an IPv6 Address
Identical structure to the A record, but the value is a full IPv6 address:
| Field | Value |
|---|---|
| Type | AAAA |
| Name / Host | blog |
| Value | 2001:db8::1 |
| TTL | 3600 |
CNAME Record β Aliasing Another Hostname
Use a CNAME record when the subdomain should resolve to another hostname rather than a direct IP. Common scenarios include pointing to a CDN, a third-party platform (Shopify, HubSpot, Netlify), or another internal hostname.
| Field | Value |
|---|---|
| Type | CNAME |
| Name / Host | shop |
| Value / Target | shops.myplatform.com. (note the trailing dot β it signals an FQDN) |
| TTL | 3600 |
Architectural constraint: A CNAME record cannot coexist with any other record type at the same label. You cannot create a CNAME for example.com itself (the zone apex) β only for subdomains. At the apex, use an A record or, if your DNS provider supports it, a proprietary ALIAS or ANAME record.
Wildcard Subdomain Record
A wildcard A record resolves any undefined subdomain to a single IP:
| Field | Value |
|---|---|
| Type | A |
| Name / Host | * |
| Value | 203.0.113.42 |
| TTL | 3600 |
This is useful for multi-tenant SaaS applications where each customer gets a subdomain (e.g., customer1.example.com). Be aware that a wildcard record does not automatically provision SSL for each subdomain β you need a wildcard SSL certificate or an ACME client that supports DNS-01 challenges.
Step 3: Configure the Web Server or Hosting Panel
Creating a DNS record makes the subdomain resolvable, but it does not automatically serve content. You must configure the web server or hosting panel to accept and route requests for the new hostname.
Configuring a Subdomain in cPanel
If your hosting uses cPanel β available on VPS with cPanel plans β the process is:
- Log in to cPanel.
- Navigate to Domains > Subdomains.
- In the Subdomain field, enter the label (e.g.,
blog). - Select the root domain from the dropdown.
- Set the Document Root β cPanel defaults to
public_html/blog, but you can specify any path. - Click Create.
cPanel automatically creates the DNS A record in WHM's BIND zone if the domain's DNS is managed locally. If DNS is managed externally (e.g., Cloudflare), you must add the record there manually as described in Step 2.
Configuring a Subdomain in Nginx
For a VPS running Nginx, create a new server block:
server {
listen 80;
listen [::]:80;
server_name blog.example.com;
root /var/www/blog;
index index.html index.php;
access_log /var/log/nginx/blog.access.log;
error_log /var/log/nginx/blog.error.log;
location / {
try_files $uri $uri/ =404;
}
}Save the file to /etc/nginx/sites-available/blog.example.com, then enable it:
sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginxConfiguring a Subdomain in Apache
Create a new virtual host file at /etc/apache2/sites-available/blog.example.com.conf:
<VirtualHost *:80>
ServerName blog.example.com
DocumentRoot /var/www/blog
<Directory /var/www/blog>
AllowOverride All
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/blog.error.log
CustomLog ${APACHE_LOG_DIR}/blog.access.log combined
</VirtualHost>Enable and reload:
sudo a2ensite blog.example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2Step 4: Provision an SSL Certificate for the Subdomain
Every subdomain that serves web traffic should be secured with TLS. A subdomain is a distinct hostname and is not covered by the root domain's single-domain certificate unless you use a wildcard certificate.
Option 1 β Let's Encrypt with Certbot (Single Subdomain)
sudo certbot --nginx -d blog.example.comOr for Apache:
sudo certbot --apache -d blog.example.comCertbot modifies the virtual host configuration automatically and sets up a cron job for renewal.
Option 2 β Let's Encrypt Wildcard Certificate (DNS-01 Challenge)
A wildcard certificate covers *.example.com, securing all current and future subdomains with a single certificate. This requires DNS-01 challenge verification:
sudo certbot certonly
--manual
--preferred-challenges dns
-d "*.example.com"
-d "example.com"Certbot will prompt you to create a TXT record (_acme-challenge.example.com) in your DNS zone. After adding the record and verifying propagation, Certbot issues the certificate. Wildcard certificates must be renewed every 90 days; automate renewal with a DNS plugin for your provider (e.g., certbot-dns-cloudflare).
Option 3 β Commercial SSL Certificate
For organizations requiring extended validation (EV) or a longer validity period, a commercial certificate from a trusted CA is appropriate. AlexHost offers SSL Certificates including domain-validated, organization-validated, and wildcard options. After purchase, install the certificate by placing the .crt and .key files on the server and referencing them in the virtual host configuration.
Step 5: Verify DNS Propagation
DNS changes do not take effect globally the instant you save them. Each resolver caches records for the duration of the TTL value. With a TTL of 3600, resolvers may serve the old record for up to one hour after you make a change.
Check propagation from multiple global vantage points:
# Check from a specific DNS resolver
dig A blog.example.com @8.8.8.8 +short
dig A blog.example.com @1.1.1.1 +short
# Check authoritative answer directly
dig A blog.example.com +traceFor a visual multi-region check, use whatsmydns.net or dnschecker.org. Full global propagation typically completes within 15 minutes to 2 hours for TTLs of 3600 or lower. The often-cited "up to 48 hours" applies primarily to TTL values of 86400 (24 hours) set on the previous record β a common default at many registrars.
Pro tip: Before making DNS changes, lower the TTL of the existing record to 300 (5 minutes) at least one TTL cycle in advance. This dramatically reduces propagation wait time during the actual change.
Step 6: Test End-to-End Functionality
After propagation, perform a complete functional test:
# Confirm DNS resolution
dig A blog.example.com +short
# Confirm HTTP response
curl -I http://blog.example.com
# Confirm HTTPS and certificate validity
curl -I https://blog.example.com
# Inspect the TLS certificate
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null
| openssl x509 -noout -subject -datesVerify that:
- The
curl -Iresponse returns200 OKor the expected redirect code. - The TLS certificate subject matches
blog.example.comor*.example.com. - The certificate expiry date is correct.
- No mixed-content warnings appear in the browser developer console.
Common Pitfalls and How to Avoid Them
CNAME at the zone apex: Attempting to create a CNAME record for example.com itself will break mail delivery and other DNS records. Use an A record or an ALIAS/ANAME record at the apex.
Subdomain not served by the web server: DNS resolves correctly, but the browser returns a 404 or connection refused. Cause: the web server has no virtual host matching the subdomain hostname. Solution: add the server block or virtual host as described in Step 3.
SSL certificate mismatch: The browser shows a certificate error. Cause: the existing certificate covers only example.com, not blog.example.com. Solution: issue a new certificate specifically for the subdomain or replace with a wildcard certificate.
cPanel creates a local DNS record but DNS is managed externally: When using Cloudflare or another external DNS provider with cPanel hosting, cPanel's subdomain wizard creates a record in WHM's local BIND zone, which is never consulted. You must add the A record manually in Cloudflare (or your external DNS provider). This is one of the most common sources of confusion for shared hosting users.
Wildcard DNS without wildcard SSL: A *.example.com DNS record resolves all subdomains to your server, but each new subdomain will trigger a certificate warning unless you have a wildcard SSL certificate installed. Do not rely on wildcard DNS alone for production subdomains.
Cookie scope leakage: If your application sets cookies on .example.com (note the leading dot), those cookies are sent to all subdomains. This can expose session tokens from a high-security subdomain to a less-secure one. Scope cookies explicitly to the intended hostname.
Subdomain Management on Different Hosting Environments
| Hosting Type | DNS Management | Web Server Config | SSL Provisioning |
|---|---|---|---|
| Shared Hosting | Registrar or cPanel DNS Zone | cPanel Subdomains wizard | AutoSSL / Let's Encrypt in cPanel |
| VPS (unmanaged) | Registrar or external DNS | Manual Nginx / Apache vhost | Certbot CLI |
| VPS with cPanel | WHM / cPanel DNS or external | cPanel Subdomains wizard | AutoSSL |
| Dedicated Server | Registrar or BIND/PowerDNS | Manual or control panel | Certbot or commercial CA |
| Cloud (AWS, GCP) | Route 53 / Cloud DNS | Load balancer / ingress rules | ACM / Let's Encrypt |
For high-traffic applications requiring full root access and custom server configurations, a Dedicated Server gives you complete control over DNS, web server software, and certificate management without the constraints of a shared environment.
Technical Decision Checklist
Before creating a subdomain, work through the following:
- Where are the authoritative nameservers? Run
dig NS example.com +shortto confirm before logging into any panel. - A record or CNAME? Use
A/AAAAfor a server IP. UseCNAMEfor a third-party platform hostname. Never useCNAMEat the zone apex. - Is the web server configured to accept the new hostname? A DNS record alone does not serve content.
- Does the subdomain need its own SSL certificate? Yes, unless a wildcard certificate is already installed.
- Is the TTL set low before the change? Lower it to
300at least one TTL cycle before making changes to minimize propagation delay. - Is cPanel managing DNS locally while an external provider is authoritative? If so, add the record in the external provider, not cPanel.
- Does the subdomain need to be blocked from search engine indexing? If it is a staging or internal environment, add
X-Robots-Tag: noindexat the server level or use HTTP Basic Auth. - Are cookie scopes defined correctly? Explicitly set the
Domainattribute on cookies to prevent unintended cross-subdomain sharing.
FAQ
Can I create a subdomain without access to the root domain's DNS?
No. A subdomain requires a DNS record (A, AAAA, or CNAME) in the zone of the root domain. Without write access to the authoritative DNS zone, you cannot create a publicly resolvable subdomain.
Does a subdomain affect the SEO of the root domain?
It depends on content relationship and internal linking. Google can associate a subdomain with the root domain, but link equity does not flow as freely as between subdirectory URLs. For content tightly integrated with the main site, a subdirectory is generally preferable from an SEO standpoint. For separate applications or staging environments, a subdomain is the correct choice and should be noindex-ed if not intended for public search.
How many subdomains can I create under one domain?
The DNS specification imposes no practical limit on the number of subdomains. Registrars and hosting panels may impose soft limits, but these are administrative, not technical. A single domain can have hundreds of subdomains.
What is the difference between a wildcard DNS record and a wildcard SSL certificate?
A wildcard DNS record (*.example.com) routes all undefined subdomains to a single IP address at the DNS layer. A wildcard SSL certificate (*.example.com) secures all first-level subdomains at the TLS layer. They are independent: you can have one without the other, but both are required to serve all subdomains over HTTPS without individual certificate provisioning.
Why does my subdomain resolve correctly in dig but return a browser error?
DNS resolution and HTTP serving are separate layers. If dig returns the correct IP but the browser shows an error, the web server on that IP is not configured to handle requests for that hostname (server_name in Nginx or ServerName in Apache). Add the appropriate virtual host block and reload the web server.
