3,932 Australian domains analysed. Most fail basic email authentication. [2026 Report]

CNAME Record Lookup

Find the canonical name (alias target) for any hostname.

Perform CNAME Lookup

What is a CNAME record?

A CNAME record (Canonical Name) points one hostname to another, effectively creating a DNS alias. When a resolver follows a CNAME, it stops resolving the original name and restarts the lookup against the target hostname — whatever A, AAAA, MX, or other records exist at the target become the effective answer for the alias.

CNAMEs are the standard way to delegate hostname resolution to a third party without granting DNS zone access. Pointing www.example.com to d1234.cloudfront.net tells resolvers "for this hostname, whatever the CloudFront edge answers is the authoritative answer". The CNAME owner doesn't need to know (and shouldn't care about) the target's underlying IP addresses — that's the whole point.

CNAMEs are also used heavily for email authentication. ESPs like SendGrid, Mailgun, and Postmark typically ask customers to publish CNAMEs at specific selector names so DKIM key rotation can happen on the ESP side without customer intervention. For example, em123.example.com CNAME u1234.wl.sendgrid.net lets SendGrid rotate the underlying TXT record invisibly.

The DNS spec imposes two strict constraints on CNAMEs. First, they cannot coexist with any other record type at the same hostname — no A, MX, or TXT alongside a CNAME. Second, they cannot be published at the zone apex (the bare domain example.com itself — only subdomains like www.example.com). Most DNS providers offer ALIAS or ANAME records as a workaround for the apex limitation.

How to read the results

The result shows the target hostname the alias points to. This is not the final IP — to get there, you'd need to resolve the target's own A or AAAA records. Most DNS resolvers automatically follow CNAMEs to completion, but when troubleshooting it's useful to see the chain explicitly.

Short TTLs on CNAMEs are common and expected, especially when the target is a CDN or load balancer that rotates its own addresses aggressively.

CNAME chains (CNAME → CNAME → CNAME → A) are legal but inefficient. Each link adds a resolver round-trip. If you see a chain deeper than two or three levels, someone along the way has likely stacked redirects without cleaning up the old ones. Long chains also risk hitting resolver-side loop detection and failing entirely.

If the query returns no CNAME but you expected one, the hostname probably has an A or AAAA record directly and never passes through an alias.

Common issues

  • CNAME published at the apex. The DNS spec (RFC 1034) forbids this — example.com cannot have a CNAME because the SOA and NS records at the apex would conflict with it. Use an ALIAS, ANAME, or flattened CNAME feature (offered by Cloudflare, Route 53, Netlify, Fastly) to simulate the behaviour at the apex.
  • CNAME alongside an MX or TXT record. The target hostname's records take precedence and the directly-published MX/TXT is ignored or silently discarded by strict resolvers. Pick one approach per hostname: either use a CNAME to delegate all records, or publish them directly.
  • CNAME chain exceeds resolver limits. Some resolvers cap CNAME following at 8–16 hops to prevent infinite loops. If your chain is long enough to hit this limit, some users will see inconsistent resolution failures while others succeed. Collapse the chain to at most two levels.
  • Unexpected CNAME at a DKIM selector. Many ESPs (SendGrid, Mailgun, Amazon SES) publish DKIM keys via CNAME delegation rather than TXT. This is normal and usually documented in the ESP's DNS setup guide — do not "fix" it by replacing the CNAME with a TXT.
  • CNAME points to a hostname that doesn't exist. If the target has no A or AAAA records, the alias itself resolves to nothing. Commonly caused by a CDN or SaaS account being deleted without cleaning up the customer's DNS — a dangling CNAME can also be a subdomain takeover risk if the target hostname becomes available for someone else to claim.