Subdomain in Netlify: Adding One, and What Carries Over to Any Host

A subdomain in Netlify is added in two ways: as a custom domain on an existing site’s Domain management panel, which points that one subdomain at that one site, or as its own separate Netlify site with its own domain setting, which lets several subdomains of the same root domain point at entirely different deployed projects. Both rely on a CNAME record at the subdomain pointing to the site’s Netlify hostname; the apex domain, which cannot take a CNAME under the DNS standard, uses Netlify’s ALIAS or A record handling instead. Netlify issues a free certificate automatically once the DNS record resolves and ownership is verified, whether Netlify manages the DNS zone or an external provider does.

The mechanics here are not Netlify-specific, which is the part most Netlify-only tutorials skip. A subdomain is a DNS record, a certificate is issued once that record resolves correctly, and the same CNAME-vs-apex distinction applies whichever host answers on the other end. Learning it through Netlify’s UI is a reasonable way to learn it once.

Table of contents

• Two ways to add a subdomain in Netlify
• CNAME vs A/ALIAS: apex and subdomain records
• Netlify DNS vs external DNS
• Automatic branch-deploy subdomains
• Certificate issuance for subdomains
• Multiple projects on subdomains of one root domain
• What carries over to any host
• How this fits the rest of the stack
• FAQ

Two ways to add a subdomain in Netlify

From an existing site: Site configuration, Domain management, Add a domain, and enter the subdomain, blog.example.com. That subdomain now serves whatever that site deploys, and it shows up alongside the site’s default .netlify.app address rather than replacing it.

As its own site: create a separate Netlify site from its own repository or deploy source, then add the subdomain to that site’s domain settings instead. This is the pattern for app.example.com and docs.example.com being two entirely different projects that happen to share a root domain, each with its own build, its own deploy history, and its own environment variables.

The choice between the two is not about DNS: it is about deploy independence. A blog folder inside the same repository as the main site is the first pattern, one build, one deploy history, a subdomain bolted on for routing. A documentation site built by a different tool from a different repository is the second: its own pipeline, its own failure mode, and a subdomain that happens to share the parent domain’s name and nothing else.

• Check which pattern applies before creating anything: does the content live in the same repository as the main site, or a separate one.
• A subdomain added to the wrong site shows the wrong project until the domain is removed there and re-added to the correct one, which costs a DNS propagation wait twice.

CNAME vs A/ALIAS: apex and subdomain records

A subdomain almost always uses a CNAME record, pointing blog to the target host’s hostname, such as yoursite.netlify.app. This is standard DNS and applies identically on any host. A CNAME record makes one name an alias for another, and the DNS resolver follows it before returning an answer.

The domain apex, example.com with nothing in front of it, cannot technically hold a CNAME under the DNS specification. The apex also needs to hold other record types, such as MX for email, and a name cannot mix a CNAME with anything else at the same label. Netlify, like most hosts, offers an ALIAS or ANAME-style record, or a set of A records pointing at Netlify’s load balancer IPs, to work around that restriction at the apex specifically.

blog.example.com.   CNAME   yoursite.netlify.app.
app.example.com.    CNAME   another-site.netlify.app.
example.com.         ALIAS   yoursite.netlify.app.   ; apex, provider-dependent record type

The failure mode to know: adding a CNAME at the apex anyway, because the DNS provider’s UI let you, breaks mail delivery and any other apex record silently, sometimes not until someone notices bounced email days later. If a provider does not offer ALIAS or ANAME, an A record pointed at the host’s published IP addresses is the fallback, accepting that those IPs can change and need to be re-checked occasionally.

Netlify DNS vs external DNS

Netlify DNS delegates the entire zone to Netlify’s nameservers, after which every record, including ones unrelated to Netlify sites, such as an MX record for email, is managed in Netlify’s dashboard. It simplifies subdomain setup because Netlify creates the CNAME automatically when a subdomain is added, and it is the lower-friction choice for a domain that serves nothing but Netlify sites.

Keeping DNS with the original registrar or a dedicated DNS provider and adding individual records by hand is the other path, and it is the one that keeps the DNS zone independent of any one hosting platform. For a domain with services split across more than one provider, an email provider, a second host for an API, a third for a marketing tool, this independence is usually worth the extra manual record.

A second scenario worth naming: a domain that starts entirely on Netlify DNS and later needs a service elsewhere, a transactional email provider that requires its own TXT and MX records, for instance. Migrating the zone back to an external provider at that point means re-creating every record Netlify had auto-managed, so a team that expects to add non-Netlify services later is often better off keeping the zone external from day one and pointing individual records at Netlify instead.

Automatic branch-deploy subdomains

Netlify generates a preview subdomain automatically for every branch and pull request, in the form branch-name--yoursite.netlify.app, without any DNS configuration required. This is separate from a custom subdomain on a real domain; it exists on Netlify’s own .netlify.app domain and is meant for reviewing a change before merge, not for a permanent address.

A custom subdomain can also be pointed at a specific deploy context, for example a staging subdomain permanently tracking the staging branch. That is a deploy-context setting in the site’s build configuration, not a DNS setting, and it is what turns a temporary branch preview into a stable address a QA team can bookmark.

