Should a subdomain be an A record or a CNAME?

Either works — this is the one place the apex rule doesn't bite. Use an A (or AAAA) record when you're pointing the subdomain at an IP address you control, like your own server. Use a CNAME when a platform hands you a hostname to point at — `cname.vercel-dns.com`, `yourname.github.io`, a load balancer's DNS name — because that target's IP can change and the CNAME follows it automatically. The rule of thumb: got an IP, use A; got a hostname, use CNAME. And remember a CNAME must be alone — RFC 1034 forbids any other record (MX, TXT, a second A) on the same name as a CNAME.

Why does my subdomain resolve to something like blog.example.com.example.com?

Because your DNS host auto-appends the zone to whatever you type in the name field, and you typed the full name. In the host/name box you enter only the label — `blog` — not `blog.example.com`. Typing the whole thing makes the provider append `.example.com` again. If a lookup of your subdomain returns NXDOMAIN but you can see a record for a bizarre doubled name, this is why. Fix the record to hold just the label.

I created the record and the subdomain still doesn't work. What now?

Three usual suspects, in order. First, propagation: the record is live but resolvers are still serving the old (empty) answer until the previous TTL expires, and NXDOMAIN gets cached too. Second, you edited the record in a zone that isn't actually authoritative — your domain's nameservers point somewhere else, so nobody reads your change. Third, the subdomain is delegated: an NS record hands that name to different nameservers, and the A/CNAME has to live over there, not in this zone. Check which nameservers are authoritative before you keep editing records nobody sees.

How to Create a Subdomain (CNAME or A Record)

Problem

You want blog.example.com, or app., or staging. — a subdomain — and the platform you’re connecting told you to “add a DNS record.” So you opened your DNS panel, and now you’re staring at a form with a Type dropdown, a Name box, and a Value box, none of which explain themselves. Add the wrong type, or type the wrong thing in the name box, and the subdomain either does nothing or resolves to a name so mangled it’s almost funny.

Here’s the good news: a subdomain is not a special kind of object you create somewhere. There’s no “make a subdomain” button, and you don’t register anything. A subdomain is just a DNS record whose name has a label in front of your domain. Once you see it that way, the whole thing is two decisions — which record type, and what to put in the name box — and both have simple answers.

What a subdomain actually is

DNS is a tree. example.com is a name in that tree, and blog.example.com is a name one level below it. When you “create a subdomain,” all you’re doing is publishing a record at that lower name inside the same zone you already control. The nameservers that answer for example.com answer for everything under it too, unless you explicitly hand a piece off (more on that at the end).

That’s the whole model. www is a subdomain. mail is a subdomain. The _dmarc and selector._domainkey names your email setup uses are subdomains. They’re all just records with a label prefix, and you add them the same way.

The two decisions

1. Which record type: A or CNAME

For a subdomain — unlike the apex/root of your domain — you can use either, and the choice is about what you’re pointing at.

You have an IP address (your own server, a VPS, a static IP): use an A record for IPv4, an AAAA record for IPv6. The value is the raw address, e.g. 203.0.113.10.
A platform gave you a hostname to point at (cname.vercel-dns.com, yourname.github.io, d1a2b3.cloudfront.net, a load balancer’s DNS name): use a CNAME record. The value is that hostname. The reason to prefer a CNAME here is that the platform’s underlying IPs change without warning, and a CNAME re-resolves every time, so it follows them. Hard-code their IP in an A record and the day they renumber, your subdomain breaks and you won’t know why.

The one hard rule: a CNAME cannot share a name with any other record. RFC 1034 §3.6.2 says a name with a CNAME has no other data — so you can’t put a CNAME and an MX (or a TXT, or a second A) on the same subdomain. If you need mail and a CNAME on the same label, you can’t; use an A record instead. This trips people who try to add a verification TXT onto a subdomain that’s already a CNAME.

The apex confusion, for the record: you can’t CNAME the root example.com, because the apex already carries mandatory SOA and NS records and a CNAME would collide with them. That restriction is real, but it’s an apex problem. On a subdomain, a CNAME is completely normal.

2. What goes in the name box: the label, and only the label

Every DNS panel has a Name (or Host) field, and almost all of them automatically append your domain to whatever you type. So for blog.example.com you type just:

blog

Not blog.example.com. If you type the full name, the provider appends the zone and you get a record for blog.example.com.example.com, which resolves for nobody. This is the single most common subdomain mistake, and it’s invisible until you do a lookup and see the doubled name.

A few panels want a trailing dot to mean “this is the complete name, don’t append” (blog.example.com.), and Cloudflare’s UI lets you type the full name and quietly strips the zone for you. But the safe default that works everywhere is: type only the label. For a multi-level subdomain like api.staging.example.com, the label is api.staging.

Wildcards, and when you actually want one

A wildcard record — name * — answers for any label that doesn’t have its own record. *.example.com as an A record means anything.example.com resolves to that IP. It’s genuinely useful for multi-tenant setups (customer1., customer2., … all landing on one app) so you don’t add a record per tenant.

But wildcards are narrower than people expect, and RFC 4592 spells out the traps. A wildcard matches only names that have no explicit record — the moment you add blog.example.com, the wildcard stops covering blog. It does not match multiple levels: *.example.com covers a.example.com but not a.b.example.com. And it does not magically create matching TLS certificates — a wildcard DNS record and a wildcard SSL certificate are two separate things you both have to set up. Treat * as a fallback, not a default; a wildcard pointed at an app you no longer run is a subdomain-takeover surface.

Check it with DechoNet

DNS Lookup resolves the exact subdomain and shows what the record actually returns — the fastest way to catch the doubled-name trap (you’ll see blog.example.com.example.com in the answer), confirm a CNAME points where you meant, or see the NXDOMAIN that means no record exists yet.
DNS Propagation checks the subdomain from resolvers around the world at once, so you can tell “I need to wait longer” (some resolvers see it, others still don’t) apart from “the record is wrong” (nobody sees it).

Resolution Checklist

Decide the type: A/AAAA if you have an IP, CNAME if a platform gave you a hostname to point at.
In the Name/Host box, enter only the label (blog), never the full blog.example.com — your provider appends the zone for you.
If it’s a CNAME, make sure that name has no other records (no MX, no TXT, no second A) — RFC 1034 forbids it.
Save, then look the subdomain up with DNS Lookup and confirm the answer is the value you set, not a doubled name.
If some resolvers see it and others don’t, wait out the old TTL — check propagation rather than re-editing a record that’s already correct.

When to Escalate

The subdomain is delegated. If there’s an NS record for the subdomain in your zone, that name has been handed to a different set of nameservers, and your A/CNAME must be created there, not in this zone. Editing records in the parent zone does nothing. Check for a subdomain NS record before assuming your change should work.
You’re editing a zone nobody reads. If nothing you change ever takes effect, confirm your domain’s authoritative nameservers actually point at the DNS host you’re editing. A domain whose nameservers were moved to another provider will happily let you edit stale records in the old panel forever.
You need mail and a CNAME on the same name. You can’t. Switch that name to an A record, or move the CNAME’d service to a different label.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.