Canonical name (alias) records
DNS & Records
DNS Lookup Every DNS record for any domain A Record Lookup IPv4 addresses for a domain AAAA Record Lookup IPv6 addresses for a domain MX Lookup Mail servers for a domain NS Lookup Authoritative name servers TXT Lookup TXT records, SPF, verification CNAME Lookup Canonical name (alias) records SOA Lookup Start of Authority record SRV Lookup Service location records CAA Lookup Which CAs may issue certificates Reverse DNS (PTR) IP address to hostname DNSSEC Check Is the domain signed and validated? DNS Health Check A full delegation & DNS report cardEmail Deliverability
SPF Check Validate your Sender Policy Framework record DMARC Check Inspect and grade your DMARC policy DKIM Check Find and validate your DKIM public key Blacklist Check Check an IP against email blocklists (DNSBLs) SMTP Test Connect to a mail server and check STARTTLS MTA-STS Check Enforced TLS policy for inbound mail BIMI Check Brand logo record for email TLS-RPT Check SMTP TLS reporting policyNetwork & Web
SSL Certificate Check Inspect a site's TLS certificate and expiry HTTP Header Check Inspect response headers, redirects and security Ping (TCP) Reachability and latency over TCP Port Check Which common ports are openDomain
WHOIS Lookup Registration data for domains, IPs and ASNsA CNAME record aliases one hostname to another canonical name, so the target's A and AAAA records are used to resolve the address. It is common for subdomains that point at CDNs or SaaS providers, letting you follow their infrastructure without tracking their IP addresses. When the provider changes IPs, your CNAME keeps working automatically.
A CNAME does not store an IP; it points one hostname at another. When a resolver hits a CNAME, it restarts the lookup on the target name and follows its A or AAAA records to the final address. For example, shop.example.com CNAME mystore.shopify.com means a request for shop.example.com resolves through Shopify's hostname. This indirection is why CDNs and SaaS platforms hand you a CNAME target: they can change the underlying IPs freely and your subdomain follows along with no edits on your side.
A CNAME result shows the alias hostname and the canonical target it points to, such as www.example.com CNAME example.com or blog.example.com CNAME hosted.ghost.io. To see the final IP, follow the chain: the target's own A and AAAA records resolve the address. If a CNAME points at a target that itself has a CNAME, resolvers follow the chain, though long chains add lookups and latency. A CNAME pointing at a hostname with no records is broken and will fail to resolve.
The most important rule is that you cannot put a CNAME on the root domain (example.com), because the apex must coexist with required NS and SOA records and a CNAME may not share a name with other records. Use an A record or a provider's ALIAS/ANAME feature at the apex instead. You also cannot add a CNAME to a hostname that already has an A, MX, or TXT record. A frequent failure is pointing a CNAME at a SaaS target before activating the service there, which leaves it unresolvable.
A CNAME record is a DNS record that aliases one hostname to another canonical hostname, so the target's A and AAAA records are used to resolve the address. CNAME stands for canonical name. It is widely used to point subdomains at CDNs and SaaS providers, so your domain follows their servers even when their IP addresses change.
A CNAME points a hostname to another hostname, while an A record points a hostname directly to an IPv4 address. A CNAME adds a layer of indirection that auto-follows the target's IPs; an A record is a fixed mapping. Use a CNAME for subdomains tracking a provider, and an A record for a root domain or a fixed IP.
No, you cannot use a standard CNAME on a root (apex) domain such as example.com, because the apex must hold NS and SOA records and a CNAME cannot coexist with other records on the same name. Instead, use an A record or your DNS provider's ALIAS or ANAME feature, which mimics CNAME behavior at the apex while staying standards-compliant.
Yes, a CNAME can point to another CNAME, and resolvers will follow the chain until they reach a hostname with A or AAAA records. However, long chains add a DNS lookup at each hop, increasing latency. Keep chains short, ideally one level, and make sure the final target actually has address records so resolution succeeds.
A CNAME often fails because the target hostname has no A or AAAA records, the SaaS service it points to has not been activated yet, or you placed the CNAME on a name that already has other records. Verify the target resolves on its own, confirm the provider's setup is complete, and ensure no conflicting A, MX, or TXT records share the hostname.