(100% Working) How to Add ALIAS Record in GoDaddy, Cloudflare, Namecheap Easily 2026

An ALIAS record behaves like a CNAME. It points a name at another name instead of at an IP address, but unlike a CNAME it's legal on the root of a domain.

The restriction on root CNAMEs exists because a CNAME has to be the only record on its name, and a root already carries NS records and usually MX records too. A root CNAME would break both mail and delegation.

Registrars that offer ALIAS work around this by resolving the target hostname on their own nameservers, then answering visitors with the resulting IP addresses, refreshed as the target changes. That's the real benefit: when a host moves your site to a different IP, an ALIAS follows automatically, while a hardcoded A record keeps sending traffic to an address you no longer own until someone notices. Use ALIAS when a service hands you a hostname for the root domain, and a plain CNAME when it hands you one for a subdomain like www or shop.

Before touching DNS, get the destination string from the service you're connecting, and copy it instead of typing it. One wrong character produces a domain that resolves to nothing and an hour of confused troubleshooting.

Most hosts show it on the site or domain panel for your plan, next to the temporary system URL your site currently answers on. In the panel shown here, the site is live on a long ingress hostname under ewp.live, with its SSL certificate and status listed beside it, and the Change link next to Domain is where you tell the host a custom root domain is on its way.

Note the ingress name in that URL: that's the family of hostnames the ALIAS record needs to target. Also check whether the host wants the domain added on its side first. Many providers won't issue an SSL certificate for a domain they haven't been told about, so you can end up with a correct DNS record and a browser warning anyway.

Namecheap is the registrar of the three that genuinely offers the record type. Open Domain List, click Manage on the domain, go to the Advanced DNS tab, and choose Add New Record.

ALIAS Record appears in the type dropdown. Set Host to @ and Value to the hostname your provider gave you, then save with the green tick, which is easy to miss because the row looks saved before you click it.

Two constraints catch people out. First, Namecheap won't let an ALIAS record share a host with an existing CNAME, URL Redirect, A or AAAA record, so delete any of those on @ before adding it.

Second, this only works while the domain sits on Namecheap's own BasicDNS, FreeDNS or PremiumDNS nameservers; if you've pointed the domain at Cloudflare or your host's nameservers instead, the Advanced DNS tab is inert and the record has to be created wherever the nameservers point. Namecheap caps the value at 255 characters and offers a TTL of 1 or 5 minutes, defaulting to 5.

Cloudflare has no record type called ALIAS, and it doesn't need one. Add an ordinary CNAME with the name set to your root domain and the content set to the target hostname.

Cloudflare's CNAME flattening resolves that target and returns A records to visitors, which is functionally the same outcome as an ALIAS under a different name. Flattening applies to root records by default, so there's nothing extra to switch on for a bare-domain CNAME.

The one setting worth a moment's thought is the orange cloud. Proxied means traffic runs through Cloudflare's network and visitors see Cloudflare's IPs; DNS-only passes them straight to your host. Proxied is usually what you want, but switch it to DNS-only if your host needs to issue its own certificate or see the real visitor IP during setup, then turn the proxy back on once the site loads.

GoDaddy's Type dropdown has no ALIAS or ANAME option, and none is coming under that name; GoDaddy's own DNS team has said publicly that it considers ALIAS/ANAME a workaround it doesn't intend to add. On a GoDaddy-hosted zone the root instead takes a CNAME on www plus a domain forward, or A records pointed at the IPs behind your target (the fallback covered next).

For a plain A record, open your account, go to Domains, pick the domain and choose DNS. The add-record form has four fields: Type, Name, Value and TTL.

Name is where the root goes: enter @, which is DNS shorthand for the domain itself, not the word www and not the full domain name. Drop the IP into Value and leave TTL at its default while you're testing, since a short TTL means a mistake expires quickly instead of sitting in caches all day.

GoDaddy's record list sits directly under the form, so you can confirm the new row saved and the existing NS entries are untouched. GoDaddy has also started supporting HTTPS records in alias mode (priority 0, RFC 9460) on some zones, which behave like flattening for services that publish one, but A records remain the option that works everywhere.

If your registrar has no ALIAS type and you're not on Cloudflare, you can reach the same destination with plain A records. You take on the maintenance yourself in exchange.

Ask your host for the IP addresses behind the target hostname; providers that expect this usually publish a table mapping each ingress hostname to its addresses, as in the reference page shown here, which pairs names like ingress-alpha.easywp.com with a pair of IPs. Create an A record on @ for each address, then repeat the same set for the www host so both versions of your domain resolve.

Using both IPs instead of just one matters: it's what gives you a second path if the first server stops answering. The trade-off is that this is a snapshot. If your host ever changes those addresses, your site goes dark until you edit the records by hand, so set a reminder to re-check them, or move the zone to a registrar that supports ALIAS and stop thinking about it.

Propagation is mostly a myth in the way people use the word. What happens is that resolvers hold the old answer until its TTL expires, which is why lowering TTL before a change is worth the extra minute.

Instead of refreshing your browser, query the record directly: run dig example.com or nslookup example.com against a public resolver like 1.1.1.1, and check the addresses coming back match what your host expects. If you still see an old value, clear your local DNS cache and try a resolver you haven't queried yet, since your own machine caches aggressively too.

Two mistakes account for most failures here: a leftover A record on @ competing with the new one, and the domain still pointed at nameservers other than the panel you edited. Delete the stale record, confirm the nameservers, and the root resolves within the TTL window.