How to Create Subdomains Using DNS Records

Subdomains are one of the most practical tools in a DNS administrator's kit. Whether you need staging.yourdomain.com for a test environment, api.yourdomain.com for a backend service, or mail.yourdomain.com as an MX pointer, you create all of them the same way: by adding the right DNS records in the right place. The process sounds simple, but there are enough small details — record types, TTL choices, CNAME restrictions, and propagation timing — that it trips up even experienced admins. This guide covers every step from choosing the right record type to confirming the subdomain is live globally.

What a Subdomain Actually Is at the DNS Level

A subdomain is nothing more than a label prepended to your root domain. blog.example.com is the label blog under the zone example.com. From DNS's perspective, it is just another resource record inside your zone file, no different in structure from the record that points your bare domain to an IP address. The DNS hierarchy does not require any special registration or fee — you own the zone, you add the record, done.

Three record types handle almost all subdomain use cases:

• A record — maps the subdomain directly to an IPv4 address.
• AAAA record — maps it to an IPv6 address.
• CNAME record — creates an alias that points the subdomain at another hostname, which is then resolved separately.

There is one hard rule to know before you start: you cannot place a CNAME at the zone apex (the bare domain itself, e.g., example.com). Subdomains, however, can freely use CNAMEs, and that is the most common way to point a subdomain at a cloud service, CDN, or load balancer endpoint.

Step 1 — Log In to Your DNS Provider

Your DNS records live wherever your domain's nameservers point. That is typically your domain registrar (Namecheap, GoDaddy, Google Domains, Cloudflare, etc.) or a separate hosting provider if you have delegated DNS management. To find out which nameservers are authoritative right now, run:

Whatever those NS records return — that is where you log in to add your new subdomain records. If the answer is ns1.cloudflare.com / ns2.cloudflare.com, head to the Cloudflare dashboard. If it is dns1.registrar-servers.com, log in at Namecheap. Getting this wrong is the number-one reason newly added records never appear.

Step 2 — Choose the Right Record Type

Before clicking anything, decide what the subdomain needs to resolve to:

• You have a fixed IP address (a VPS, dedicated server, or home server with a static IP) → use an A record.
• The target is a hostname (a load balancer FQDN like my-lb-1234.us-east-1.elb.amazonaws.com, a GitHub Pages address, a Heroku endpoint, or a Netlify URL) → use a CNAME record.
• You need IPv6 support → add an AAAA record alongside or instead of the A record.

Cloud services almost always give you a hostname to point at, not an IP, because their IP addresses rotate. Always use CNAME in those cases, or your subdomain will quietly break the next time the provider shifts IPs.

Step 3 — Add the DNS Record

Adding an A Record (Direct IP)

In your DNS provider's control panel, create a new record with these values:

• Type: A
• Name / Host: the subdomain label only — enter staging, not staging.example.com. Most panels automatically append the root domain.
• Value / Points to: the IPv4 address, e.g., 203.0.113.45
• TTL: 300 seconds (5 minutes) while testing; raise to 3600 once stable.

The equivalent zone file syntax looks like this:

Adding a CNAME Record (Hostname Alias)

Same process, different type:

• Type: CNAME
• Name / Host: blog (or whatever label you want)
• Value / Points to: the target FQDN — for example mysite.netlify.app or username.github.io. Most panels require a trailing dot in raw zone files; GUI panels handle this automatically.
• TTL: 300 initially.

One important restriction: do not add any other records (MX, TXT, A) on the exact same CNAME name. A CNAME must stand alone at that label. If you need both an MX and a web destination at the same subdomain, use an A record instead and point it at an IP, then configure the destination host separately.

Adding an AAAA Record (IPv6)

Identical to an A record but with the IPv6 address:

You can have both an A and an AAAA record on the same subdomain simultaneously — clients with IPv6 will prefer the AAAA, older clients fall back to A automatically.

Step 4 — Verify the Record Was Saved Correctly

After clicking Save, query the authoritative nameserver directly — do not rely on your local DNS cache, which may return old data or nothing at all during propagation. Find the authoritative NS for your domain and query it directly:

If the authoritative nameserver returns the correct value immediately after you save, the record is correct. Any delays you see elsewhere are pure propagation — the record is valid and spreading.

Step 5 — Understand Propagation Timing

DNS propagation is often misunderstood. Your record is not slowly traveling around the internet — it is immediately available on the authoritative nameserver. What takes time is the expiry of cached answers in recursive resolvers (Google's 8.8.8.8, your ISP's resolver, etc.). The cache lifetime is controlled by the TTL value you set on the record.

