---
title: Custom domain not connecting? How to check a CNAME record with the CNAME Lookup
description: Your CDN, Shopify, Zendesk or status page says the custom domain isn't configured, even though you added the CNAME. To check a CNAME record, look up the hostname and confirm it aliases to the exact target the vendor gave you. Here's how to do it with the free CNAME Lookup, a real CDN example, what the result can and can't show, and the dig commands that reveal every hop of the chain.
canonical: https://watchfor.io/blog/how-to-check-a-cname-record
---

# Custom domain not connecting? How to check a CNAME record with the CNAME Lookup

2026-10-04 · WatchFor Team · Guides · guides, dns, networking

Your CDN, Shopify, Zendesk or status page says the custom domain isn't configured, even though you added the CNAME. To check a CNAME record, look up the hostname and confirm it aliases to the exact target the vendor gave you. Here's how to do it with the free CNAME Lookup, a real CDN example, what the result can and can't show, and the dig commands that reveal every hop of the chain.

To check a CNAME record, look up the hostname you configured (such as
`www.example.com` or `shop.example.com`) and compare the target it aliases to
with the exact hostname your vendor gave you. They must match character for
character. If the lookup shows a different target, or the hostname has no
CNAME at all, the vendor can't verify the domain or issue its certificate.

The free [CNAME Lookup](/cname-lookup) shows where a hostname is aliased,
from a real WatchFor location, in under a second. No signup.

## What this tool answers

*Where does this hostname point?* Reach for it when a CDN, a SaaS platform
(Shopify, Zendesk, HubSpot, Webflow) or a status page provider says your
custom domain "isn't connected", when a subdomain loads someone else's error
page, or when you inherit a zone and need to know which services its
subdomains depend on.

## A real example

### Checking a CNAME record for a domain behind a CDN

The typical setup: the CDN or SaaS vendor tells you to add
`www CNAME <something>.vendor.net`. You add it, the vendor's dashboard keeps
saying "pending", and you want to know whether DNS is the problem. We
checked a large site that serves its `www` hostname through a CDN this way.

In the [CNAME Lookup](/cname-lookup) we typed `www.mozilla.org`, kept the
resolver on **Auto** and pressed **Run lookup**:

![The CNAME Lookup for www.mozilla.org from Europe / Lithuania: NOERROR, 1 record in 197 ms, value www-mozilla.fastly-edge.com.](/blog/how-to-check-a-cname-record-result.webp)

The lookup returned `NOERROR` with **one record**:
`www-mozilla.fastly-edge.com.` That's a Fastly edge hostname; the response
from `https://www.mozilla.org` carries Fastly's `x-served-by: cache-ber…`
header, so the CDN really is serving it.

The command-line check below shows the full chain:
`www.mozilla.org → www-mozilla.fastly-edge.com → four 151.101.x.19 addresses`,
with a TTL of 60 seconds on the alias. A short TTL is a deliberate choice: it
lets Mozilla repoint `www` to another provider within a minute.

**The answer:** `www.mozilla.org` is aliased to the CDN hostname, and the
alias resolves to working addresses. For your own domain, compare the value
in the result with the target in the vendor's setup screen. If they match,
DNS is done and the "pending" is on the vendor's side (it may need a re-check
or time to issue the certificate). If they don't, fix the record.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Resolve time** | How long the lookup took: green under 50 ms, amber under 200 ms, red above. |
| **NOERROR** (green) | The name resolved. |
| **NXDOMAIN** (amber) | The name doesn't exist, often a typo, or the record was created under a doubled name (see Tips). |
| **Value** | The canonical name: where the alias chain ends. The trailing dot just means "fully qualified". |
| **1 record** | A CNAME is always a single record; a name can't have two. |
| **Location** | Signed out, the query runs from the WatchFor location nearest you. |

Two things the result doesn't show. It reports the **final** name of the
chain, so when an alias points at another alias, the hops in between and
their TTLs are only visible with `dig`. And when a name has **no CNAME** but
resolves to addresses, the tool returns the name itself as the value (a
lookup of `mozilla.org` returned `mozilla.org.`), so a result equal to what
you typed means "not an alias".

## More ways to use it

