You buy a domain on Namecheap, point your site to your host, and hit an immediate wall: www.example.com loads perfectly, but example.com refuses to resolve. If you try slapping a CNAME record on the root domain inside Namecheap BasicDNS, the dashboard throws an error or silently breaks your mail routing. Here is why the DNS spec prevents root CNAMEs, how resolvers actually handle apex lookups, and how to route root domain traffic cleanly.

1. The RFC 1034 Trap: Why CNAME Fails on Root Domains
DNS seems simple enough until you try pointing a zone apex (the naked root domain like example.com) at another hostname with a CNAME. Try creating a CNAME with host @ in Namecheap, and you will hit a hard stop.
This isn’t a Namecheap limitation—it’s baked into IETF RFC 1034 Section 3.6.2. The spec states that if a node has a CNAME record, it cannot hold any other resource records. The problem is that your root domain must have other records to function at all:
- SOA (Start of Authority): Defines authoritative zone parameters.
- NS (Name Server): Points to the nameservers authoritative for the zone.
- MX (Mail Exchange): Directs incoming email to your mail provider.
Putting a CNAME at the root (@) forces resolvers to ignore your SOA, NS, and MX records. That immediately breaks zone lookups and kills incoming email. If you need mail working on your domain, check out how to route custom domain email to Google Workspace with Namecheap DNS.
2. A Records vs CNAME Records: How Resolvers Query Them
To set up Namecheap DNS properly, you need to know how resolvers handle A records versus CNAMEs during recursive queries.
An A Record maps a hostname straight to an IPv4 address (like 192.0.2.1), and an AAAA Record maps to an IPv6 address. When a client requests an A record, the nameserver returns the IP immediately in the first response. Done in one round-trip.
A CNAME Record maps an alias to another hostname (like myapp.onrender.com or cname.vercel-dns.com). The resolver receives the alias, realizes it still doesn’t have an IP, and fires off an extra DNS query to resolve that target hostname. That adds lookup latency—usually 40ms to 120ms on cold lookups—and triggers the RFC exclusivity rule.
Here is how record types break down by host level:
- Root Domain (
@/example.com): Use A/AAAA records, an HTTP redirect, or ALIAS/ANAME via an external DNS provider that supports flattening. - Subdomains (
www,api,app): Can use CNAME, A, or AAAA records without interfering with root zone records. - Wildcard (
*): Best for catching arbitrary subdomains and routing them to a single endpoint.
3. Setting Up an A Record for Apex Domains in Namecheap BasicDNS
If your hosting provider gives you a static or dedicated IP address (standard for VPS instances, dedicated boxes, and many static hosts), an A record on the root domain is the fastest, cleanest approach.
Head to your Namecheap Domain List, click Manage next to your domain, and open the Advanced DNS tab. Make sure your nameservers are set to Namecheap BasicDNS under the main Domain tab. If you need custom nameservers instead, see our guide on custom nameservers and glue records in Namecheap.
Under Host Records in Advanced DNS, delete any default parking records (such as default URL Redirects or parking pages) and add your entry:
- Click Add New Record.
- Set Type to A Record.
- Set Host to
@(which represents the naked apex domain). - Set IP Address to your server’s public IPv4 address (e.g.,
198.51.100.42). - Set TTL to
Automatic(or1 min/5 minif you are testing a migration).
If your provider uses multiple IP addresses for redundancy or load balancing (like GitHub Pages), create multiple A records with @ as the host, one for each IP.
Conceptually, here is what this looks like inside a standard DNS zone file:
; Namecheap Zone File Output for Apex and Subdomain
@ 300 IN A 198.51.100.42
@ 300 IN A 198.51.100.43
www 300 IN CNAME example.com.
api 300 IN A 198.51.100.44For modern static frontends and Jamstack platforms, follow our walkthroughs on pointing a Namecheap domain to Vercel and pointing a Namecheap domain to GitHub Pages.
4. When You Need an ALIAS, ANAME, or URL Redirect
What if your host doesn’t offer static IPs? Platforms like Heroku, AWS Elastic Beanstalk, and CloudFront only hand you a hostname like d1234.cloudfront.net or myapp.herokuapp.com.
Because Namecheap BasicDNS does not support native CNAME flattening (ALIAS or ANAME records), you have two options:
Option A: Use Namecheap’s URL Redirect Record
Let Namecheap run an HTTP 301 redirect from the root domain to your www subdomain, then point www to your target hostname using a CNAME.
- Under Namecheap Advanced DNS, click Add New Record.
- Select URL Redirect Record.
- Set Host to
@. - Set Value to
https://www.example.com. - Set the redirect type to Permanent (301).
- Add a second record: Type
CNAME Record, Hostwww, Valueyour-target-hostname.net., TTLAutomatic.
The catch: Namecheap proxies this redirect over their shared edge. If you need full HTTPS custom certificate handling at the apex before redirecting, Namecheap’s URL redirect won’t cut it.
Option B: Switch to a DNS Provider with CNAME Flattening
If you need your application to load directly on https://example.com without redirecting to www, and your host only gives you a CNAME target, Namecheap BasicDNS cannot do this natively. Keep domain registration at Namecheap, but change your nameservers to a provider that supports CNAME flattening or ALIAS records at the apex.
5. How to Route `www` to Root (or Vice Versa) Without Breaking SSL
In production, you want all traffic landing on one canonical domain—either example.com or www.example.com—with the alternate variant redirecting via HTTP 301. This keeps SEO authority unified and prevents session cookie splits.
If you manage your own Nginx server or reverse proxy, point both @ and www to your server IP via A records, then handle SSL termination and the 301 redirect inside Nginx.
Here is an Nginx config that redirects www to the canonical root domain over HTTPS:
# /etc/nginx/sites-available/example.com.conf # Redirect HTTP traffic to HTTPS Apex
server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://example.com$request_uri;
} # Redirect HTTPS www to HTTPS Apex
server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; return 301 https://example.com$request_uri;
} # Main application block
server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; root /var/www/example.com/public; index index.html index.php; location / { try_files $uri $uri/ /index.php?$query_string; }
}Make sure your SSL certificate covers both names by passing both flags to Certbot:
sudo certbot --nginx -d example.com -d www.example.com6. Debugging Apex DNS Resolution: Dig, Curl, and TTL Gotchas
Don’t rely on your browser to verify DNS changes. Browsers aggressively cache DNS lookups and lock in HSTS redirects, hiding what nameservers are actually returning.
Open a terminal and query your records with dig. Query Namecheap’s authoritative nameserver directly first, then test public resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1).
Here is how I check an apex A record lookup:
# Query Namecheap authoritative nameservers directly
dig @dns1.registrar-servers.com example.com A +noall +answer # Query public resolver with full trace
dig example.com A +traceYou should see the IP address and remaining TTL in the answer section:
; DiG 9.18.18 @dns1.registrar-servers.com example.com A +noall +answer
example.com. 300 IN A 198.51.100.42Once DNS returns the right IP, use curl to trace the redirect headers and verify there are no redirect loops:
curl -ILs https://www.example.com | grep -E "HTTP/|Location"When you see HTTP/2 301 redirecting to https://example.com/ followed by HTTP/2 200, your routing is solid.
7. Common Namecheap Apex DNS Pitfalls and Real Fixes
Most DNS issues in Namecheap come down to these four mistakes:
- Typing the full domain in the Host field: In Namecheap BasicDNS, entering
example.comcreates a record forexample.com.example.com. Always use@for the root domain. - Leaving default parking records active: Namecheap often pre-populates a
URL Redirect (Masked)or a parking page record when you register a domain. If you add an A record without deleting those default entries, resolvers get conflicting data. - Entering IPs into CNAME fields: CNAME values must be hostnames, never IP addresses. If you have an IP, select the A Record type.
- Negative DNS caching: If you visited your domain before adding records, your OS cached an NXDOMAIN response based on the SOA negative TTL (often 300 to 3600 seconds). Clear your local cache using
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderon macOS oripconfig /flushdnson Windows.
8. Frequently Asked Questions
Can I point my root domain to a CNAME in Namecheap BasicDNS?
No. RFC 1034 prohibits CNAME records on the root host (@) because they conflict with required SOA and NS records. Namecheap BasicDNS does not support CNAME flattening, so you must use an A record or a URL Redirect.
How long does Namecheap DNS propagation take for root domains?
Changes made inside Namecheap BasicDNS usually take effect within 5 to 30 minutes. If you are changing authoritative nameservers on the domain, global propagation can take up to 24 to 48 hours.
What should I put in the Host field for the root domain?
Always enter @. In DNS zone conventions, @ is shorthand for the origin/apex domain.
Can I have both an A record and a CNAME record on the root domain?
No. DNS rules forbid having an A record and a CNAME record on the same host label. Namecheap’s interface will reject this configuration.
Once your root domain is resolving, secure your domain email by checking our guide on how to configure SPF, DKIM, and DMARC records in Namecheap BasicDNS.