• TTL 300 (5 minutes) → resolvers will re-check within 5 minutes of the record being published. New subdomains have no prior cache, so they typically resolve within 1–5 minutes globally.
• TTL 3600 (1 hour) → if you are replacing an existing record, old resolvers can hold the previous answer for up to an hour.
• TTL 86400 (24 hours) → avoid this for any record you may ever need to change quickly.

For brand-new subdomains that have never been queried before, full global propagation is almost always complete within 10–15 minutes regardless of TTL, because there is no stale cache to wait out.

Common Mistakes and How to Avoid Them

Entering the Full FQDN in the Name Field

Most control panels auto-append the domain. If you type staging.example.com in the Name field, you often end up with staging.example.com.example.com. Always enter just the label: staging, blog, api.

Using a CNAME for the Root Domain

You cannot CNAME example.com itself. Some providers offer proprietary workarounds (Cloudflare calls it CNAME Flattening, Route 53 calls it ALIAS records). These are fine for the apex, but for subdomains, a regular CNAME always works.

Forgetting the SSL Certificate

Creating a DNS record makes the subdomain resolve. It does not automatically generate an SSL certificate. If you are serving HTTPS, you must provision a certificate that covers the new subdomain — either a wildcard cert (*.example.com) or a dedicated cert for that exact name. Services like Netlify and Vercel do this automatically after you set the CNAME; self-managed servers require a manual certificate request via Let's Encrypt or your CA of choice.

Conflicting Records

If a subdomain already has an A record and you try to add a CNAME at the same name, most providers will reject it or silently ignore one of them. Always delete conflicting records first. Use the DNS Lookup tool to check what records currently exist on a hostname before adding new ones.

Wildcard Subdomains

If you want every possible subdomain to resolve to the same destination — useful for multi-tenant SaaS apps or catch-all staging environments — use a wildcard record. The name field is simply an asterisk:

A wildcard matches any single label: anything.example.com will resolve, but deep.anything.example.com will not unless you add a second wildcard. Explicit records always take precedence over wildcards — www.example.com with its own A record will not be overridden by *.example.com.

Delegating a Subdomain to Different Nameservers

There is a more advanced use case: delegating an entire subdomain zone to a different set of nameservers. This is common in large organizations where a team manages dev.example.com independently. You do this with NS records on the subdomain label:

Once you add these NS records, your authoritative server will hand off all queries for *.dev.example.com to the specified nameservers. The dev team then manages their own zone file independently. This is called a subdomain delegation and is completely transparent to end users.

How to Verify the Subdomain Is Working End to End

Once propagation is expected to be complete, run a full verification:

The +trace flag is especially useful for debugging — it shows every step from the root nameservers down to the authoritative answer, making it immediately obvious if a delegation or record is missing at any level.

Keeping Subdomains Organized

DNS zones have no folder structure, so a domain with dozens of subdomains can become hard to audit. A few practical habits:

• Use consistent naming conventions: staging-, dev-, v2- as prefixes make it easy to identify purpose at a glance.
• Set low TTLs (300–600) on any subdomain that might change, such as staging or canary environments.
• Remove subdomains when decommissioning services. Dangling DNS records that point to no longer controlled infrastructure are a real security risk — attackers can register the old endpoint and hijack the subdomain.
• Document what each subdomain points to and why. A simple spreadsheet or a comment field in your DNS provider's interface saves significant time during incidents.

Quick Reference by Provider

Every major DNS provider uses slightly different terminology but the same underlying concepts:

• Cloudflare: Dashboard → your domain → DNS → Add record. Toggle the orange cloud off (DNS only) if you are testing and do not want Cloudflare proxying the subdomain yet.
• Namecheap: Domain List → Manage → Advanced DNS → Add New Record.
• GoDaddy: My Products → DNS → Add.
• Route 53 (AWS): Hosted Zones → your zone → Create Record. Choose Simple routing for straightforward A or CNAME records.
• cPanel (shared hosting): Zone Editor → your domain → Add Record. Alternatively, Subdomains in cPanel creates the record and a document root simultaneously.

Summary

Creating a subdomain is a four-step process: log in to the DNS provider hosting your authoritative nameservers, add either an A record (for an IP address) or a CNAME record (for a hostname), save it with a low TTL while testing, and then verify directly against the authoritative nameserver using dig or nslookup. The record is live the moment the authoritative nameserver accepts it — everything after that is just waiting for caches elsewhere to refresh. Get the record type right, avoid the full FQDN in the name field, and remember to provision SSL if the subdomain will serve HTTPS traffic, and the process is straightforward every time.