An apex domain is a domain name at its root level, without any subdomain prefix. example.com is an apex domain. www.example.com is not, it has the www subdomain prefix. blog.example.com is not, it has the blog subdomain prefix. The apex domain is the base from which all subdomains extend, it sits at the top of the domain’s own namespace, one level below the TLD.

Apex domains are also called root domains, naked domains, bare domains, or zone apexes. These terms all refer to the same thing, the domain name consisting of only the second-level domain and TLD with no additional labels to the left. The DNS specification uses the term zone apex, the point at the top of a DNS zone where SOA records and NS records are required.

The apex domain has special significance in DNS because of a fundamental technical restriction, CNAME records cannot be placed at the zone apex. This restriction, rooted in the DNS specification, creates real practical challenges for connecting apex domains to modern hosting platforms, CDNs, and redirect management services that provide hostnames rather than fixed IP addresses. Understanding this restriction and the workarounds available is essential for anyone managing domains and redirects.

Why apex domains are technically unique

The zone apex restriction on CNAME records is the defining technical characteristic of apex domains and the source of most of the complexity surrounding them.

The CNAME restriction: the DNS specification prohibits CNAME records at the zone apex because the apex must simultaneously have NS records and SOA records: the records that define the zone’s authoritative nameservers and administrative information. A CNAME record declares that the name is an alias for another name, meaning all records for that name should be looked up at the target. Having both a CNAME and NS or SOA records at the same name creates a contradiction, the CNAME says “look elsewhere for everything” while the NS and SOA records are specific to this zone.

This restriction is not a limitation of DNS providers, it is built into the DNS protocol itself. Any properly implemented DNS server rejects CNAME records at the zone apex as a protocol violation.

Why this matters for modern infrastructure: the practical problem is that most modern hosting platforms, CDNs, and redirect management services provide a hostname rather than a fixed IP address for their infrastructure. proxy.redirect.supply, sites.platform.com, cdn.provider.net: all hostnames. Subdomains connect to these services easily via CNAME. Apex domains cannot use CNAME. They must use A records which require a fixed IP address, something many services do not provide or cannot guarantee will remain stable.

Apex domain vs www subdomain

The most common distinction involving apex domains is the choice between example.com: the apex, and www.example.com: the www subdomain. Both can serve as the primary address for a website but they have different technical characteristics.

The apex domain: example.com. The address most users type when they know a brand, without www. Clean and minimal. Requires A records or ALIAS/ANAME records for connection to modern infrastructure. Cannot use CNAME. Email MX records are also configured at the apex, this does not conflict with A records but would conflict with a CNAME if one were permitted.

The www subdomain: www.example.com. The traditional web address format. Can use a CNAME record pointing to any hostname, the most flexible DNS connection option. Historically the standard form for web addresses, early web conventions placed websites at the www subdomain rather than the apex. Still widely used and understood.

Canonical domain choice: an organisation should choose one canonical form, either the apex or www, and redirect the other to it. Serving content at both without a redirect creates duplicate content issues for SEO as search engines see the same content at two different addresses. The permanent redirect from the non-canonical form to the canonical form consolidates SEO equity and ensures consistent URLs across all backlinks and references.

The choice between apex and www as the canonical form depends on preference, technical requirements, and the infrastructure being used. There is no SEO advantage to either, search engines treat both equally as long as one properly redirects to the other. Some organisations prefer the clean brevity of the apex. Others prefer www for its technical flexibility.

Connecting an apex domain to redirect infrastructure

Connecting an apex domain to redirect management infrastructure, so that visitors to example.com reach the redirect service and receive configured redirect responses, requires working within the CNAME restriction. Several approaches are available depending on what the DNS provider and redirect infrastructure support.

A records pointing to stable IP addresses: if the redirect management infrastructure provides stable, fixed IP addresses an A record at the apex can point directly to those addresses. The A record functions like a CNAME in practical terms, the apex domain resolves to the redirect service’s IP address and requests reach the redirect server.

The limitation is IP address stability. If the redirect management service changes its infrastructure and IP addresses change the A record must be manually updated. For managed redirect services like Redirect Supply that maintain stable infrastructure IP addresses A records are a reliable connection method.

ALIAS and ANAME records: non-standard record types offered by some DNS providers that provide CNAME-like behaviour at the apex. The provider resolves the target hostname to its current IP address internally and returns an A-record-style response to resolvers. From the outside it looks like an A record. Internally it follows the target hostname’s IP address automatically, providing the same automatic update behaviour as a CNAME.

ALIAS records are available on DNS providers including Route 53, DNSimple, NS1, and others under various names, ALIAS, ANAME, or similar. They are the cleanest solution for apex domain connection when the DNS provider supports them.

Cloudflare CNAME flattening: Cloudflare’s nameservers automatically flatten CNAME records at the apex. A domain owner configures what appears to be a CNAME in the Cloudflare DNS interface, pointing the apex to a hostname. Cloudflare’s nameservers resolve the hostname to its current IP address and serve an A-record-style response to resolvers. The CNAME-like behaviour works for the apex without violating the DNS protocol, Cloudflare handles the translation internally.

