- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
A large share of site-is-broken reports are a DNS record that is not what somebody reasonably believes it is.
Check CNAME records for a domain before you debug anything else
A large share of “the site is broken” reports are a DNS record that is not what somebody believes it is. The belief is usually reasonable — the record was entered correctly, in the right panel, and saved — and it is still wrong, because something else is overriding it, because it has not propagated, or because the domain is being served by a nameserver nobody remembered was authoritative.
Checking takes a minute and rules out an entire category of cause. Doing it first is the difference between a short fix and an afternoon.
What a CNAME actually is, and what it cannot do
A CNAME says “this name is an alias for that name” — a hostname pointing at another hostname rather than at an address. That indirection is why hosting platforms ask for one: they can change the address behind their hostname without every customer having to update a record.
Two consequences follow, and both cause real problems. A CNAME cannot coexist with other records on the same name, so adding one where a TXT or MX record already lives produces a conflict the provider may or may not warn about. And the root of a domain generally cannot be a CNAME at all, which is why pointing an apex domain at a host is its own separate problem with its own solutions.
Check what is published, not what is in the panel
| What you look at | What it tells you | Limitation |
|---|---|---|
| The DNS panel | What you intended | Not proof anything is being served |
| A public lookup tool | What resolvers currently answer | Cached, and varies by location |
| A query to the authoritative nameserver | The truth, now | Not what most visitors are seeing yet |
| Your own browser | Almost nothing | Caches aggressively at several layers |
The last row is the one that wastes the most time. A browser will happily show a stale result long after the record changed, so an operator concludes the change failed and edits it again — which restarts propagation and makes the situation worse. Check with a lookup rather than a reload.
The five causes, in the order to eliminate them
- Wrong nameservers. The records are being edited in a panel that is not authoritative for the domain. Everything else is irrelevant until this is right, and it is far more common than it sounds — a domain transferred years ago often still has an old panel someone keeps editing.
- A conflicting record. Another record on the same name, frequently one added automatically when the domain was registered.
- Trailing dots and doubled domains. A value entered as a full hostname where the panel appends the domain, producing a name with the domain in it twice.
- Propagation. Genuinely just waiting, governed by the TTL that was in force before the change rather than the one set now.
- A proxy in front. A record set to be proxied resolves to the proxy rather than the host, which is sometimes intended and sometimes the reason verification fails.
the full set a funnel host needs lists what should be present; this is how to establish what actually is.
TTL decides how long a mistake lasts
The time-to-live tells resolvers how long to cache an answer, and the value that governs a change is the one that was published before you made it. A record with a long TTL edited today can still be answering the old value tomorrow, entirely correctly.
The practical habit: before a planned change, lower the TTL and wait for the old one to expire, then make the change, then raise it again. That converts a day-long cutover into a minutes-long one. It requires planning ahead, which is why it is worth doing on any migration — moving pages into a website container and one funnel on several domains both involve exactly this kind of cutover.
Certificates depend on the record being right first
Certificate issuance usually validates by checking a DNS record or by retrieving something from the host the record points at. If the record is wrong, cached, or proxied in a way that interferes, issuance stalls — and the symptom is a certificate that has not issued rather than anything mentioning DNS. the not-secure warning in the browser is the visitor-facing version of the same thing.
The sequence that avoids the confusion: fix the record, confirm it resolves from an authoritative query, then trigger issuance. Repeatedly retrying issuance while the record is still wrong produces a series of failures that look like a platform problem.
Records that are not about the website
A domain carries records for several unrelated purposes, and editing one set can break another. Email authentication lives in TXT records — SPF, DKIM and DMARC covers SPF, DKIM and DMARC — and a well-meaning clean-up of “records we do not recognise” is a recurring cause of mail suddenly landing in spam. the workflow sender domain depends on those records being present and correct.
Before removing anything, establish what it is for. If nobody knows, leave it and find out; an unexplained record is not evidence of an unnecessary one.
A check worth running on a schedule
- Confirm which nameservers are authoritative for the domain.
- Query them directly for the records you expect, rather than trusting a panel.
- Compare against what a public resolver answers, to see propagation state.
- Check both the apex and the www host — choosing one canonical host only works if both resolve.
- Confirm the certificate is valid and not close to expiry.
- Check the mail records are intact, not only the web ones.
Record the expected values somewhere outside the DNS panel — a log kept outside the platform is enough — because the panel tells you what is there, not what should be. That document is also what makes handover when someone leaves survivable: DNS is the classic piece of knowledge that lives in one person’s head, and the day they leave is the day something needs changing. And keep an eye on what belongs in a sitemap and a page speed score after any domain change, since both are measured against a hostname that just moved.
Frequently Asked Questions
How do I check what a CNAME record actually resolves to?
Query the authoritative nameservers directly, and compare that against what a public resolver answers to see propagation state. Do not judge from your browser, which caches at several layers and will show a stale result long after the record changed.
Why is my correct CNAME not working?
Five usual causes, in order: the panel you edited is not authoritative for the domain, a conflicting record exists on the same name, the value has the domain in it twice, the old TTL has not expired, or a proxy sits in front and answers instead of the host.
Can I put a CNAME on the root of my domain?
Generally no. A CNAME cannot coexist with the other records a domain root must carry, which is why apex domains need a different approach. Providers offer various substitutes for this, and which one applies depends on your DNS host.
How long should I wait for a DNS change?
As long as the TTL that was published before you made the change, not the one you set with it. That is why lowering the TTL in advance, waiting for the old one to expire, then making the change turns a day-long cutover into a minutes-long one.
Why does my certificate keep failing to issue?
Usually because validation depends on the record being correct and resolving, and it is not yet. Fix the record, confirm it from an authoritative query, then trigger issuance. Retrying repeatedly while the record is still wrong produces failures that look like a platform fault.
Is it safe to delete DNS records I do not recognise?
No. Domains carry records for email authentication, service verification and other purposes unrelated to the website, and removing them is a recurring cause of mail landing in spam. Establish what a record is for before removing it.
Should I edit a record again if it does not seem to have taken effect?
Not immediately. Re-editing restarts propagation and makes the wait longer, and the most common reason a change looks ineffective is a cached answer rather than a failed save. Verify with a lookup against the authoritative servers before touching it again.
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.