Apex domain (naked / root domain)

An apex domain (also called the naked domain, root domain or bare domain) is the hostname with no label in front of it: example.com, not www.example.com. It is the one name in a zone that can never hold a CNAME record, which is why pointing a customer's bare domain at a SaaS app is harder than pointing their www.

That single restriction is the root cause of most custom-domain support tickets. This page covers why the restriction exists, what production sites actually publish at their apex, and the three ways to work around it, with the failure mode of each.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free.

The apex is not special by policy, it is special by construction

The usual explanation is "RFC 1034 doesn't allow it." That is true but it makes the rule sound arbitrary, and it leaves people hunting for a DNS provider that will let them do it anyway. The real reason is structural.

RFC 1034 section 3.6.2 says that if a CNAME record is present at a name, no other data may be present at that name. RFC 2181 section 10.1 restates it more sharply: a CNAME and any other record type at the same owner name is illegal.

Now look at what a zone apex is required to carry. The apex is where the SOA record lives, and where the NS records that delegate the zone live. Both are mandatory. A zone without them is not a zone.

So the apex always has other data, which means it can never have a CNAME. Not "should not" — cannot, without producing a zone that is invalid on its face.

Queried against the authoritative nameservers directly on 2026-08-26, with recursion off so nothing is coming from a cache:

Name	Authoritative server	SOA	NS	CNAME
shopify.com	gold.foundationdns.com	1	3	0
www.shopify.com	gold.foundationdns.com	0	0	0
stripe.com	ns-1087.awsdns-07.org	1	4	0
www.stripe.com	ns-1087.awsdns-07.org	—	—	1

The apex rows carry SOA and NS. The www row on shopify.com carries neither, which is exactly why www is free to be a CNAME and the apex is not. www.stripe.com uses that freedom: it is a CNAME pointing back at stripe.com.

What production apexes actually publish

Every workaround discussion assumes big sites have solved this in some clever way. They have not. Resolved through 1.1.1.1 on 2026-08-26:

Apex	Answer type	Authoritative TTL
shopify.com	A	60
github.com	A	60
stripe.com	A	30
notion.so	A	300
netlify.com	A	300
vercel.com	A	1800
cloudflare.com	A	—
linear.app	A	—
figma.com	A	—
discord.com	A	—

Ten out of ten return A records. Zero return a CNAME. That includes the four sitting behind Cloudflare (notion.so, linear.app, discord.com, and cloudflare.com itself), which is the point worth internalising:

CNAME flattening is invisible on the wire. When a provider flattens an apex CNAME, it resolves the target itself and hands the client synthesized A records. The client never sees a CNAME, because if it did the answer would be illegal. You cannot look at a dig output and tell whether an apex is a static A record or a flattened alias. There is no external difference, by design.

The same is true of an ALIAS record and an ANAME record. These are vendor names for the same server-side trick, not new record types on the wire. No resolver has ever needed to learn them.

A tell that isn't one

Public resolvers report odd TTLs at these apexes — 15 for shopify.com, 13 for github.com, 57 for cloudflare.com, 114 for discord.com. It looks like a flattening signature: a remaining upstream lifetime being passed through.

It isn't. Asked directly, the authoritative servers return stable round values (60, 60, 300, 1800, 30, 300 in the table above). The odd numbers are ordinary recursive-cache countdown at the resolver. If you were planning to use TTL shape to detect a flattened apex, it does not work — checked, and it does not hold.

The three workarounds, and where each one breaks

1. Redirect the apex to www

The customer points www.theirdomain.com at your edge with a CNAME, and configures a redirect from the apex to www at their registrar or DNS host.

This is the most reliable option because it asks nothing unusual of their DNS provider. Its cost is that the redirect itself has to be served by somebody, and a plain DNS host cannot serve HTTP. Providers bundle a redirect service (domain forwarding) to cover this, and the quality varies: some only redirect HTTP and break the moment a browser tries HTTPS first, because serving https://theirdomain.com requires a valid certificate for the apex before the redirect can even be sent.

Watch for the HSTS interaction too. If the apex has ever sent an HSTS header with includeSubDomains, browsers will refuse the plaintext redirect entirely.

2. Ask them to use a flattening provider

If the customer's DNS is on a provider that supports flattening, ALIAS or ANAME, they can enter what looks like an apex CNAME and the provider does the rest.

