DNS
Apex CNAME checker
See whether a name is really its own zone apex, and whether a CNAME sitting there is legal or just flattened.
Free, no accountLive check
Result
The verdict appears here once you press Check the root domain.
What this is
This apex cname checker settles whether a cname at root domain is even possible for the name you typed, by reading the SOA, CNAME and A records the name itself answers with, rather than guessing from how many labels it has.
A zone apex is the name a zone starts at, the one carrying that zone's own NS and SOA records - and RFC 1034 §3.6.2 forbids a name with a CNAME from holding any other record at all, which an apex always does. Counting dots gets this wrong for a name like a second-level public suffix, so this instead asks the resolver for an SOA record and only calls a name the apex when one answers.
ALIAS and ANAME are a DNS host's own invention, not a DNS record type at all - they let someone configure what looks like a CNAME at the apex, and the host quietly answers with a plain A record instead. Seen from outside, that looks identical to an apex that simply has an A record and no CNAME, which is the second thing this check looks for.
For the apex rule itself, and the other record types that sit alongside a CNAME on a working domain, see our blog guide "The DNS records a domain needs, and what each one actually does."
How to read the result
The facts above name three things: whether this name answered with its own SOA record at all, what CNAME it has if any, and what A record it has if any. Those three answers are the whole decision - there is nothing else to weigh.
A fail means a CNAME is sitting somewhere RFC 1034 §3.6.2 does not allow it to. A pass with an A record at the apex and no CNAME is what flattening looks like done correctly; an info result means the rule against a CNAME at the apex never applied to this name in the first place.
Common mistakes
What goes wrong most often, and how to tell.
- Guessing a name is the apex by counting its labelsA two-label name like example.com usually is the apex, but a name registered under a public suffix such as example.co.uk is not, even though it also has an SOA record at the right place. Only an SOA record actually answering settles it.
- Assuming a flattened apex is the same as a manually kept A recordBoth answer with an identical A record over plain DNS, so this check cannot tell a host's ALIAS/ANAME feature apart from someone updating the A record by hand whenever the target changes. Only the DNS host's own panel actually knows which one it is doing.
- Leaving a CNAME at the apex because a DNS host saved it anywayMost hosts refuse to save a CNAME alongside the NS and SOA records an apex always needs, but a few do not enforce it, and the zone that results answers unpredictably depending on which record type a resolver happens to ask for.
Questions
What people ask about this tool.
- No DNS host can make that legal at the protocol level - RFC 1034 §3.6.2 forbids a name with a CNAME from carrying any other record, and the apex always needs its own NS and SOA records, so a plain CNAME there is impossible to use safely.
- A DNS host resolves the CNAME's target on its own servers and hands back a plain A or AAAA record whenever anyone asks, so the apex technically carries no CNAME at all - it only looks like one in the host's own control panel.
- It asks the name itself for an SOA record. A name that answers with one is where a zone starts, by definition, regardless of how many labels it has; a name that answers with nothing there sits inside somebody else's zone instead.
- RFC 1034 §3.6.2 does not allow a CNAME to share a name with any other record anywhere in a zone, apex or not, because a resolver asking for one type can get an answer that contradicts what the other type would have said for the very same name.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “RFC 1034: Domain Names - Concepts and Facilities” read 13 October 2026
- IETF, “RFC 1912: Common DNS Operational and Configuration Errors” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.