Point Root Domain in Namecheap DNS: A Record vs CNAME Guide

by Fahim

You just shipped a project and need to point your naked root domain (example.com) to your server or cloud host. If you try to slap a standard CNAME on the root inside Namecheap, the dashboard either throws a validation error or quietly blows up your incoming email.

I’ve configured this exact zone setup countless times across static hosts, bare VPS boxes, and shared hosting. Here is how DNS handles the zone apex, when to reach for an A record versus an ALIAS record in Namecheap, and how to verify everything from your terminal instead of guessing.

Close up view of terminal screen showing DNS dig command outputs and A record configurations
Close up view of terminal screen showing DNS dig command outputs and A record configurations

The Zone Apex Problem (Why CNAME Fails on Root Domains)

The root domain—often called the zone apex or naked domain—is your base domain without any subdomain prefix (example.com rather than www.example.com). In standard DNS zone files, this root level is represented by the @ symbol.

Under IETF RFC 1034 (Section 3.6.2), if a CNAME record lives on a specific node, no other record types can exist at that same node. Because your root domain must hold mandatory SOA (Start of Authority) and NS (Nameserver) records—plus your MX and TXT records for mail—sticking a CNAME on the root violates basic DNS specs.

If a DNS provider let you put a raw CNAME on @, any external mail server looking for your MX records would follow the CNAME alias instead. It would hunt for MX records on your hosting provider’s load balancer hostname, find nothing, and bounce every single incoming email. If you’re managing business mail on the same domain, read our breakdown on how to point Namecheap DNS to Hostinger without breaking email to see how MX and A records coexist cleanly.

Method 1: Pointing Root via an A Record (Fixed IP Setup)

If your VPS or hosting provider gives you a static IPv4 address (like 192.0.2.1), an A record is the cleanest, fastest setup. There’s zero dynamic lookup overhead, and it won’t clash with any other root records.

Here’s the setup flow in Namecheap:

  1. Log into Namecheap and hit Domain List in the left sidebar.
  2. Click Manage next to your domain.
  3. Head to the Advanced DNS tab.
  4. Under Host Records, click Add New Record.
  5. Pick A Record from the dropdown.
  6. Set Host to @.
  7. Paste your server’s IPv4 address into the Value field.
  8. Set TTL to Automatic (or 1 min if you’re actively migrating).
  9. Click the green checkmark to save.

If your host also gave you an IPv6 address, click Add New Record, choose AAAA Record, set the host to @, and enter the IPv6 string.

Here’s what the raw DNS zone export looks like for this setup:

; Namecheap Zone Apex Configuration
; A Record for Root Domain
@ 300 IN A 192.0.2.1
; Optional IPv6
@ 300 IN AAAA 2001:db8::1
; Canonical Name for WWW Subdomain
www 300 IN CNAME example.com.

This setup routes all direct traffic for example.com straight to your server IP while pointing www back to root. If you’re running a multi-server setup where different hostnames route to separate backends, check out our guide on how to route subdomains to different servers in Namecheap DNS.

Method 2: Pointing Root via ALIAS (ANAME) for Dynamic Endpoints

Modern platforms like Vercel, Netlify, Heroku, and AWS ALBs rarely give you a static IP. Instead, they hand you a dynamic target hostname like cname.vercel-dns.com or an AWS load balancer URL that shuffles IP addresses behind the scenes.

Since you can’t put a raw CNAME on the apex, Namecheap provides a pseudo-record called an ALIAS Record (often called ANAME in DNS circles). Namecheap’s nameservers resolve the upstream target hostname down to its current IPs at query time and return them to the client as standard A records. This gives you dynamic cloud routing while keeping your zone RFC-compliant.

To set up an ALIAS record in Namecheap Advanced DNS:

  1. Navigate to Domain List > Manage > Advanced DNS.
  2. Delete any existing A Record or URL Redirect Record using @ as the host.
  3. Click Add New Record and choose ALIAS Record.
  4. Set Host to @.
  5. In the Value field, paste your cloud provider’s target hostname (e.g., your-app.netlify.app). Leave off any trailing dot.
  6. Set TTL to Automatic.
  7. Save the record with the green checkmark.

This lets you deploy a web app with custom DNS and SSL without worrying about static IP changes or managing your own reverse proxy.

Managing WWW and Handling Root Redirects

People will type both example.com and www.example.com. You need to pick a canonical URL structure and configure DNS and your web server to handle it cleanly.

Option A: WWW as a CNAME to Root

This is the standard approach. The root domain holds your A or ALIAS record, and the www subdomain points to @ with a CNAME.

  • Record 1: Type: A Record | Host: @ | Value: 192.0.2.1
  • Record 2: Type: CNAME Record | Host: www | Value: example.com. (or @ in Namecheap)

Your web server (Nginx, Apache, or Caddy) listens for both names and serves an HTTP 301 redirect from http(s)://www.example.com over to https://example.com.

Option B: Namecheap URL Redirect Record

If your hosting environment can’t handle HTTP-level redirects directly, Namecheap has an internal URL Redirect Record option. When enabled, Namecheap’s redirect servers catch the incoming traffic and issue a 301 or 302 redirect.