What to check when a branch preview does not appear: that the branch was actually pushed to the connected repository, that deploy previews are enabled for pull requests in the site’s build settings, and that the branch is not on the list of ones explicitly excluded from deploys. A preview subdomain that 404s, rather than failing to appear at all, usually means the build failed silently and the previous successful preview is what is still being served.

Certificate issuance for subdomains

Netlify provisions a free TLS certificate automatically through Let’s Encrypt once the subdomain’s DNS record resolves to Netlify and domain ownership is confirmed. This normally takes minutes after the CNAME propagates, though DNS propagation itself can take longer depending on the previous record’s time-to-live value.

Each subdomain, including preview and branch-deploy subdomains, gets its own certificate. There is no manual certificate step to perform, which is standard for platforms handling both the DNS-facing and certificate-facing pieces together rather than leaving certificate issuance to a separate tool.

A certificate stuck in a pending state for more than an hour almost always traces back to the DNS record, not the certificate authority: the CNAME points somewhere other than Netlify, a conflicting A record still exists from before the subdomain was added, or the domain’s DNSSEC configuration is rejecting the validation check. Removing the conflicting record and forcing a certificate retry from the domain settings resolves the large majority of these without contacting support.

Multiple projects on subdomains of one root domain

Running app.example.com, docs.example.com, and status.example.com as three entirely separate deployed projects, each with its own repository, build pipeline, and possibly its own host, is a common pattern once a product grows past a single site. Each subdomain is just a CNAME pointing at whichever host serves that particular project.

The root domain’s DNS becomes the map of the whole product, which is a reason to keep that zone somewhere stable and independent of any single host, rather than fully delegated to one provider that only serves one of the subdomains.

A second scenario: a status page hosted on a dedicated status-page service, a docs site built by a static-site generator on one host, and the main app on Netlify, all under the same root domain. Nothing about that setup is unusual from a DNS point of view; it is three CNAME records pointing at three different hostnames, each issuing its own certificate independently. The only shared resource is the root zone itself, which is exactly why keeping it on a neutral DNS provider avoids a future migration touching every subdomain at once.

What carries over to any host

Every mechanic here, CNAME for a subdomain, ALIAS or A records at the apex, automatic certificate issuance once DNS resolves, is standard DNS and TLS behaviour, not a Netlify feature. Moving a subdomain from Netlify to another static host is the same operation: change the CNAME target, wait for the new certificate to issue, done.

What to check before and after a migration: confirm the new host’s target hostname before touching DNS, lower the existing record’s time-to-live a day ahead so the change propagates quickly once made, and keep the old site running until the new certificate has actually issued rather than tearing it down the moment the CNAME is updated. A subdomain migrated this way sees at most a brief window of DNS inconsistency, not downtime, because the old target keeps answering until resolvers catch up to the new one.

That portability is the actual point of learning the DNS layer instead of just the host’s UI. A subdomain configured this way is never locked to one provider; the record can point anywhere that accepts a CNAME, which keeps the migration decision a DNS change rather than a rebuild.

How this fits the rest of the stack

Static sites on RunxBuild follow the same pattern: add a custom domain or subdomain, point a CNAME at it, and the certificate issues automatically once the record resolves, with each project’s own subdomain getting its own deploy history and environment. The RunxBuild hosting calculator prices out a multi-subdomain setup, docs on one subdomain and the app on another, against the 120GB bandwidth allowance each static site includes.

Useful related references:

• Branch Deploy on Netlify: How It Works and When to Use One
• What Is a Custom Domain? The Working Definition for Builders Who Actually Have One
• Multi-Domain SSL: SAN Certificates, Wildcards, and What to Use
• Custom domains and certificates on RunxBuild

FAQ

How do I add a subdomain in Netlify?

From an existing site’s Domain management panel, add a domain and enter the subdomain, such as blog.example.com. To point the subdomain at a different project entirely, create it as its own separate Netlify site and add the subdomain there instead.

Can I host multiple sites on subdomains of the same domain?

Yes. Each subdomain is an independent CNAME record, so app.example.com and docs.example.com can be two entirely separate deployed projects, on Netlify or split across different hosts, sharing only the root domain’s DNS zone.

Do I need Netlify DNS to use a subdomain?

No. A CNAME record at any DNS provider pointing the subdomain to Netlify’s hostname works the same way. Netlify DNS is a convenience that delegates the whole zone and automates record creation, not a requirement for a subdomain to function.

How long does it take for a subdomain’s DNS to work?

Usually minutes once the CNAME record is created, though propagation time depends on the previous record’s TTL and can take up to a few hours in slower cases. The certificate issues automatically shortly after the record resolves correctly.

Why can’t I add a CNAME at my domain’s apex?

The DNS specification does not allow a CNAME to coexist with other record types at the same name, and the apex usually needs an MX record for email among others. Most hosts, including Netlify, offer an ALIAS or ANAME-style record, or a set of A records, as the apex-safe equivalent.