CNAME Lookup — Check CNAME Records for Any Domain

#What this tool does

This CNAME lookup tool resolves the canonical name record for any domain or subdomain. Enter a hostname, and it queries public DNS servers to find the CNAME target — the domain that your hostname is aliased to. Lookups run server-side; your domain is not stored or logged.

#What is a CNAME record?

A CNAME (Canonical Name) record maps an alias domain to a canonical domain. When a DNS resolver encounters a CNAME, it follows the chain to the target and resolves that instead.

www.example.com  →  CNAME  →  example.com
blog.example.com →  CNAME  →  abc123.ghost.io

CNAME records are the standard way to point subdomains to external services — CDNs, hosted blogs, SaaS platforms, and load balancers.

#Common CNAME patterns

These are real-world CNAME configurations you will see in production:

CDN routing — cdn.example.com → d123456.cloudfront.net or example.com.cdn.cloudflare.net

SaaS custom domains — app.example.com → proxy.heroku.com or cname.vercel-dns.com

Hosted services — blog.example.com → ext-cust.squarespace.com or hosted.gitbook.io

Domain verification — _acme-challenge.example.com → verification CNAME for SSL certificate issuance

www redirect — www.github.com → github.com (one of the most common CNAME uses)

#CNAME vs A record

A records point a domain to an IP address. CNAME records point a domain to another domain name.

example.com     →  A      →  93.184.216.34     (direct IP)
www.example.com →  CNAME  →  example.com       (alias to another name)

Key difference: you cannot place a CNAME at the zone apex (the bare domain like example.com without a subdomain). The DNS specification (RFC 1034) forbids this because a CNAME at the apex would conflict with the SOA and NS records that must also exist there. If you need CNAME-like behavior at the apex, use ALIAS records (Route 53), ANAME records, or CNAME flattening (Cloudflare).

CNAME records also add one extra DNS hop — the resolver must first look up the CNAME, then resolve the target domain. For subdomains this is negligible, but it is why root domains use A records.

#When to use CNAME records

Pointing subdomains to cloud services — when deploying to cloud platforms, you configure a CNAME to route your custom domain through their infrastructure.

CDN setup — CDN providers (CloudFront, Cloudflare, Fastly) give you a distribution hostname. You CNAME your subdomain to it.

SSL certificate verification — certificate authorities like Let's Encrypt use DNS challenges. You add a CNAME at _acme-challenge.yourdomain.com to prove ownership.

Email service verification — Google Workspace, Microsoft 365, and email providers require DKIM and SPF CNAME records for domain authentication. See our MX record checker for email DNS lookups.

#Debugging CNAME issues

If your CNAME lookup returns no record:

• Root domains do not support CNAME — check if you are looking up example.com instead of www.example.com
• Propagation delay — DNS changes take time. TTL on the old record must expire first. Most propagation completes within 1-48 hours.
• Conflicting records — a CNAME cannot coexist with other record types for the same hostname. If an A record exists, the CNAME is ignored.

You can also check from the command line:

# macOS / Linux
dig CNAME www.example.com
 
# Windows
nslookup -type=cname www.example.com

#Open source

This tool is powered by @azin-tech/mini-tools, an open-source developer toolkit. View source on GitHub.