What Is an Apex Domain (Naked Domain)?

If you have ever connected a domain to a hosting platform, you have probably seen instructions that treat example.com and www.example.com differently: "add a CNAME for www, but add an A record for the apex." That word, apex, trips up a lot of people. The apex domain (also called the root domain, bare domain, or naked domain) is the domain you registered, with nothing in front of it. It is the most important name you own, and it has special rules in DNS that affect how you can host websites and services on it. This article explains what an apex domain is, where it sits in the DNS hierarchy, what records it must and cannot hold, and the practical options for pointing it at modern hosting platforms. For background on how names are structured, see what a fully qualified domain name is.

What Is an Apex Domain?

The apex domain is the name at the top of your DNS zone: the domain you registered, without any subdomain labels. If you registered example.com, then:

Name	What it is
example.com	The apex (root, bare, or naked domain)
www.example.com	A subdomain of the apex
blog.example.com	A subdomain of the apex
api.eu.example.com	A subdomain two levels below the apex
com	The top-level domain (TLD), run by the registry

The terms are used interchangeably:

• Apex comes from DNS terminology: the zone apex is the top node of a zone.
• Root domain is common in hosting dashboards, though it can be confused with the DNS root, the unnamed node above all TLDs that is served by the root name servers.
• Naked or bare domain emphasises that there is no www or other prefix.

For TLDs with a second-level structure, such as .co.uk or .com.au, the apex is the name you registered, for example example.co.uk. The co.uk part belongs to the registry.

In zone files and most DNS dashboards, the apex is written as @, which is shorthand for the zone's origin.

Apex, Zone, and Delegation

When you register a domain and set its name servers, the TLD registry delegates your name to those servers. The .com zone contains NS records saying, in effect, "for example.com, ask these servers." Your DNS host then serves a zone whose top node is the apex.

Because the apex is the top of the zone, it is where the zone's administrative records live. You can see the delegation and the apex records with dig:

# Ask a .com TLD server who is authoritative for example.com
dig +norec @a.gtld-servers.net example.com NS

# Ask your own authoritative servers for the apex records
dig example.com SOA +short
dig example.com NS +short
dig example.com A +short

Records the Apex Must Have

Every zone apex is required to hold two record types:

• SOA (Start of Authority): exactly one, describing the zone's primary server, administrator contact, serial number, and timers.
• NS (Name Server): one or more, listing the authoritative servers for the zone. These should match the delegation at the registry.

Most DNS hosts create both automatically, and you rarely edit them.

Records Commonly Found at the Apex

Beyond SOA and NS, the apex typically holds:

Record	Purpose at the apex
A	IPv4 address of the website for the bare domain
AAAA	IPv6 address of the website
MX	Mail servers for addresses like you@example.com
TXT	SPF policy, domain verification tokens for Google, Microsoft, etc.
CAA	Which certificate authorities may issue certificates for the domain
HTTPS	Service binding information, including aliasing at the apex
DS	Lives in the parent zone, but links your apex to DNSSEC

A typical apex section of a zone file looks like this:

$ORIGIN example.com.
$TTL 3600
@    IN  SOA   ns1.dns-host.net. hostmaster.example.com. (
               2026102601 ; serial
               7200       ; refresh
               3600       ; retry
               1209600    ; expire
               3600 )     ; negative caching TTL
@    IN  NS    ns1.dns-host.net.
@    IN  NS    ns2.dns-host.net.
@    IN  A     203.0.113.10
@    IN  AAAA  2001:db8::10
@    IN  MX    10 mail.example.com.
@    IN  TXT   "v=spf1 include:_spf.example-mail.net -all"
@    IN  CAA   0 issue "letsencrypt.org"
www  IN  CNAME example.com.

The Big Constraint: No CNAME at the Apex

The most important rule about apex domains is that you cannot put a CNAME record there. This trips up anyone trying to point a bare domain at a platform that only gives you a hostname, like myapp.hosting-platform.net.

The reason comes from the original DNS specification, RFC 1034: if a name has a CNAME record, it cannot have any other records. A CNAME says "this name is just an alias; go look up that other name instead," so having other data alongside it would be contradictory. Since the apex must always hold SOA and NS records, a CNAME there would break the rule and the zone.

Some DNS dashboards will refuse to save an apex CNAME. Others accept it and then behave unpredictably: mail can stop working, because resolvers that see a CNAME may ignore your MX records. A full explanation of what goes wrong is in can you use a CNAME record on the root domain.

