Apex domain

DNS is divided into zones, and each zone is served by its own set of authoritative nameservers. The apex is the name the zone is named after. For the zone example.com the apex is example.com itself; www.example.com, app.example.com and mail.example.com are names inside that zone, one or more labels below the apex.

Two records are mandatory at every apex. The SOA record states which server is primary for the zone and sets the timers, including how long a missing name may be cached. The NS records list the nameservers that answer for the zone. Nothing else is required, but most apexes also carry an A or AAAA record for the website, MX records for mail, and several TXT records for SPF and ownership proofs.

The apex is not always the domain you bought. If eu.example.com has been delegated to its own nameservers, it is a zone of its own, and eu.example.com is an apex too. Which zone owns a name is a question for DNS, not for the spelling of the name.

A subdomain is any name below the apex. The practical difference is what records each can hold. A subdomain can be a CNAME, an alias that says "this name is really that other name", which is how most SaaS products ask customers to connect: point app.customer.com at customers.yourproduct.com and let your own DNS decide which addresses that resolves to.

An apex cannot be a CNAME. The DNS rules forbid a CNAME from sharing its name with any other record, and the apex always has SOA and NS records, so there is never room for one. This is the single most expensive surprise in custom-domain work: a customer types customer.com, your setup instructions say "add a CNAME", and their DNS provider rejects it. The ALIAS and CNAME flattening entry covers the provider features that work around it.

People often use "root domain" to mean the registrable domain, the part you pay a registrar for. That boundary is set by the Public Suffix List, not by counting dots: example.co.uk is registrable because co.uk is a public suffix. The registrable domain is usually a zone apex, but a delegated subdomain can be an apex without being registrable, as above.

For a product that connects customer domains the distinction matters in one place: before you tell a customer to add a record, find the zone that actually owns the name. The DNS provider detector reports both the domain you typed and the zone that serves it. When the two are equal, the customer gave you an apex.

• Ask for a subdomain by default. app.customer.com or links.customer.com takes one CNAME at every DNS provider.
• Serve the apex from stable IP addresses if your infrastructure has them. A and AAAA records work at the apex everywhere, but those addresses become a promise to every connected customer.
• Point www at you and redirect the apex at the customer's provider, where the provider offers forwarding.

The apex-domain guide goes through each pattern and records, provider by provider, which DNS hosts offer an apex alias at all.

• Apex domains (docs)

  The patterns that work at the apex, and a sourced table of which DNS providers offer an alias record.

• ALIAS and CNAME flattening

  The provider features that let an apex behave like a CNAME, and what they cost.

• DNS provider detector

  Names the zone that owns a domain, so you can tell an apex from a subdomain before asking for records.

• Subdomain vs custom domain

  Which kind of address a SaaS product should give its customers.