Verifying means your host cannot see the DNS record it asked you to add. The record usually exists. It is just not visible in the form the host needs: proxied behind Cloudflare's orange cloud, flattened into an address record, delegated away by a stray NS record, or blocked from certificate issuance by a CAA record. Query it with dig before you change anything.
This is the failure page under custom domains and subdomains for a support site, which covers the setup itself. It is a common enough stall that Cloudflare's own community forum carries a run of threads with the same title shape, the newest posted days before this was written.
What is the host actually checking?
Two separate things, which fail differently.
First, ownership. The host asked you to publish a specific record, almost always a CNAME pointing your subdomain at a hostname they control. They look that record up from their own resolvers. If they get anything other than the exact target they issued, verification does not advance.
Second, the certificate. Once ownership passes, a certificate authority has to issue for that hostname, a separate check with its own reasons to fail. Most dashboards collapse both into one spinner labelled Verifying, so the word tells you nothing about which half is stuck.
The distinction matters because the fixes have nothing in common. An ownership failure is a DNS visibility problem. A certificate failure is usually a CAA record or a rate limit, and that has its own post.
How do you see what your host sees?
Your browser is the worst instrument here: it caches, and your machine may be using a resolver holding a stale answer. Query public resolvers directly instead.
dig +short CNAME support.example.com @1.1.1.1
dig +short CNAME support.example.com @8.8.8.8Both should print the exact target your host gave you, with a trailing dot. If one prints an IP address instead of a hostname, something is flattening or proxying the record. If one prints nothing and the other prints the target, you are watching propagation and the answer is to wait.
Then check the two records that quietly override everything else:
dig +short NS support.example.com @1.1.1.1
dig +short CAA example.com @1.1.1.1An NS record on the subdomain hands that whole name to a different DNS provider, so the CNAME in your main panel is never consulted. A CAA record on the registered domain restricts which certificate authorities may issue for it, and if your host's authority is not listed, no certificate will ever appear however correct the CNAME is.
Why does Cloudflare's orange cloud break this?
Because a proxied record does not answer with your target. It answers with Cloudflare's own addresses, which is the entire point of the proxy, and your host's ownership check sees an unrelated IP rather than the hostname it issued.
Cloudflare documents four distinct causes of exactly this on its own verification troubleshooting page: the record is set to Proxied, zone-wide CNAME flattening for all records is switched on, flattening is set on that one record, or an NS record has made another provider authoritative for the subdomain.
Two of the hosted rivals in this category publish the same instruction in their own help centres, which is a fair signal of how often it comes up. Sleekplan tells Cloudflare users the record "should be grey-clouded (DNS only), not orange-clouded (proxied)" and that flattening should be set to flatten at the apex rather than for all records. Frill.co's custom-domain article warns that propagation can take up to 48 hours and re-checks verification every 20 seconds.
There is one important exception. If your support site is hosted on Cloudflare Pages, the record does need to be proxied, because Cloudflare is serving the certificate itself, and its own documentation is blunt about the prerequisite:
Cloudflare can only serve an SSL/TLS certificate for a DNS record when you set the record's proxy status to Proxied.
Cloudflare, Universal SSL limitations
So the rule is not "always grey-cloud it". The rule is: grey-cloud it when an outside host is issuing the certificate, and proxy it when Cloudflare is.
The fix, in order
1. Confirm the exact target string from your host's dashboard, then compare it character by character with what dig returns. A missing trailing segment is the single most common cause and is invisible at a glance.
2. If your DNS is on Cloudflare and the certificate is issued by an outside host, set the record's proxy status to DNS only.
3. Open your Cloudflare zone's DNS settings and turn off CNAME flattening for all records, leaving it at the apex only. Then check the Flatten toggle on the record itself.
4. Delete any NS record sitting on the same subdomain, unless you deliberately delegated it.
5. If a CAA record exists, add the authorities your host needs. For a site on Cloudflare Pages, Cloudflare publishes the exact values, letsencrypt.org, pki.goog; cansignhttpexchanges=yes and ssl.com, with matching issuewild entries.
6. Press the re-check button in your host's dashboard rather than waiting for its own timer.
One payment, no subscription, unlimited products.
How do you know it worked?
The dashboard flipping to Active is weak evidence, because some hosts mark a domain active before the certificate is in place. Check the certificate itself:
openssl s_client -connect support.example.com:443 \
-servername support.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesYou want the subject to name your hostname, the issuer to be a public authority, and the dates to bracket today. Then confirm the page is genuinely being served and not redirected somewhere unexpected:
curl -sSI https://support.example.com | head -n 3If that returns a 522, the record resolves but no origin answered. On Cloudflare Pages, the documented cause is adding the CNAME by hand without registering the domain in the Pages dashboard first.
Same spinner, different cause
| Symptom | Likely cause | Where to look |
|---|---|---|
dig returns nothing anywhere | Record not saved, or saved on the wrong zone | Your DNS panel, and the zone the domain actually uses |
dig returns an IP, not a hostname | Proxied record, or CNAME flattening | Cloudflare proxy status and flattening settings |
| Record correct, certificate never appears | CAA record excludes the authority | dig CAA on the registered domain |
Works for support.example.com, fails for a deeper name | Universal SSL covers the root and first-level subdomains only | Use a first-level subdomain, or buy per-hostname coverage |
| Verified once, then went inactive | DNS was pointed elsewhere and back again | The host's own known-issues page |
| Vendor shows a "cross-user banned" error | The hostname is already claimed in the provider's system | The vendor's own error documentation, for example Featurebase's |
Does this apply if you are running Docket?
Yes, and on day one. Docket is a static site in your own repository, deployed to whichever host you prefer, so getting it onto support.yourdomain.com uses the same records, the same proxy setting and the same certificate check as everything above. The difference is afterwards: no vendor dashboard holds your domain, so the record points at your host and nothing sits in between. If you are choosing that host, Netlify, Vercel and Cloudflare Pages compared covers the tradeoffs, and security headers for a public feedback page covers what to send once the certificate is live.
One thing worth doing at the same time, whichever tool you are on: if you have single sign-on in front of anything, moving to a custom domain changes your callback URL. Frill.co's own documentation ends on that warning, and it is the direct cause of the error in redirect_uri_mismatch when you add Google or Microsoft sign-in.
Frequently asked questions
How long should verification actually take?
Minutes, not days, once the record is correct and visible. Sleekplan tells its customers a few minutes and up to an hour; Frill.co says 10 to 15 minutes and up to 48 hours in the worst case. If you are past an hour and dig is returning the right target from two public resolvers, the delay is not propagation and you should look at CAA and NS records instead.
Can I speed up propagation?
Not after the fact. Propagation is bounded by the TTL that was already on the record when resolvers last cached it, so the only useful move is preventative: lower the TTL to a few minutes a day before you plan a change, then raise it once things settle.
Should the record be proxied or not?
Not proxied when an outside host issues the certificate, because the proxy hides your target from their ownership check. Proxied when Cloudflare itself serves the certificate, because Cloudflare will not serve one for an unproxied record. Check which of the two situations you are in before touching the toggle.
Why does it work on the apex but not on a deeper subdomain?
On a Cloudflare full setup zone, Universal SSL covers the root domain and first-level subdomains only. A name like support.docs.example.com is not covered and will not serve a valid certificate without either an advanced certificate or a custom one. Moving to a first-level name is usually cheaper than solving it.
Do I need to remove the old record from the previous vendor?
Remove your own record pointing at them, yes, otherwise two live addresses serve the same content and split your search signal. Also remove the domain inside the old vendor's dashboard, since some providers keep the hostname claimed on their side, which is what produces the "already in use" class of error when you try to add it somewhere new.