What a CNAME record does
A CNAME (canonical name) record declares that one name is an alias for another. The record www.example.com CNAME example.github.io. tells every resolver to stop, restart the question at example.github.io, and return whatever that name holds. The alias itself carries no address. The target does. That indirection is why vendors ask you to create a CNAME: they can move their servers without you touching your zone.
RFC 1034 says a name that has a CNAME must have no other records. The reason is mechanical: once a resolver sees the CNAME it substitutes the target for every query type, so an MX or TXT record sitting next to the alias would never be returned. The same rule forbids a CNAME at the zone apex, because the apex must hold SOA and NS records.
Reading the result table
The table lists the CNAME records the resolver returned for the name, with the canonical target in the second column. If a chain exists (an alias pointing at another alias), the entries the resolver reported appear in order and the last one is used as the target for the address lookup. The Final resolved addresses block shows the target's A and AAAA records as chips tagged IPv4 or IPv6, each linking to IP Lookup.
An empty table with the No CNAME record notice means the resolvers returned NODATA or NXDOMAIN for the CNAME type. Either the name has its own address records, or the name does not exist at all. A SERVFAIL, timeout or a hostname that fails validation produces an error instead, so you never mistake an outage for a missing record.
Aliases at the apex and the workarounds
People want example.com to point at a CDN hostname and find that their DNS host refuses the record, correctly: a CNAME at the apex conflicts with the SOA and NS records that must live there. The workarounds are provider-side. CNAME flattening and ALIAS or ANAME records make the authoritative server resolve the target itself and hand out plain A and AAAA records, which is what this tool then sees.
Because flattening is invisible from outside, the lookup cannot tell a flattened apex from a normal one. Check the apex with Domain to IP and compare its addresses with the CDN hostname's addresses. If they match and change together over time, the apex is being flattened.
Problems this lookup reveals
The most dangerous finding is a dangling CNAME: an alias whose target no longer exists, typically a deleted storage bucket, a removed app on a hosting platform, or a cancelled SaaS plan. Anyone who can register that target name on the platform then serves content under your subdomain. The fix is to delete the CNAME as soon as the service is retired, and to scan for leftovers with the Domain Scanner.
Verification failures at a vendor usually come down to three things: the record was created at the wrong name (shop.example.com versus www.shop.example.com), the target has a typo, or the vendor's hostname is not provisioned yet. Looking up the exact name shows which of the three you have.
- Mail stops after adding a CNAME: an MX at the same name is masked. Move mail to a name without a CNAME.
- DKIM via CNAME is fine: selector._domainkey.example.com may alias to the vendor's key because nothing else lives at that name.
- Long chains add a lookup per hop and a failure point per target. Two hops is a sensible limit.
- Apex rejected by your DNS host: use ALIAS, ANAME or flattening rather than forcing a CNAME.
What the lookup cannot tell you
The answer reflects the caches of the public resolvers Cloudflare 1.1.1.1, Google 8.8.8.8 and Quad9 9.9.9.9, not the authoritative zone. Right after a change, use the DNS Change Analyzer to compare resolvers with your nameservers. The tool also says nothing about HTTP: a CNAME does not redirect a browser, so the target must still serve your hostname with a valid certificate.