You want blog.yourcompany.com, or shop.yourcompany.com, or app.yourcompany.com. Setting up a subdomain is one of the most common DNS tasks, and one of the most commonly confused. Do you use an A record or a CNAME? Do you need to register anything? Why isn't it working after you added it?
The good news: creating a subdomain is straightforward once you understand what's actually happening. A subdomain is just a DNS record under your existing domain. You don't register it separately, you don't pay extra for it, and you can create as many as you want. The entire process is adding the right record in your DNS provider's dashboard.
This guide walks through what a subdomain is, the different ways to point one, step-by-step setup, and the common reasons subdomains don't work right away.
What Is a Subdomain?
A subdomain is a prefix added to your main domain, separated by a dot. If your domain is yourcompany.com, then blog.yourcompany.com, shop.yourcompany.com, and support.yourcompany.com are all subdomains.
Technically, www.yourcompany.com is also a subdomain. The www is just a conventional prefix. There's nothing special about it compared to any other subdomain you create.
Subdomains are part of the DNS hierarchy. Your domain yourcompany.com is delegated to your authoritative nameservers, and those nameservers can answer for any subdomain you configure. You have full control to create, modify, and delete subdomains through your DNS provider without involving your registrar or anyone else.
Subdomains vs Subdirectories
A quick clarification, because these are often confused:
- Subdomain:
blog.yourcompany.com(uses DNS, can point to entirely separate infrastructure) - Subdirectory:
yourcompany.com/blog(a path on the same server, handled by your web server, not DNS)
This guide is about subdomains, which are configured in DNS. Subdirectories are configured in your web server or application and don't involve DNS at all.
Two Ways to Point a Subdomain
There are two main record types you'll use to set up a subdomain, and choosing the right one matters.
Option 1: A Record (Point to an IP Address)
If your subdomain should point to a server with a known, stable IP address (your own server, a dedicated cloud instance, a VPS), use an A record:
app.yourcompany.com. 300 IN A 203.0.113.50
This points app.yourcompany.com directly to the IP 203.0.113.50. Use AAAA records for IPv6 addresses.
Option 2: CNAME Record (Point to Another Hostname)
If your subdomain should point to a third-party service that gives you a hostname rather than an IP (a website builder, a SaaS app, a CDN, a hosting platform), use a CNAME record:
shop.yourcompany.com. 3600 IN CNAME yourstore.myshopify.com.
This makes shop.yourcompany.com an alias for yourstore.myshopify.com. When the service changes its underlying IP addresses, your CNAME automatically follows because it points to their hostname, not a fixed IP.
For a deeper comparison of when to use each, see our guide on A records vs CNAMEs.
Step-by-Step: Creating a Subdomain
Step 1: Determine Where It Should Point
Decide what the subdomain connects to. Is it:
- Your own server with a static IP? Use an A record with that IP.
- A third-party service (Shopify, Ghost, Webflow, GitHub Pages, etc.)? Use a CNAME with the hostname they provide.
- An email or other service requiring specific records? Follow that service's DNS instructions.
Most third-party services tell you exactly what record to create in their custom domain or DNS setup documentation. Always check their instructions first, as they specify the exact target value.
Step 2: Log Into Your DNS Provider
Go to wherever your DNS is hosted. This is your authoritative DNS provider, which may be your registrar (GoDaddy, Namecheap) or a separate provider (Cloudflare, Route 53, etc.). This is where your existing records live, not necessarily where you bought the domain.
Step 3: Add the Record
Find the DNS management or DNS records section and add a new record:
For an A record:
- Type: A
- Name/Host: the subdomain prefix only (e.g.,
app, notapp.yourcompany.com). Most providers automatically append your domain. - Value/Points to: the IP address (e.g.,
203.0.113.50) - TTL: 300 seconds is a good default while setting up
For a CNAME record:
- Type: CNAME
- Name/Host: the subdomain prefix (e.g.,
shop) - Value/Points to: the target hostname (e.g.,
yourstore.myshopify.com), often with a trailing dot - TTL: 300-3600 seconds
Step 4: Save and Wait for Propagation
Save the record. It won't be instantly available everywhere. DNS propagation means resolvers need time to pick up the new record. With a low TTL on a brand-new record, this is usually fast (minutes), but it can occasionally take longer. We explain the timing in our DNS propagation guide.
Step 5: Verify the Subdomain Resolves
Use the DNS lookup tool at dnsassistant.com/tools to query your new subdomain. Confirm it returns the IP address (for an A record) or resolves through the CNAME to the right target. If the lookup returns the expected value, your subdomain is configured correctly.
Step 6: Configure the Destination
Pointing DNS is only half the job. The server or service the subdomain points to also needs to be configured to accept and respond for that subdomain. For your own server, this means setting up a virtual host or site configuration. For third-party services, this means adding the custom domain in their dashboard so they provision a TLS certificate and route requests correctly.
Common Reasons a Subdomain Isn't Working
Propagation Hasn't Completed
If you just created the record, give it a few minutes. Check the actual DNS resolution with the DNS lookup tool rather than just trying it in your browser, since your browser and operating system may cache results.
Negative Caching
If you tried to access the subdomain before you created the record, the NXDOMAIN (not found) response may have been cached. This negative cache persists for a period defined by your SOA record's minimum TTL. Wait for it to expire, or it may appear to "not work" even though the record now exists. This is why it's best to create records before they're needed.
Wrong Record Type
Trying to CNAME a subdomain to an IP address (CNAMEs point to hostnames, not IPs), or using an A record with a hostname (A records need IPs). Match the record type to the target.
The Destination Isn't Configured
DNS resolves correctly, but the server or service doesn't recognize the subdomain. You see a default page, a certificate error, or a "domain not configured" message from the service. The fix is on the destination side: add the custom domain in the service's dashboard, or configure the virtual host on your server.
Missing TLS Certificate
The subdomain resolves and the server responds, but you get a certificate warning because there's no TLS certificate covering the subdomain. Most services provision certificates automatically once you add the custom domain in their dashboard. For your own server, you'll need to obtain a certificate (e.g., via Let's Encrypt) that includes the subdomain.
Trying to Use a CNAME at the Apex
This applies to the root domain, not subdomains, but it's a common related confusion. You cannot CNAME the bare yourcompany.com (the zone apex). Subdomains like www or app can use CNAMEs freely; the apex cannot.
Wildcard Subdomains
If you want all possible subdomains to resolve to the same place, you can use a wildcard record:
*.yourcompany.com. 300 IN A 203.0.113.50
This makes any subdomain that doesn't have a specific record (anything.yourcompany.com) resolve to the specified IP. Wildcards are useful for certain applications (multi-tenant SaaS, dynamic subdomains), but they come with security considerations: they can mask configuration errors and make dangling DNS issues harder to detect. Use explicit records when you can, and wildcards only when you specifically need them.
Keeping Track of Your Subdomains
As organizations grow, subdomains accumulate. A staging environment here, a marketing campaign site there, a third-party integration somewhere else. Over time, it's easy to lose track of what exists and what each subdomain points to.
This matters for security. Forgotten subdomains pointing to decommissioned services become dangling DNS records vulnerable to subdomain takeover. Keeping an accurate inventory of your subdomains and what they point to is an important part of DNS hygiene.
DNS Assistant helps by monitoring your DNS records, alerting you when records change, and detecting dangling records that point to decommissioned cloud services across 22+ providers. This gives you visibility into your subdomains and catches the ones that become risks.
Get Started
After setting up a subdomain, verify it with the DNS lookup tool at dnsassistant.com/tools. For a full view of all your DNS records and configuration, run a Free Domain Risk Report.
For continuous monitoring of all your subdomains and DNS records with real-time alerting, sign up at dnsassistant.com.
Start Monitoring Your DNS Today
Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.
Sign Up Free