You deploy an app on Railway, Vercel, or Render, and the setup screen tells you to point your root domain to something like app-ingress-7841.up.railway.app. You head into Namecheap Advanced DNS, plug in @ for the host, pick CNAME, and click save. Namecheap immediately barks back with an error or warns you about conflicting records.
You can’t put a raw CNAME on a root domain without breaking core DNS rules. I learned this the hard way years ago when deploying an app and watching every inbound email vanish into thin air. Here is how DNS actually treats the apex domain and how to configure Namecheap without shooting yourself in the foot.
The RFC Problem: Why DNS Forbids CNAME at the Apex
The root domain—often called the zone apex or naked domain (like example.com without www)—always needs an SOA (Start of Authority) and NS (Name Server) record. Back in 1987, IETF RFC 1034 laid down a strict rule: if a CNAME record lives on a label, no other record can exist on that same label. None.
Because your zone apex is required to have SOA and NS records, dropping a standard CNAME at @ breaks the protocol. If a recursive resolver gets a CNAME back for the apex, it stops looking for anything else. That means your MX records vanish instantly. Mail servers can’t find where to deliver messages, and all inbound email drops into a black hole.
If you’re splitting mail handling across different hostnames, check out how we route subdomain email with custom MX records in Namecheap without touching root records.
When to Pick an A Record
An A record points a hostname straight to a fixed 32-bit IPv4 address (like 198.51.100.42). Unlike a CNAME, an A record plays nicely with MX, TXT, and NS records on the apex.
Go with an A record if:
- Your host gives you a dedicated, static IPv4 address that won’t change on a whim.
- You run your own VPS or dedicated box on DigitalOcean, Linode, or Hostinger.
- You run mail, SPF, and DKIM on the apex and want crystal-clear, zero-ambiguity DNS answers.
The catch is flexibility. If your provider relocates your VPS to a different rack or subnet, or you run ephemeral instances behind an autoscaling load balancer, that A record points to a dead IP until you manually update it in Namecheap.
Why CNAME Fails on Root and How Namecheap Replaces It
PaaS hosts and edge platforms rarely hand out static IPs. They sit behind dynamic, geo-distributed anycast networks. They ask for a CNAME because their edge IPs shift constantly to mitigate DDoS attacks and balance regional traffic.
Since the DNS spec outlaws standard CNAMEs at the apex, Namecheap works around it with an internal pseudo-record called the ALIAS Record.
To you, an ALIAS record looks and acts like a CNAME. But to the outside world, it looks like an A record. When someone’s browser asks Namecheap for example.com, Namecheap queries the upstream target hostname on its own servers, grabs the resolved IP, and hands back a standard A record. This trick is called CNAME flattening.
For a step-by-step breakdown of that specific setup, see our guide on how to point a root domain to a CNAME in Namecheap with ALIAS.
Step-by-Step: Configuring an A Record on Namecheap
If your web host handed you a fixed IPv4 address, an A record is the fastest, cleanest approach. Here is how to wire it up without wrecking existing records.
1. Clean Out Conflicting Root Records
Log in to Namecheap, go to your Domain List, find the domain, and hit Manage. Click over to the Advanced DNS tab.
Scan through the Host Records table. Before touching anything, delete existing records where the host is @ and points to old parking IPs or default URL Redirects. Leaving orphan records on @ causes intermittent resolution headaches that are a pain to debug.
2. Add the New A Record
Click Add New Record at the bottom of the table and enter:
- Type: A Record
- Host: @
- Value: Your server’s IPv4 address (e.g.,
192.0.2.1) - TTL: Automatic (or 5 min while testing)
Click the green checkmark to save. If your host also gave you an IPv6 address, add a companion AAAA Record with @ as the host and paste the 128-bit address.
If you’re deploying preview environments or multi-tenant apps on the same domain, look into setting up a wildcard subdomain DNS in Namecheap so new subdomains resolve automatically.
Step-by-Step: Configuring an ALIAS Record for Cloud Hosts
When you’re pushing code to Vercel, Render, or GitHub Pages and they give you a hostname instead of a static IP, use Namecheap’s ALIAS record.
1. Remove Conflicting Apex Records
In the Advanced DNS panel, check your Host Records. You cannot run an active A record and an ALIAS record on the @ host simultaneously. If there’s an old A record sitting there from a previous host, delete it first.
2. Insert the ALIAS Entry
Click Add New Record and set:
- Type: ALIAS Record
- Host: @
- Value: The target domain from your hosting provider (e.g.,
dns-edge.example-platform.com) - TTL: Automatic
Don’t add a trailing dot to the target domain in Namecheap. The dashboard takes care of the zone formatting behind the scenes.
The Canonical WWW Pattern: The Safest Production Alternative
Most high-traffic production apps avoid the apex headache altogether. Instead of serving production web traffic directly on the naked root, they make www.example.com the canonical home of the app and redirect the bare domain (example.com) to www.
Why bother? Two main reasons:
- The
wwwsubdomain has no RFC baggage. You can slap a normal CNAME onwwwall day long without touching MX records or violating specs. - Cookies set on the bare root domain trickle down to every single subdomain by default. Running your main app on
wwwkeeps session and auth cookies from leaking to static asset or API subdomains.
If you want to keep parts of your infrastructure separate, you can also point a Namecheap subdomain to Hostinger without touching the main site.
How to Implement the WWW Canonical Redirect in Namecheap
Setting this up in Namecheap takes two records:
- Add a CNAME Record with Host
wwwand Value set to your cloud host’s target domain. - Add a URL Redirect Record with Host
@, Valuehttps://www.example.com, and pick 301 Permanent Redirect.
Whenever a visitor types your naked domain into their browser, Namecheap’s edge proxies handle the 301 redirect and send them straight to www, where your standard CNAME handles traffic smoothly.
Verifying DNS Resolution with the Terminal
Never rely on a browser window to test DNS changes. Local OS resolvers and browser caches will mislead you every time. Query public resolvers directly with dig.
Here is what I run to inspect an apex domain hooked up via an ALIAS record:
# Query Cloudflare's resolver for the root domain A record
dig @1.1.1.1 example.com A +short # Query Google's resolver with full trace information
dig @8.8.8.8 example.com +noall +answer # Inspect HTTP redirect headers if using the 301 redirect pattern
curl -I -s https://example.com | grep -E "HTTP/|Location:"Notice something important: dig won’t show a CNAME record here. You will see an immediate A answer containing the IP Namecheap resolved from the upstream host. If you get back nothing or see stale IPs, skip the caching layer and query Namecheap’s nameservers directly:
# Query Namecheap authoritative nameservers directly
dig @dns1.registrar-servers.com example.com A +shortFor more background on standard DNS lookups, check out MDN Web Docs on Web Mechanics or read through the Namecheap Knowledge Base for Host Records.
Gotcha: Silent Email Failures from Stray Apex CNAMEs
I saw this happen during a client migration last month. A dev tried to get around the root domain restriction by setting a standard CNAME on @ in an external DNS tool, then imported the raw zone file into Namecheap. The UI accepted it without an error.
Two hours later, every inbound email bounced. Because the apex had a raw CNAME, Google Workspace’s inbound mail agents got that CNAME answer when looking up example.com MX (per RFC 2181 Section 10.1). The mail agents treated the MX records as non-existent and threw 550 5.1.1 bounce errors back to senders.
If you care about email landing in inboxes, don’t try to hack a raw CNAME onto @. Use an A record, Namecheap’s ALIAS record, or the www redirect pattern.
Comparison Matrix: A Record vs CNAME vs ALIAS
Here is a quick cheat sheet for picking the right record for your root setup:
- A Record: Best for static VPS or dedicated IPs. Fully compliant on apex. Doesn’t conflict with MX or TXT records. Downside: requires manual updates if the IP changes.
- CNAME Record: Great for subdomains (
www,api). Forbidden on the root (@) by RFC specs. Will knock your email offline if forced. - ALIAS Record: Namecheap’s workaround for pointing the root to cloud hostnames. Flattens to an A record at lookup time. Completely safe for MX records.
- URL Redirect (301): Namecheap’s HTTP-level redirect. Ideal if you run your real site on
wwwand just want apex visitors forwarded .
Frequently Asked Questions
Can I have both an A record and an ALIAS record for the root domain?
No. Both return an IPv4 answer for the @ host. If you keep both, Namecheap responds with mixed results, sending half your users to the old server and the other half to your new host. Wipe the old A record before saving the ALIAS.
Why doesn’t dig show an ALIAS record type?
ALIAS isn’t an official DNS record type defined by IETF specs. It’s an internal feature of Namecheap’s nameservers. When a query comes in, Namecheap resolves the destination behind the scenes and returns regular A records. That is all dig will ever see.
How long does it take for Namecheap ALIAS records to update?
With TTL set to Automatic, changes usually roll across Namecheap’s global nameservers in 5 to 30 minutes. If your cloud host shifts its edge IPs, Namecheap re-resolves the upstream record based on your host’s TTL.
Does an ALIAS record slow down initial page loads?
There’s a tiny lookup penalty (roughly 15 to 40 ms) on the very first query if Namecheap’s authoritative server doesn’t have the target cached. After that, it serves the cached IP and latency matches a standard A record.
Next Steps
With your root domain pointed in the right direction without violating DNS specs, make sure your email auth is locked down. If you send transactional or business emails, read our guide on configuring SPF, DKIM, and DMARC in Namecheap Advanced DNS to keep your messages out of the spam folder.