- **Before a vendor checks your domain.** Confirm the alias is live before
  you press "Verify" in Shopify, Zendesk or your status page provider, so a
  failed check doesn't get cached.
- **Finding dangling CNAMEs.** Look up the subdomains in your zone that point
  at third-party services. One that aliases to a deleted Heroku app, S3
  bucket or GitHub Pages site can be claimed by someone else (subdomain
  takeover).
- **Auditing which vendors a zone relies on.** CNAME targets name the
  provider: `cloudfront.net`, `fastly-edge.com`, `herokudns.com` and so on.
- **After switching CDNs.** Confirm `www` now aliases to the new provider and
  not the old one.

## Tips and gotchas

- **No CNAME at the apex.** A CNAME can't coexist with other records on the
  same name (RFC 1034), and the apex always has SOA and NS records. For
  `example.com` itself use A/AAAA records, or your DNS provider's ALIAS or
  CNAME flattening.
- **A CNAME name can't hold other records.** You can't put a TXT verification
  token or an MX on a name that is a CNAME. Put those on a different name.
- **Doubled zone name.** Many DNS editors append the zone to the host field.
  Typing `www.example.com` there creates `www.example.com.example.com`; type
  `www`.
- **Proxied records hide the CNAME.** With Cloudflare's orange cloud, public
  lookups return Cloudflare's addresses, not your CNAME target. That's normal
  for proxied records; some vendors need the record set to "DNS only".
- **A correct CNAME isn't a working site.** The target must resolve and
  answer for your hostname; check the addresses with the
  [A Record Lookup](/a-record-lookup) and the certificate with the
  [SSL checker](/ssl-checker).

## Check it from the command line too

`dig` with an address query shows every hop of the chain, with each TTL:

```bash
dig +noall +answer www.mozilla.org A @1.1.1.1
```

```text
www.mozilla.org.	36	IN	CNAME	www-mozilla.fastly-edge.com.
www-mozilla.fastly-edge.com. 36	IN	A	151.101.195.19
www-mozilla.fastly-edge.com. 36	IN	A	151.101.3.19
www-mozilla.fastly-edge.com. 36	IN	A	151.101.67.19
www-mozilla.fastly-edge.com. 36	IN	A	151.101.131.19
```

36 seconds were left on Cloudflare's cached copy; asking for the CNAME alone
right before showed 60. The apex, as expected, has no CNAME (no output):

```bash
dig +noall +answer CNAME mozilla.org @1.1.1.1
```

To confirm the CDN serves the site, look at the response headers:

```bash
curl -sI https://www.mozilla.org/ | grep -iE "^HTTP|^via|^x-served-by"
```

```text
HTTP/2 200
via: 1.1 google, 1.1 varnish, 1.1 varnish
x-served-by: cache-ber1080030-BER, cache-ber1080030-BER, cache-ber1080055-BER
```

## Keep watching it

A CNAME that silently changes, or starts pointing at a target that no longer
exists, breaks a subdomain or opens it to takeover. A
[DNS monitor](/dns-monitoring) on the **CNAME** record type re-checks it
from several locations on a schedule, and with the **Expected DNS Records**
rule set to the vendor's target it opens an incident when the canonical name
stops matching. The [DNS hijacking guide](/blog/detect-dns-hijacking) shows a
full setup.

## FAQ

**How do I check if a CNAME record is set up correctly?**
Look up the hostname with a CNAME lookup or `dig CNAME www.example.com` and
compare the result with the target your provider gave you. If they match and
the target resolves to addresses, DNS is set up; anything still failing is on
the provider's side.

**How long does a CNAME take to propagate?**
A new CNAME is live at your DNS host immediately. Resolvers that had cached
the old answer (or a "doesn't exist" answer) keep it until that TTL expires,
usually minutes to an hour.

**What's the difference between a CNAME and an A record?**
An A record maps a name to an IPv4 address; a CNAME maps a name to another
name, whose addresses are then used. CNAMEs let a vendor change addresses
without you editing DNS. More in
[DNS record types explained](/blog/dns-record-types-explained).

---

Canonical page: https://watchfor.io/blog/how-to-check-a-cname-record · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt