Troubleshooting guide
White label domain not working: find the cause and fix it
A white label domain that will not load, verify or show HTTPS almost always fails for one of a few reasons: the record is missing or wrong, another record shares the name, a proxy is in the way, the certificate cannot be issued, or an old answer is still cached. Run the six checks below in order. Each is one command, and each tells you which fix to use.
How to use the commands. Replace app.example.com with your hostname, example.com with your domain and target.vendor.example with the target your vendor gave you. They use dig, curl and openssl on macOS or Linux. On some Linux systems dig comes in the dnsutils or bind-utils package.
The addresses and names here are reserved for examples, so none of them point at a real service.
Run these six checks in order
Each check isolates one layer, from the DNS record up to the certificate. Stop at the first one that fails and use its fix. Skipping ahead wastes time, because a failure at a lower layer causes confusing errors above it.
# 1. Where does the name point?
dig +short CNAME app.example.com
# 2. Is anything else at the same name?
dig +short A app.example.com
dig +short AAAA app.example.com
dig +short TXT app.example.com
# 3. Which nameservers are authoritative, and what do they say?
dig +short NS example.com
dig +short CNAME app.example.com @ns1.dnshost.example
# 4. Does it answer on HTTP and on HTTPS?
curl -sI http://app.example.com | head -n 5
curl -sI https://app.example.com | head -n 5
# 5. Which certificate does it present?
echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates
echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Alternative Name"
# 6. Do CAA records limit who may issue?
dig +short CAA app.example.com
dig +short CAA example.comThe -servername option matters in check 5. A server picks its certificate by the name you ask for, so without it you may see a default certificate for a different site.
| Check | A good result | A bad result means |
|---|---|---|
| 1. Name | One line: the vendor's target, ending in a dot. | Empty: the record is missing, misspelled or sits at a DNS host nobody queries. A different target: an old record is still in place. |
| 2. Other records | Nothing at all for A and AAAA, and no TXT at this name. | Any answer: another record shares the name with the CNAME. See CNAME conflicts. |
| 3. Authority | The nameservers belong to the DNS host where you edit, and their answer matches the public one. | Different nameservers: you edited a zone that is not live. A different answer from the authority: wait for caches, or see caching. |
| 4. Web | A status line such as 200, or 301 to an HTTPS address. | A timeout or refusal: the name points at the wrong place, or a proxy or firewall is in the way. A certificate error from curl: go to check 5. |
| 5. Certificate | The subject or alternative names include your hostname, the issuer is a public authority, and today is inside the dates. | No output: nothing answered on port 443. A different name: you reached another server, or issuance has not happened. Expired: renewal failed. |
| 6. CAA | No output (any authority may issue) or a record that lists your vendor's authority. | A record that leaves out the vendor's authority: issuance is refused. See certificates. |
Symptom by symptom
| What you see | Likely cause | What to do |
|---|---|---|
| The site cannot be reached, or the browser says DNS_PROBE_FINISHED_NXDOMAIN | The record is missing or misspelled, or it was added at a DNS host that is not authoritative for the domain. | Run checks 1 and 3. Add the record at the DNS host that the domain's nameservers point to. |
The record is in the dashboard but dig shows nothing | The registrar's nameservers point elsewhere, or the name picked up a doubled suffix such as app.example.com.example.com. | Compare dig NS with the host you edited. Type only the host part, app, in the name field. |
| The DNS host will not save the CNAME | Another record exists at that name, or the name is the root domain. | See CNAME conflicts and the root domain. |
| The browser warns that the name does not match the certificate | The server answering is not the vendor's, the hostname is not saved at the vendor yet, or issuance has not finished. | Run checks 4 and 5. Confirm the hostname is saved in the vendor's settings, then allow time for issuance. |
| The certificate stays pending | Port 80 does not reach the vendor, a proxy answers instead, a stale AAAA record points elsewhere, or a CAA record blocks the issuer. | See certificates that will not issue. |
| ERR_TOO_MANY_REDIRECTS | A proxy and the origin disagree about HTTP and HTTPS. | See proxies and redirect loops. |
| It works on your network but not for a client | Different resolvers hold different answers: an old record, a cached missing-name answer or an IPv6 address. | Query two public resolvers and compare. See caching and waiting. |
| SERVFAIL, or a site that fails only on some resolvers | A DNSSEC problem, often after moving DNS hosts. | See SERVFAIL and DNSSEC. |
| The old site still loads | A leftover A record, a wildcard record answering for the name, or an old cache. | Run check 2 and list the zone for a wildcard such as *.example.com. A wildcard answers only for names that have no record of their own. |
| The browser gives no Proceed button on the warning | The browser stored an HTTPS-only rule (HSTS) for the domain during an earlier setup. | Fix the certificate. The browser will not let visitors click through while that rule is stored. |
| The vendor says the domain is verified, but the page shows a generic error | The hostname reaches the vendor but is not mapped to an account, site or origin there. | Assign the domain to the right site or brand in the vendor's settings. The error code varies by vendor. |
| It worked for months, then stopped | A record was changed or deleted, DNS moved hosts, the certificate failed to renew or the domain expired. | Run all six checks, then check the expiry date with whois example.com. |
CNAME conflicts and the root domain
A name that has a CNAME cannot hold any other data (RFC 1034 section 3.6.2 and RFC 2181 section 10.1). The most common mistake is an old A record left next to the new CNAME:
app.example.com. 300 IN A 203.0.113.10
app.example.com. 300 IN CNAME target.vendor.example.Resolvers may return either record, so some visitors reach the old server and the certificate check can land on the wrong one. Delete the A record, and any AAAA or TXT record, at that name, and keep only the CNAME. Some DNS hosts refuse to save a CNAME next to another record. Others save it and leave you with this problem.
The root domain
The root of a domain (example.com) always carries SOA and NS records, so a standard CNAME cannot sit there. Your options:
- Use a subdomain such as
wwworappinstead. - Use an ALIAS, ANAME or CNAME flattening record if your DNS host offers one. The name differs by provider, and the host resolves the target for you.
- Use A records that point at the addresses your vendor publishes, if it publishes stable ones.
The doubled name
Many DNS panels add the domain for you. Typing app.example.com in the name field can create app.example.com.example.com. Check with dig +short CNAME app.example.com.example.com. Enter only app, or follow your host's rule for fully qualified names, which end in a dot.
Proxies and redirect loops
Some DNS hosts also proxy traffic. Cloudflare's orange cloud is the common example. When the proxy is on, visitors and certificate checks reach the proxy's addresses, not the vendor's. A vendor that issues the certificate itself generally needs the record set to DNS only (the grey cloud), and HighLevel's whitelabel article says so. Switch the record to DNS only, wait a few minutes and run checks 4 and 5 again.
A proxy can also cause a redirect loop. If the proxy talks to the origin over plain HTTP while the origin redirects every HTTP request to HTTPS, the browser bounces between the two and reports ERR_TOO_MANY_REDIRECTS. With Cloudflare, that is the Flexible mode. Set the hostname to DNS only, which is what vendors that issue their own certificate usually ask for. If you must keep the proxy, use Full (strict) mode and make sure the origin presents a valid certificate for the name. To see a loop, follow the redirects and watch the location header repeat:
curl -sIL --max-redirs 5 https://app.example.com | grep -i '^location'Certificates that will not issue
Before a certificate authority issues a certificate, it must confirm that you control the hostname. The HTTP-01 check from Let's Encrypt requests a token from your hostname on port 80, so the name must already resolve to the vendor and port 80 must reach it. Issuance also checks CAA records. These are the causes, most common first:
- DNS does not point at the vendor yet. Run check 1 and wait for the answer to change.
- A proxy answers instead. Set the record to DNS only, as above.
- A stale AAAA record. A leftover IPv6 address can send the check, and your visitors, to an old server. Remove AAAA records that do not belong to the vendor.
- Something else answers on port 80. A forwarding or parking page at the registrar can intercept the request when the name points to it.
- A CAA record forbids the issuer. See the next part.
CAA records
CAA records (RFC 8659) say which certificate authorities may issue for a name. The lookup starts at the hostname and climbs to its parent domains until it finds a CAA record set, so a record on example.com also governs app.example.com. No CAA record means any authority may issue. A record that leaves out your vendor's authority means issuance is refused. To allow Let's Encrypt, the value is letsencrypt.org (its CAA guide):
example.com. 3600 IN CAA 0 issue "letsencrypt.org"Use the authority your vendor names. If its help article does not say, ask. Fix the cause first, then retry once. Certificate authorities limit repeated failed validations (see the Let's Encrypt rate limits), so pressing retry again and again can lock you out for a while.
SERVFAIL and DNSSEC
DNSSEC lets resolvers verify DNS answers with signatures (RFC 4033). A DS record, published through your registrar, must match the signing keys at the DNS host. If you change DNS hosts and leave the old DS record in place, validating resolvers reject the answers for the domain and return SERVFAIL, while resolvers that do not validate keep working. That makes the failure look random. To confirm, ask a validating resolver, then ask again with checking disabled:
dig @1.1.1.1 app.example.com A # status: SERVFAIL
dig @1.1.1.1 +cd app.example.com A # +cd skips validation; an answer here points to DNSSEC- Already broken: remove the DS record at the registrar, or replace it with the one your current DNS host gives you. The fix shows up as cached answers expire.
- Before a move: remove the DS record first, wait for its TTL to pass, then change the nameservers, and add a new DS record only after signing is set up at the new host.
Caching, propagation and how long to wait
A DNS change does not travel across the internet. It is visible at your DNS host at once, and every resolver that cached the old answer keeps it until the TTL runs out. Propagation is mostly waiting for caches to expire.
| What changed | How long until everyone sees it | How to check |
|---|---|---|
| A new record for a name nobody looked up before | The next lookup finds it. | Ask the authoritative nameserver, then two public resolvers. |
| A record you edited | Up to the old record's TTL. | The TTL in the dig answer counts down. |
| A name someone looked up before the record existed | Until the cached "no such record" answer expires. It lasts for the lower of the SOA record's own TTL and its minimum field (RFC 2308). | dig SOA example.com, then read the TTL and the last number. |
| Nameservers changed at the registrar | Often up to two days, because the parent zone caches the old delegation. | dig NS example.com against several resolvers. |
| The certificate | Starts after DNS is right. Most vendors retry on their own. | Check 5. |
To tell a cache from a mistake, compare the authority with two public resolvers. If they differ, you are waiting on a cache:
dig +short CNAME app.example.com @ns1.dnshost.example
dig +short CNAME app.example.com @1.1.1.1
dig +short CNAME app.example.com @8.8.8.8Before a planned change, lower the record's TTL to 300 seconds and wait at least one full old TTL (a day ahead is common) so caches pick up the short value. Make the change, then raise the TTL again once everything works.
Keep it working
- One record per name. Keep a list of which vendor owns which hostname, so nobody adds a second record by habit.
- Keep TTLs low during setup. Raise them afterward.
- Track expiry. Put the domain's renewal date and the certificate's renewal in a calendar, or use a monitor that watches both.
- Re-run the six checks after any DNS host change. Moves are when records get lost.
- Watch for drift. A good monitor confirms a change at the zone's own nameservers before it counts, so one slow lookup does not raise a false alarm.
The free Domain Health Check runs read-only tests on public DNS and TLS for any domain, without a signup. If you build software and your customers bring their own domains, CustomDomain™ does this work for you: it guides the customer through the records, checks every live domain once an hour, confirms drift at the zone's own nameservers, and sends webhooks at 14, 7 and 3 days before an unrenewed certificate expires. The details are in the monitoring docs.
Sources and further reading
- RFC 1034, Domain names, concepts and facilities (section 3.6.2)
- RFC 2181, Clarifications to the DNS specification (section 10.1)
- RFC 2308, Negative caching of DNS queries
- RFC 8659, DNS Certification Authority Authorization (CAA) resource record
- RFC 4033, DNS Security Introduction and Requirements
- Let's Encrypt, challenge types
- Let's Encrypt, CAA records
- Let's Encrypt, rate limits
Frequently asked questions
Why is my white label domain not working?
Usually one of five things: the record is missing or sits at the wrong DNS host, another record shares the name with the CNAME, a proxy is in the way, the certificate cannot be issued, or an old answer is cached. The six checks above find which one in a few minutes.
How long does a white label domain take to start working?
Often minutes. It can take a day or two when an old answer is cached or nameservers changed, and each vendor quotes its own limit (HighLevel's articles, for example, say up to 30 minutes for one domain type and up to 48 hours for another; see the HighLevel guide). Rather than waiting blindly, compare the authoritative answer with a public resolver: if they match, DNS is done and the remaining wait is certificate issuance.
Why does my domain show a certificate warning?
The server that answered does not hold a certificate for your hostname. Either the name does not point at the vendor yet, the hostname is not saved in the vendor's settings, issuance has not finished, or a proxy is answering. Run checks 4 and 5.
Why does a proxy such as Cloudflare break my white label domain?
With the proxy on, visitors and certificate checks reach the proxy's addresses instead of the vendor's. Set the record to DNS only. If you want to keep the proxy, make sure its mode matches the origin, because Flexible mode with an origin that forces HTTPS causes a redirect loop.
Can I put a CNAME on my root domain?
Not a standard one. The root always carries SOA and NS records, and a name with a CNAME cannot hold other data. Use a subdomain, or an ALIAS, ANAME or CNAME flattening record if your DNS host supports it, or A records to the vendor's addresses.
What does ERR_TOO_MANY_REDIRECTS mean on a custom domain?
The browser followed redirects in a circle. With a proxy, it typically means the proxy reaches the origin over HTTP while the origin redirects HTTP to HTTPS. Use a full, strict mode between the proxy and the origin, or turn the proxy off.
Why does the domain work for me but not for my client?
Their resolver holds a different answer from yours: an old record, a cached missing-name answer, a stale IPv6 address or a DNSSEC failure that only validating resolvers see. Query the authoritative nameserver and two public resolvers and compare.
What is a CAA record, and can it block my certificate?
A CAA record lists the certificate authorities allowed to issue for a name. If one exists and leaves out your vendor's authority, issuance is refused. No CAA record means any authority may issue. Add the vendor's authority, or remove the restriction.
How do I fix SERVFAIL on my domain?
If a validating resolver returns SERVFAIL and the same query with checking disabled works, the cause is DNSSEC. Remove the stale DS record at the registrar, or replace it with the one your current DNS host gives you.
How can I check whether my domain is set up correctly?
Run the six checks in this guide, or paste the domain into the free Domain Health Check, which tests DNS resolution, CNAME and root domain handling, HTTPS, the certificate, its renewal runway and the HTTP to HTTPS redirect.