- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
One zone doing several unrelated jobs, configured by different people at different times — which is why a change for one reliably breaks another.
DNS records for a funnel domain: the full set, and what each one is for
A domain used for funnels is doing several unrelated jobs at once. It serves pages, it proves ownership to a handful of platforms, it usually carries the client’s email, and it often authorises outbound messaging from a subdomain nobody looks at. Those jobs are configured in the same zone file, by different people, at different times — which is why a change made for one of them so reliably breaks another.
What follows is an inventory: the records a funnel domain typically holds, which job each belongs to, and who is likely to have created it. Knowing that map is most of what prevents an afternoon of guessing.
The inventory
| Record | Job it belongs to | Typical owner |
|---|---|---|
| A or AAAA at the root | Serving the site at the bare domain | Whoever pointed the domain at the page host |
| CNAME on www or a subdomain | Serving the site at that name | The same person, usually at the same time |
| CNAME on a tracking or link subdomain | Branded links, click tracking | Whoever set up campaigns |
| CNAME or TXT on a sending subdomain | Authorising outbound email from your platform | Whoever configured campaigns or automation |
| MX at the root | Delivering the client’s incoming mail | The client’s IT provider, often years ago |
| TXT: SPF, DKIM, DMARC | Proving mail is legitimately from this domain | Split between the mail provider and the platform |
| TXT: verification strings | Proving ownership to search, ads, messaging | Whoever set up each of those, separately |
| CAA | Restricting which authorities may issue certificates | Rarely anyone — but it blocks issuance when present |
The last row is the one nobody expects. A CAA record left over from a previous host restricts who may issue a certificate for the name, and a platform not on that list simply cannot obtain one. It is an uncommon cause of a stalled certificate issuance and an invisible one unless you look for it.
Serving the pages
Pointing a name at the page host is the visible part of the job and the part most guides cover. The apex is the awkward case, because the record type platforms prefer is one the root cannot normally hold — the reasoning, and the three workable alternatives, are in why the apex cannot take a CNAME.
Subdomains are simpler and worth using deliberately. A separate name for funnels, for a members area or for a client portal keeps each pointed at whatever serves it, and means a change to one does not affect the others. It also makes the certificate situation clearer: each name needs one, and a certificate covering the root but not www produces a not-secure warning for half your visitors.
The records that have nothing to do with the pages
This is where most damage happens, because the person changing DNS for a launch has no reason to think about mail.
- MX. Removing or replacing these stops the client receiving email. It is usually noticed a day later by someone who does not connect the two events.
- SPF. There should be exactly one SPF record, listing every service permitted to send as the domain. Adding a second does not extend the first; it invalidates both. The full picture is in SPF, DKIM and DMARC.
- DKIM and DMARC. Platform-specific and easy to leave behind during a migration, at which point mail still sends and stops being trusted.
- Sending subdomains. Outbound campaigns are usually authorised on a subdomain of their own, which is why the workflow sender domain can break while the website is entirely fine.
- Verification TXT records. Each platform’s ownership proof looks like meaningless text and is deleted during tidy-ups. Their absence surfaces only at the next re-verification — including the ones supporting business messaging registration.
Before editing anything, export the zone. It takes a minute and converts a mistake into an undo.
Order of work for a new funnel domain
Do it in this sequence and most of the usual problems do not arise:
- Record what is already there. Export, then read the MX and TXT records specifically and find out what they are for before assuming anything is unused.
- Lower the TTL a day ahead on anything you intend to change, so the change propagates quickly when you make it.
- Add the page records, root and www together, and wait for the certificate rather than concluding it has failed.
- Add sending and tracking subdomains as separate names, and verify each in the platform that requested it.
- Leave mail alone unless the mail itself is being migrated.
- Re-check the verification records afterwards, since a tidy-up during the work is when they disappear.
Agency-specific hazards
Running many client domains, the recurring problems are organisational rather than technical. Keep a record of who controls each registrar and each DNS zone, because the usual delay in a launch is finding the person with the login. Where you resell under your own brand, a name that does not resolve is your problem regardless of whose zone it is, which is the responsibility described in a white-label arrangement.
After any domain change, re-check the things that quietly depend on the hostname: absolute references in code in the page header, the absolute image URL behind the Open Graph image on a page, and booking links, since a calendar clients can book into is often shared as a bare URL 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 verify from outside your own network. Local resolvers and browsers cache aggressively enough to show you a stale answer long after the rest of the world has moved on, and “it works for me” is the least useful evidence available at this stage.
Frequently Asked Questions
What records does a funnel domain actually need?
An A or CNAME pointing the serving names at the page host, plus whatever the domain already carries for other jobs: MX for mail, SPF, DKIM and DMARC for mail authentication, verification TXT records for each platform, and CNAMEs for any tracking or sending subdomain.
Why did the certificate fail even though the record is correct?
One uncommon cause is a CAA record left over from a previous host, which restricts which authorities may issue a certificate for the name. A platform not on that list simply cannot obtain one, and nothing about the failure points at the CAA record.
Can a domain have more than one SPF record?
No. There should be exactly one, listing every service permitted to send as the domain. Adding a second does not extend the first — it invalidates both, and mail continues to send while ceasing to be trusted.
What is the safe order of work when pointing a domain at funnels?
Export the existing zone, read the MX and TXT records and establish what they are for, lower the TTL a day ahead on anything you will change, add the page records for root and www together, add sending and tracking subdomains separately, and leave mail alone unless mail is being migrated.
Why does outbound email break when the website is fine?
Because outbound campaigns are usually authorised on a subdomain of their own, separate from the names serving pages. That subdomain’s records can be removed or left behind during a migration without any visible effect on the site.
Why does the change appear to work for some people and not others?
Caching. Resolvers keep the previous answer until its TTL expires, and local resolvers and browsers are especially aggressive. Verify from outside your own network — ‘it works for me’ is the least useful evidence at this stage.
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.