CNAME Record Lookup: Understanding DNS Aliases

What CNAME Records Do

A CNAME (Canonical Name) record aliases one domain name to another. When a resolver queries www.example.com and finds a CNAME pointing to example.com, it follows the alias and queries example.com for the actual A or AAAA record. The CNAME does not hold an IP address itself — it delegates resolution to the canonical name.

CNAMEs are the standard way to point subdomains at external services. If your marketing site is hosted on a CDN, you publish a CNAME from www.example.com to example.cdn-provider.com. When the CDN changes its IP addresses, your DNS does not need to change — the CNAME follows automatically.

How CNAME Chains Work

A CNAME can point to another CNAME, forming a chain. The resolver follows each link until it reaches a name that has an actual address record. Most resolvers handle chains of two or three hops without issue, but longer chains add latency and increase the chance of resolution failure if any link breaks. Keep chains short.

The Apex Restriction

The most important CNAME limitation: a CNAME cannot coexist with other record types at the same name. Per RFC 1034, if a CNAME exists for example.com, no MX, TXT, NS, or A records can exist at example.com.

This means you cannot put a CNAME on your bare domain (the apex — example.com without www) if you also need MX records for email or TXT records for SPF and DMARC. Since virtually every domain needs those records at the apex, CNAMEs at the apex are effectively prohibited.

Some DNS providers offer proprietary workarounds — Cloudflare calls theirs "CNAME flattening," AWS Route 53 uses "ALIAS records," and others use "ANAME." These synthesize an A record from a CNAME target at query time, avoiding the conflict. They work, but they are not standard DNS — they depend on your provider supporting them.

CNAME and Email Authentication

CNAMEs play a specific role in DKIM deployment. Most email service providers ask you to publish CNAME records for your DKIM selectors, pointing them at the provider's key-hosting domain. For example:

s1._domainkey.example.com. CNAME s1._domainkey.provider.com.

This lets the provider rotate DKIM keys without requiring you to update your DNS. The DKIM Checker follows these CNAME delegations when verifying your DKIM configuration.

Common CNAME Issues

CNAME at the apex with other records. Some DNS providers silently allow this, but it violates the standard and can cause unpredictable behavior across different resolvers. Use an ALIAS or ANAME record instead, or point the apex directly with A and AAAA records.

Broken CNAME target. The CNAME points to a hostname that no longer resolves. The alias chain dead-ends, and the original name fails to resolve entirely. Audit CNAME targets after decommissioning any service.

CNAME where an A record is expected. Some older systems do not follow CNAMEs correctly. If a service requires an A record, publishing a CNAME instead may cause intermittent failures.

Checking CNAME Records

Use the mxio CNAME Lookup to trace CNAME aliases for any domain and see where they resolve. For a complete view of all record types at a name, use the DNS Lookup tool.

Look up CNAME records for your domain