This requires using Cloudflare as the DNS provider, changing nameservers to Cloudflare. For domain owners already using Cloudflare this is the simplest apex connection approach. For others it requires a nameserver change.

Redirecting apex to www: avoiding the apex CNAME restriction entirely by making www the canonical domain and having the apex redirect to it. The apex has a simple A record pointing to a server that issues a redirect, or uses the registrar’s basic redirect functionality, sending all apex traffic to www.example.com. The www subdomain has a CNAME pointing to the redirect management infrastructure where all redirect rules are applied.

This approach sidesteps the technical complexity but introduces an additional redirect hop for visitors typing the apex domain, they are redirected to www before reaching the final redirect destination. The extra hop adds latency and dilutes SEO equity slightly compared to serving the redirect directly from the apex.

Apex domains and SSL certificates

SSL certificates for apex domains require specific consideration, particularly when serving the apex over HTTPS.

Certificate coverage: a certificate for example.com covers the apex domain specifically. It does not automatically cover www.example.com or other subdomains. A separate certificate, or a multi-domain SAN certificate, is needed to cover both apex and www. Many certificate provisioning workflows cover both example.com and www.example.com in the same certificate using Subject Alternative Names.

Wildcard certificates: a wildcard SSL certificate covers *.example.com: all subdomains, but not the apex example.com itself. A wildcard certificate for *.example.com covers www.example.com, blog.example.com, and any other subdomain but does not cover example.com without an explicit SAN entry for the apex.

SSL provisioning for apex redirect management: when connecting an apex domain to redirect infrastructure the redirect service must have a valid SSL certificate covering the apex domain. Without SSL visitors typing https://example.com receive a certificate error before the redirect response can be sent.

Dedicated redirect management platforms that automatically provision SSL handle apex domain certificates as part of the connection process, provisioning certificates that cover both the apex and the www subdomain. This eliminates the SSL complication from the domain owner’s perspective.

Apex domains and email

Apex domains are where MX records for email are typically configured. Email addressed to @example.com is routed by the MX records at example.com: the apex.

This email configuration coexists with A records for web traffic and with ALIAS/ANAME records for redirect infrastructure connection. A records and MX records can coexist at the apex without conflict, they serve different purposes and do not interfere with each other.

The CNAME restriction is relevant here again, MX records cannot coexist with CNAME records at the same name. This is one of the reasons the CNAME restriction at the apex is particularly important, the apex needs MX records for email and NS records for DNS delegation. A CNAME would override all of these, making email delivery and DNS delegation impossible.

When connecting an apex domain to redirect infrastructure it is essential to preserve MX records for email delivery. Connecting via A records or ALIAS records does not affect MX records, both coexist correctly. Changing nameservers to a DNS provider must be done with care to recreate MX records at the new provider before the nameserver change takes effect.

Apex domain SEO considerations

From an SEO perspective apex domains and www subdomains are treated equally by search engines, there is no inherent ranking advantage to either. The important considerations are canonicalisation and consistency.

Canonical domain declaration: Google and other search engines support multiple methods for declaring the canonical form of a domain. The rel=canonical link element in HTML head declares the canonical URL for individual pages. Permanent redirects from the non-canonical form to the canonical form are the strongest canonicalisation signal. Both should be used together, redirects to enforce canonicalisation and canonical tags to reinforce it.

Consistent internal linking: internal links throughout the site should use the canonical form consistently. Mixing example.com and www.example.com links in internal navigation creates inconsistency even if both redirect to the canonical form. Consistent internal linking reinforces the canonical signal.

Link juice from both forms: backlinks may point to either the apex or www form depending on how external sites have linked. A permanent redirect from the non-canonical form to the canonical form ensures all backlink equity consolidates at the canonical domain regardless of which form external sites used.

Common apex domain mistakes

Forgetting to handle the apex entirely: configuring redirect rules for www.example.com but leaving example.com unconnected to redirect infrastructure. Visitors typing the apex without www reach the old server or receive errors while www visitors are correctly redirected. Both forms must be connected and configured.

CNAME at the apex: attempting to use a CNAME record for the apex domain. Most DNS management interfaces reject this as invalid. If the interface accepts it the resulting DNS configuration may behave unexpectedly with certain resolvers that handle CNAME violations differently.

Missing SSL for the apex: connecting the apex to redirect infrastructure without provisioning an SSL certificate covering the apex. HTTPS visitors receive certificate errors. Ensure SSL covers both example.com and www.example.com.

Not redirecting between apex and www: serving content at both example.com and www.example.com without a redirect between them. Both forms are accessible, duplicate content issues arise and SEO equity is split between the two addresses. Always redirect the non-canonical form to the canonical form with a 301 redirect.

Apex A records pointing to wrong IP: updating the www CNAME to point to new redirect infrastructure but leaving the apex A record pointing to old infrastructure. Www visitors reach the redirect service. Apex visitors reach the old server. Both records must be updated when changing infrastructure.