CNAME Lookup

Check the CNAME record for any hostname and see exactly what it aliases to. Enter a name and this tool queries live DNS and shows its canonical target with the TTL — confirming whether a subdomain like www or app points at a CDN, a SaaS platform or a load balancer. CNAME misconfiguration is a frequent cause of "verification pending" and broken subdomains, and this is the quick way to confirm the alias is correct.

How to use the CNAME Lookup

Enter the exact hostname to check — usually a subdomain such as www.example.com or shop.example.com — and press Look up CNAME. The tool reports:

• The alias target the name points to, if a CNAME exists, with its TTL.
• A clear note when the name has its own address records (A/AAAA) instead of a CNAME — correct for a zone apex.
• A note when no CNAME is published at the name.

Enter the specific subdomain, not the bare domain: CNAMEs live on subdomains, and the apex is not allowed to be a plain CNAME. So www.example.com may be a CNAME while example.com is not.

What a CNAME record is

A CNAME (Canonical Name) record makes one name an alias for another. Instead of holding an IP address itself, the name says "I am really this other name — go look there." The resolver then follows the CNAME to the target and reads the target's address records. It is how you point a subdomain at a service whose IP you do not control and which may change at any time.

CNAMEs are everywhere in modern hosting:

• CDNs — www.example.com CNAMEs to something like example.com.cdn.cloudflare.net, so the CDN can change the underlying IPs freely.
• SaaS platforms — pointing shop.example.com at a Shopify, Webflow or GitHub Pages hostname is done with a CNAME the provider gives you.
• Domain verification — many services ask you to add a CNAME from a unique name to one of theirs to prove control or activate a feature.

Two rules trip people up. First, a CNAME cannot coexist with any other record at the same name — no A, no MX, no TXT alongside it — because the alias is supposed to stand in for the whole name. Second, the zone apex (the bare example.com) cannot be a plain CNAME, since the apex must carry SOA and NS records that a CNAME would forbid. That is why providers offer apex workarounds like ALIAS, ANAME or Cloudflare's CNAME flattening, which behave like a CNAME at the apex but return address records directly. When you check a name here and see it has A records rather than a CNAME, that is expected and correct for an apex.

Common use cases

• Confirming a SaaS or CDN setup — verify a subdomain CNAMEs to the exact hostname the provider specified.
• Debugging domain verification — check that a required CNAME is present and points at the right target.
• Tracing an alias — see what a subdomain actually resolves to before looking up the target's IP.
• Catching apex mistakes — confirm you are not trying to CNAME a bare domain, which is invalid.
• Spotting conflicts — a CNAME that should be there but is being overridden by other records.

Common CNAME mistakes

• CNAME at the apex. Pointing the bare domain at a host with a plain CNAME is invalid. Use your provider's ALIAS / ANAME / CNAME-flattening feature instead, or an A record.
• CNAME plus other records. A CNAME must be the only record at its name. If you also have a TXT or A there, DNS is in an invalid state and resolvers may ignore one of them.
• Pointing at the wrong target. SaaS onboarding fails when the CNAME target has a typo or trailing-dot issue. Confirm it matches the provider's value exactly.
• Long CNAME chains. A CNAME pointing at another CNAME pointing at another adds lookups and latency. Keep the chain short.
• Stale alias after a move. The old target lingers in caches for the TTL. Lower the TTL before changing the alias, then re-check here.

Once you have the target, look up its address with the A Record Lookup, or inspect every record type for the name with the DNS Lookup.