- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
The bare name behaves differently from every other name in the zone, and the record most hosts ask for is one the root cannot normally hold.
A record, root domain, and why the apex is the awkward one
Pointing a client’s domain at a hosted page looks like a two-minute job and regularly turns into an afternoon. The reason is almost always the same: the root domain — the bare name with no subdomain, sometimes called the apex or the naked domain — behaves differently from every other name in the zone, and the record type most hosts ask for is one the root cannot normally hold.
This is a short explanation of what the records are, why the apex is special, and what to do when the host asks for something your DNS provider will not accept.
The record types, in the terms that matter here
| Record | What it points at | Where it can live |
|---|---|---|
| A | An IPv4 address, written as numbers | Anywhere, including the root |
| AAAA | An IPv6 address | Anywhere, including the root |
| CNAME | Another hostname, which is then resolved in turn | Subdomains only, and it cannot coexist with other records on the same name |
| TXT | Text, used for verification and mail policy | Anywhere, several allowed on one name |
| MX | Where mail for the domain should be delivered | Usually the root — which is exactly why a CNAME there is a problem |
The rule that causes the trouble is the third row combined with the fifth. A CNAME says “this name is an alias for that one”, and the specification requires that a name holding a CNAME hold nothing else. The root usually holds MX records for the domain’s mail and TXT records for verification and authentication, so a CNAME at the root would displace them. That is why most DNS providers refuse it — not a limitation of the interface, but a correctness rule.
What to do when the host asks for a CNAME at the root
Hosted platforms prefer CNAMEs because their addresses change, and a CNAME follows automatically while an A record has to be updated by hand. When the platform asks for one at the apex, you have three sane options.
- Use the platform’s A record instead. Most publish a static address for exactly this case. It works, and it means you must update it if the platform ever changes address — so record where it came from.
- Use your DNS provider’s flattening feature. Many offer an apex alias that behaves like a CNAME but answers with addresses, keeping MX and TXT intact. Names vary between providers; the behaviour is what to look for.
- Redirect the root to a subdomain. Serve the site at www, and have the root issue a permanent redirect. This is the most robust option and the one most likely to be rejected by a client who wants the bare name in their advertising.
What not to do is delete the MX records to make room for a CNAME. The site will work and the client’s email will stop, usually noticed a day later by someone who cannot connect the two events.
Propagation, and what it is not
A changed record is not instant, and the delay is not mysterious. Resolvers cache answers for the length of time the record’s own TTL specifies, so anyone who looked the name up recently keeps the old answer until that expires. Lowering the TTL a day before a planned change is the only way to make the change fast; lowering it afterwards does nothing for anyone already holding the old value.
Two related habits save time. Check the record from outside your own network, because your local resolver and your browser both cache aggressively and will show you a stale answer long after the world has moved on. And expect inconsistency during the window: some visitors reaching the new host while others reach the old one is normal, not a misconfiguration.
The certificate follows the DNS
Once the name points at the platform, the platform has to obtain a certificate for it, and that process validates through DNS or through an HTTP request to the name itself. Both fail if the record is wrong, absent, or still propagating — which is why a stalled certificate issuance is so often a DNS problem wearing a certificate’s clothing.
The visitor-facing symptom is worth knowing too. A site reachable but without a valid certificate produces a not-secure warning, which clients report as “the site is broken” and which is usually one record away from fixed. If the certificate covers the root but not www, or the reverse, half your visitors see the warning and the other half do not.
Do not disturb the records that are not about the website
A domain’s zone carries several jobs at once, and the website is only one of them. Changing records for a page launch routinely breaks the others:
- Mail. MX records, and the TXT records behind SPF, DKIM and DMARC, live on the same names. Removing or replacing them stops mail arriving or stops it being trusted.
- Sending identity. The subdomain records that authorise outbound campaigns are separate from the website’s, which is why the workflow sender domain can break while the site is perfectly fine.
- Verification tags. TXT records proving ownership to search, advertising and messaging platforms are easy to remove during a tidy-up, and their absence is only discovered when a re-verification is needed — including the ones behind business messaging registration.
Before touching anything, export the current zone. It takes a minute and it is the difference between an undo and an investigation.
Agency practicalities
Running many client domains multiplies the same small problems. Keep a record of who controls each registrar and each DNS zone, because the most common delay in a launch is not technical — it is finding the person with the login. Where you resell under your own brand, the customer sees only you when a name does not resolve, which is the responsibility described in a white-label arrangement.
After a domain change, re-check the things that quietly depend on the hostname: absolute links in page code, tracking configured against a specific domain in code in the page header, embedded forms whose height negotiation is origin-sensitive as in why an embedded frame clips, and booking links, since a calendar clients can book into is often shared as a bare URL that clients have already given out. Cloned pages are the usual source of stale hostnames, which is one more instance of what moves and what breaks on import.
Then measure the site once more from a clean connection. A domain move changes which host serves the assets, and what a page speed score measures can shift in either direction for reasons that have nothing to do with the pages themselves.
See also: DNS Records for Funnel Hosting: The Full Set
Frequently Asked Questions
Why can a root domain not use a CNAME?
Because a CNAME makes the name an alias, and the specification requires that a name holding a CNAME hold nothing else. The root usually holds MX records for mail and TXT records for verification, so a CNAME there would displace them. Most DNS providers refuse it for that reason.
What should I do when a host asks for a CNAME at the apex?
Use the platform’s published A record, use your DNS provider’s apex alias or flattening feature which behaves like a CNAME while keeping MX and TXT intact, or serve the site at www and redirect the root to it. Never delete MX records to make room.
How long does a DNS change take to take effect?
As long as the record’s TTL, because resolvers keep the previous answer until it expires. Lowering the TTL a day before a planned change is what makes the change fast; lowering it afterwards does nothing for anyone already holding the old value.
Why does the site work for some people and not others after a change?
Because caches expire at different times. Some visitors reach the new host while others still reach the old one, which is normal during the propagation window rather than a misconfiguration. Check from outside your own network, since local resolvers and browsers cache aggressively.
Why does the certificate fail after pointing the domain?
Because certificate issuance validates through DNS or through a request to the name itself, and both fail if the record is wrong, missing or still propagating. A stalled certificate is very often a DNS problem rather than a certificate one.
What should be checked before editing a zone?
Export the current zone first. Then be careful of records that have nothing to do with the website: mail routing, the authentication records behind email deliverability, the subdomains used for outbound sending, and the ownership verification tags whose absence only surfaces at the next re-verification.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.