Watch out for this major gotcha: A URL Redirect Record on @ overrides and breaks your root A Record. You cannot have both an active A record pointing to your origin and a URL Redirect on the same @ host. If you need example.com to redirect to www.example.com using Namecheap’s redirector:

; Namecheap URL Redirect Setup (Root to WWW)
; Host: @ points to Namecheap redirect engine
@ Unmasked https://www.example.com
; Host: www points directly to your web server
www 300 IN A 192.0.2.1

In production, I prefer letting the actual web server handle the 301 redirect. It keeps all TLS certificates centralized on your box and eliminates an extra redirect hop through registrar parking servers.

Verifying Your Setup with Terminal Tools

Don’t rely on your browser to check DNS changes. Browser caches, OS resolvers, and local ISP caching will fool you into thinking a record failed when it actually propagated minutes ago.

I use dig and host to query Namecheap’s authoritative nameservers directly. Run these commands to inspect your zone records:

# 1. Query your root A record against Google Public DNS
dig example.com A +noall +answer # 2. Query your root domain directly against Namecheap nameservers
dig @dns1.registrar-servers.com example.com A +noall +answer # 3. Check for CNAME or ALIAS resolution on www
dig www.example.com CNAME +noall +answer # 4. Verify your MX records remain intact and unshadowed
dig example.com MX +noall +answer

Here’s the terminal output when your A record and CNAME are working properly:

$ dig example.com A +noall +answer
example.com. 300 IN A 192.0.2.1 $ dig www.example.com CNAME +noall +answer
www.example.com. 300 IN CNAME example.com. $ dig example.com MX +noall +answer
example.com. 300 IN MX 10 mail.example.com.

If the record resolves against dns1.registrar-servers.com, Namecheap has already updated its edge. Any remaining delay on your local machine is just downstream TTL caching from your ISP.

The Broken Email Gotcha (Zone Shadowing)

The most common outage I see developers hit during root domain setup involves mail routing.

If you leave an old URL Redirect Record on @ in Namecheap, it can collide with MX record resolution on certain mail transfer agents (MTAs) due to synthetic wildcard entries. Similarly, moving DNS to a provider that tries a hard CNAME on root without CNAME flattening will quietly break all inbound SMTP traffic.

Whenever you touch your root A or ALIAS records in Namecheap, double-check that your authentication records didn’t get knocked offline. Take a look at our step-by-step guide to configure SPF, DKIM, and DMARC in Namecheap DNS so your email deliverability stays rock solid after pointing your domain.

Production DNS Checklist

Before sending live traffic to your domain, run through this quick sanity check in Namecheap Advanced DNS:

  • Nameservers: Verify your domain uses Namecheap BasicDNS or Namecheap Web Hosting DNS under the Domain tab. If you have custom nameservers configured, the Advanced DNS tab is completely bypassed.
  • No Conflicting Apex Records: Ensure you don’t have both an A Record and an ALIAS Record sitting on @ simultaneously. Pick one based on your host type.
  • Wipe Parking Records: Delete Namecheap’s default Parking Page A record (pointing to 198.54.117.x) before saving your custom records.
  • TTL Strategy: Lower your TTL to 1 min or 5 min roughly 24 hours before making a migration. Once stable, bump it back to Automatic or 30 min to save unnecessary DNS lookups.
  • SSL Challenges: Make sure your root A record resolves cleanly before running Certbot or automated Let’s Encrypt HTTP-01 challenges on your origin.

Frequently Asked Questions

Can I use a CNAME record for my root domain on Namecheap?

No. Namecheap disallows raw CNAME records on the root host (@) because it breaks RFC 1034 specs and takes down MX, NS, and SOA lookups. Use an A Record for static IPs or an ALIAS Record if your host gives you a dynamic hostname like a Netlify or AWS URL.

What is the difference between an A Record and an ALIAS Record in Namecheap?

An A Record maps your domain directly to a static IPv4 address. An ALIAS Record points your domain to another hostname, but Namecheap’s nameservers dynamically resolve that target to its current IP address on the fly, returning standard A records to visitors.

Why is my new A record not updating in my browser?

Your local resolver is caching the old IP based on the previous record’s TTL. If the old TTL was 3600 seconds (1 hour), your machine may hold the old address for that entire window. Check real-time propagation with dig @8.8.8.8 example.com A or flush your local cache using sudo resolvectl flush-caches on Linux or ipconfig /flushdns on Windows.

Will changing my root A record break my custom domain email?

No, as long as you only edit the A or ALIAS record for @ and leave your MX, TXT (SPF), and DKIM records alone. The only catch: if your MX record points directly to example.com instead of a dedicated host like mail.example.com, changing the root IP will also route incoming mail connections to your web server.

Next Steps

Once your root domain resolves to your server, you’re ready to wire up your deployment pipeline and issue automated SSL certificates. Follow our guide on deploying a web app on Hostinger with Namecheap DNS and SSL to finish provisioning your origin.

Official resources

all_in_one_marketing_tool