How to Point an Apex Domain at a Website

You have several ways around the CNAME restriction.

1. Use A and AAAA Records

The traditional method: put the IP addresses of your server or platform directly in A and AAAA records. Many hosting platforms publish stable IP addresses specifically for apex domains. The downside is that if the provider ever changes those IPs, you must update your records manually.

2. Use ALIAS, ANAME, or CNAME Flattening

Many DNS providers offer a pseudo-record that behaves like a CNAME but is legal at the apex. Your DNS provider looks up the target hostname itself and answers queries for the apex with the resulting A and AAAA records. It goes by different names:

• ALIAS or ANAME at providers such as DNSimple, NS1, and others
• CNAME flattening at Cloudflare
• Alias records in AWS Route 53 (for AWS resources such as CloudFront and load balancers)

These are provider features, not standard DNS record types, so they only work while you use that provider. Details are in what an ALIAS or ANAME record is and what CNAME flattening is.

3. Redirect the Apex to www

Host your site on www.example.com (which can use a CNAME) and make the apex answer only with a redirect. The apex still needs an A record pointing at whatever performs the redirect, such as your server, a CDN, or a registrar forwarding service. This approach is explained in www vs. non-www.

4. HTTPS Records (Emerging)

The newer HTTPS record type (RFC 9460) supports an AliasMode that can point the apex at another hostname for HTTPS clients. Browser support is still incomplete, so it is not yet a replacement for the options above, but it is worth knowing about:

@    3600    IN    HTTPS    0 myapp.hosting-platform.net.

Comparison

Method	Standard DNS?	Follows provider IP changes?	Portable across DNS hosts?
A/AAAA records	Yes	No	Yes
ALIAS/flattening	No (provider)	Yes	No
Redirect to www	Yes	Yes, for www	Yes
HTTPS AliasMode	Yes	Yes	Yes, but limited support

Apex Domains and Hosting Platforms

Most platforms document an apex option. A common pattern for a static or serverless host is:

@      3600    IN    A        203.0.113.50
www    3600    IN    CNAME    myapp.hosting-platform.net.

Platform-specific steps for two popular hosts are in how to point a domain to Vercel or Netlify. Always copy the exact IPs or targets from your platform's current documentation, since they occasionally change.

Apex Domains, Email, and Cookies

A few other things are worth knowing about the apex:

• Email lives at the apex. Addresses like you@example.com depend on MX records at the apex, and SPF is a TXT record there. Any change to apex web hosting must leave these intact.
• Cookies scoped to the apex reach every subdomain. A cookie set with Domain=example.com is sent to www, api, blog, and every other subdomain. Keep this in mind if you host the main site on the apex.
• Certificates must cover the apex explicitly. A wildcard certificate for *.example.com covers www.example.com but not example.com itself. Request both names:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"

How to Check Your Apex Configuration

Run a quick audit with dig:

#!/usr/bin/env bash
DOMAIN="${1:-example.com}"
for type in SOA NS A AAAA MX TXT CAA CNAME; do
  echo "== $type"
  dig +short "$DOMAIN" "$type"
done

If the CNAME section prints anything for your apex, fix it: replace it with A/AAAA records or an ALIAS/flattened record. If A and AAAA are empty, the bare domain will not load in a browser even if www works, which is one of the most common causes of "my site only works with www"

Apex Domain FAQ

Conclusion

The apex domain is the top of your DNS zone and the name your brand is built on. It must hold SOA and NS records, usually carries your mail and verification records, and cannot hold a CNAME. That single restriction explains most of the confusing instructions hosting platforms give for bare domains.

To point an apex at a website, use A/AAAA records with stable IPs, an ALIAS or flattened record from a capable DNS provider, or host on www and redirect the apex to it. Whatever you choose, make sure the apex resolves, is covered by your certificate, and keeps its mail records intact.

Here are some useful references for going deeper on apex domains:

1. RFC 1034: Domain Names, Concepts and Facilities — defines zones, delegation, and the rule that a CNAME cannot coexist with other data.
2. RFC 1035: Domain Names, Implementation and Specification — defines the zone file format, including the @ origin shorthand and SOA records.
3. RFC 9460: Service Binding and Parameter Specification via the DNS — defines HTTPS and SVCB records, including AliasMode for the apex.
4. Cloudflare Docs: CNAME Flattening — how Cloudflare resolves CNAME-like records at the apex.
5. AWS Documentation: Choosing Between Alias and Non-Alias Records — how Route 53 alias records work at the zone apex.