The catch is that you do not control which provider your customer uses, and you find out which one they are on only after they have already failed. Support-wise this converts a hard error into a conditional one, which is often worse: the instruction "add a CNAME at your root" works for some customers and not others, and neither group knows why.

There is a second-order problem. Flattening resolves your edge hostname on the provider's schedule, not yours. If you move an edge IP, every flattening provider re-resolves at its own cadence, and you have no way to see or influence it.

3. Publish edge IPs and have them add A records

You hand out a fixed set of IPs and the customer creates A records. It works everywhere, with no provider dependency.

The price is that you can never move those IPs. This is the constraint people underestimate, and it is worth stating precisely: your ability to rotate an edge IP is bounded by a TTL that your customer sets, on a record you cannot see. The apexes measured above run TTLs from 30 seconds to 1800 seconds, and those are companies who tune this. A customer who accepted their provider's default may be on 3600 or 86400.

So the honest version of workaround 3 is: the IPs are permanent. Plan the anycast or edge network behind them so you never need to change the address a customer typed in, because you cannot make them change it.

Choosing between them for a SaaS

Approach	Works on any DNS host	You can rotate IPs	Support burden	Certificate at apex
Apex → www redirect	Yes	Yes	Low, one instruction	Needed for the redirect itself
Flattening / ALIAS	No, provider-dependent	Partly, on their schedule	High, fails silently for some customers	Normal
Published edge IPs	Yes	No	Low to set up, permanent constraint	Normal

Most custom domain APIs default to the redirect and offer edge IPs as the escape hatch. If you are building multi-tenant custom domains yourself, decide this before you publish setup instructions, because the choice is close to irreversible once customers have DNS pointing at you.

The certificate side

Whichever route you pick, the apex needs its own certificate entry. A wildcard certificate for *.example.com does not cover example.com. Wildcards match exactly one label, and the apex has zero. This surprises people regularly, and it is the reason an apex can fail TLS while every subdomain succeeds.

For automated issuance across many customer domains, the DNS-01 challenge validates an apex the same way it validates anything else, by publishing a TXT record at _acme-challenge.example.com. The HTTP-01 challenge also works at an apex, provided the apex already resolves to you on port 80 — which, in the redirect-to-www design, it may not. SNI then lets one IP serve the right certificate for every apex you have issued for. There is more on the full flow in how SSL works for custom domains.

Cleaning up afterwards

An apex that points at edge IPs you no longer serve is a dangling DNS record, and on shared infrastructure that is a subdomain takeover risk at the most valuable name the customer owns. When a customer leaves, tell them to remove the A records, and check that they did.

You can inspect any of this with the DNS record lookup, confirm a CNAME target with the CNAME lookup, and watch a change roll out with the DNS propagation checker.

FAQ

Why can't I use a CNAME on my apex domain? Because the apex must carry SOA and NS records, and RFC 1034 forbids any other data at a name that holds a CNAME. It is not a provider restriction you can shop around for — an apex with a CNAME is an invalid zone. Providers that appear to allow it are flattening the record server-side and returning A records.

What is the difference between an apex domain and a root domain? None. Apex domain, root domain, naked domain, bare domain and zone apex all mean example.com with no subdomain label. "Root domain" is slightly ambiguous because the DNS root is the empty label at the top of the whole namespace, so "apex" is the more precise term.

Does CNAME flattening actually work? Yes, and it is invisible to clients. The provider resolves the target and returns A records, so what reaches the resolver is a legal answer. Measured across ten major apexes on 2026-08-26, all ten returned A records and none returned a CNAME, including four behind Cloudflare. The trade-off is that re-resolution happens on the provider's schedule, not yours.

Does a wildcard certificate cover the apex domain? No. *.example.com matches one label, so it covers app.example.com but not example.com itself. The apex needs its own entry on the certificate, which is usually handled by issuing a SAN certificate covering both names.

Should I tell customers to use www or the apex? Point them at www with a CNAME and have them redirect the apex to it. That instruction works on every DNS provider, and it keeps your edge addresses changeable. Publishing A records for the apex is the fallback when a customer insists on a bare domain, and it commits you to those IPs indefinitely.

How long until an apex change takes effect? As long as the old record's TTL, which the domain owner controls. The apexes measured here run 30 to 1800 seconds, but a provider default of 3600 or 86400 is common. Lower the TTL before making the change, not after, since the reduction itself has to propagate first.