mabel.ink

You cannot CNAME an apex domain

July 23, 2026

Pointing www.mabel.ink at my Azure site took one record and about thirty seconds. Pointing mabel.ink at the same place took a validation record, a different record type, and deleting something my registrar had put there by default.

The asymmetry is not a vendor quirk. It falls out of how DNS works, and the reason is worth knowing because it also explains why your email is at risk if you do this carelessly.

The easy half

A subdomain is straightforward. www is just a name in the zone, so you point it at the provider's hostname with a CNAME:

CNAME   www   yellow-field-08296cc0f.7.azurestaticapps.net

A CNAME says "this name is an alias for that other name." The resolver follows it and asks again. Done.

Why the apex is different

A CNAME does not mean "also resolve to." It means "this name is nothing but an alias for that name." The RFCs are strict about it: if a name has a CNAME record, it cannot have any other records.

The apex of a zone is exactly the name that cannot satisfy that. It must carry SOA and NS records, that is what makes it a zone. And in practice it usually carries MX records too, because mail for you@example.com is routed by the MX records at example.com.

So a CNAME at the apex is not "discouraged" or "poorly supported." It is mutually exclusive with the records that have to be there. If a provider let you do it, you would lose mail delivery, and depending on the resolver you might lose the zone.

That is the whole rule. It is not about Azure, or your registrar, or the year.

What you use instead

Two options, and neither is a CNAME.

An A record pointing at an IP address. This works everywhere because it is ordinary DNS. The problem is that you have hard-coded a specific IP for a service you do not run. If the provider changes it, your site goes down and nothing tells you why.

An ALIAS record, sometimes called ANAME, which is what I used. This behaves like a CNAME from your point of view, but the DNS provider resolves the target on their side and hands back the resulting address records. Because the client only ever sees A records, nothing conflicts with MX or NS.

The catch: ALIAS is not in any DNS standard. It is a provider feature. If your DNS host does not offer it, you are back to an A record, which is a real reason to consider moving DNS hosting even when your registrar stays put.

The Azure flow specifically

For the subdomain, Azure wanted the CNAME to exist before validating. For the apex, it went the other way: it generated a TXT value for me to publish first, proving I control the domain, then asked for the routing record.

Worth noting that TXT records coexist happily with everything. Multiple TXT records at the same name are fine, which matters because the apex already had one holding the SPF record for email forwarding. Adding the validation TXT alongside it was safe. Replacing it would not have been, and that is a very easy mistake to make if you assume one record per name.

The record I had to remove was a URL redirect my registrar had added by default, pointing the apex at the parking page. That occupied the apex and conflicted with the ALIAS. Deleting it did not affect mail, because a URL redirect is an HTTP behaviour and has nothing to do with MX.

The thing I could not do

I wanted www.mabel.ink to redirect to mabel.ink so one URL is canonical.

Azure Static Web Apps cannot do it. Its config file supports route rules, but they match on paths, not on hostnames. There is no host-based redirect. Both names serve the site, and the only ways to get a real 301 are to put an Azure Function in front to inspect the Host header, or to put something else in front entirely.

For a site this size that is not worth a compute resource. The actual concern was duplicate content for search engines, and that has a solution that requires no infrastructure at all:

<link rel="canonical" href="https://mabel.ink/">

That tells crawlers which URL is authoritative. Problem addressed at the layer where the problem actually lived.

Summary