Free CNAME Checker

A CNAME record is a redirect that happens inside DNS, before your browser ever makes a request. When a resolver looks up a name that has a CNAME, it doesn't get an answer — it gets told "that's really called something else, go ask for this name instead." So it does, and it keeps following until it lands on a name with an actual A record and a real IP address. One lookup you typed quietly becomes two or three under the hood.

That indirection is the entire value of a CNAME. Because www.example.com points at a name rather than a number, whoever owns that target — a CDN, a hosting platform, a status page — can move their servers, swap IPs, or fail over to a new region, and your record never has to change. You pointed at a name; they keep the name aimed at the right place. It's why platforms hand you a CNAME to set up instead of an IP address.

Almost every CNAME you'll ever set falls into one of a few buckets, and knowing which one you're in tells you what the target should look like:

CNAMEs come with two constraints that cause most of the confusion. The first is the apex rule: you cannot put a CNAME on the bare root of your domain — example.com with no www. The DNS spec won't allow a CNAME to sit alongside the other records an apex is required to have (its NS and SOA records), so your provider rejects it outright. If a platform tells you to "CNAME your root domain" and your registrar refuses, what you actually need is an ALIAS or ANAME record — a special type that behaves like a CNAME but is legal at the apex — or Cloudflare's CNAME flattening, which quietly resolves the CNAME down to an A record for you.

The second rule follows from the first: a name with a CNAME can't have any other records. You can't put a CNAME and an MX record on the same hostname, for example — which is why you alias www but keep your mail records on the apex. When a lookup shows no CNAME where you expected one, it's often because another record type is already living on that name.

The most dangerous CNAME isn't a wrong one — it's a forgotten one. Say you pointed status.example.com at a hosting provider a year ago, then stopped using the service but left the CNAME in place. That's a dangling CNAME: it still aliases your subdomain to a target you no longer control. If someone else claims that target on the provider, they inherit your subdomain — a subdomain takeover, complete with a valid page served under your name.

What makes this hard is timing. The lookup above tells you what's true this second, and a CNAME reads perfectly fine right up until the target underneath it changes hands or disappears. A one-time check can't warn you when that happens next week. That's the gap continuous monitoring closes: point Uptura at your domains and it re-runs this exact lookup on a schedule, keeps a baseline of every CNAME and the record it resolves to, and the moment one changes it emails or Slacks you the before-and-after — so a broken alias or a takeover is something you catch in minutes, not something a customer reports.