You ship an app to AWS, Fly.io, or Heroku, and instead of a clean static IP, you get handed an auto-generated target like dualstack.my-alb-1234.us-east-1.elb.amazonaws.com. Try dropping a standard CNAME on your apex domain (@), and your DNS zone blows up immediately.
Namecheap solves this with ALIAS records. Here is how to wire your naked root domain to a third-party hostname target without breaking your MX records or violating DNS specs, plus how to verify the resulting synthetic A records straight from your terminal.
Why RFC 1034 Breaks Naked Domain CNAME Records
The DNS spec in RFC 1034 is brutally clear: if a node has a CNAME record, it cannot hold any other record types. That’s a massive issue for your root domain (the zone apex, naked domain, or @) because it must have SOA (Start of Authority) and NS (Nameserver) records just to function. Point a CNAME at @, and recursive resolvers will drop queries or refuse to resolve your mail servers.
That rule made total sense back when websites sat on single bare-metal boxes with static IPv4 addresses. It falls apart completely on modern cloud platforms that balance traffic across dynamic IP pools. If your host rolls their load balancer IPs and you had hardcoded four static A records to the apex, your site drops offline with zero warning.
DNS providers worked around this by inventing pseudo-records. Cloudflare calls it CNAME Flattening, AWS Route 53 calls it an Alias, and DNSimple calls it an ALIAS or ANAME record. Namecheap has built-in ALIAS Record support right in both BasicDNS and PremiumDNS dashboards.
How Namecheap Implements ALIAS Records Behind the Scenes
An ALIAS record isn’t an official IETF DNS record type. You’ll never see an ALIAS record returned in raw wire-format DNS packets over port 53. It’s an internal server-side trick handled inside Namecheap’s authoritative nameservers.
When you point an ALIAS record at @ to target.hostingprovider.com, Namecheap does the heavy lifting for you:
- A client asks Namecheap for the A record of
yourdomain.com. - Namecheap’s authoritative nameserver catches the request.
- Instead of passing back a CNAME, Namecheap resolves the upstream target (
target.hostingprovider.com) behind the scenes. - It pulls the active IPv4 and IPv6 addresses from that lookup.
- It synthesizes genuine, ordinary A and AAAA records on the fly and sends those back to the client’s resolver.
Because the resolver gets clean A records, the lookup fully adheres to RFC rules. Your NS, SOA, and MX records stay completely untouched. If you run email through your root domain, you can safely point Namecheap DNS to your host without breaking email while keeping an ALIAS pointed at your web app.
Step-by-Step: Adding an ALIAS Record in Namecheap Advanced DNS
First, verify your domain actually runs on Namecheap BasicDNS or Namecheap PremiumDNS. If you pointed your domain at external nameservers, changing entries in Namecheap won’t do a thing. Double-check this by reviewing how you set up custom nameservers on Namecheap.
Step 1: Clear Out Conflicting Apex Records
Log in to Namecheap, head to your Domain List, hit Manage next to the domain, and open the Advanced DNS tab.
Scan through the Host Records table. Before adding an ALIAS record to the apex, strip out any records attached to @ that might collide:
- Delete any existing A Record with Host
@(especially default parking IPs like198.54.115.1). - Delete any existing AAAA Record with Host
@. - Delete any URL Redirect Record where Host is
@.
Leave your TXT verification records and MX records alone. They won’t interfere with your new ALIAS record.
Step 2: Create the ALIAS Record
Click the red Add New Record button under the table. Fill out these fields:
- Type: Pick
ALIAS Record. - Host: Type
@. - Value: Paste your target hostname (like
myapp.fly.devor your AWS ALB hostname). - TTL: Set it to
Automatic(or drop it to1 minwhile testing).
Click the green checkmark to save. Namecheap updates its internal zone within seconds, though downstream public resolvers usually need a few minutes to flush their cache.
Handling MX and TXT Records Alongside Your Apex ALIAS
Email deliverability is usually why developers end up needing ALIAS records in the first place. If you run Google Workspace, Fastmail, or custom mailboxes, your apex domain requires functional MX, SPF, and DKIM records.
Because Namecheap flattens the ALIAS record into regular A records before replying to the world, queries for MX yourdomain.com don’t hit the CNAME dead-end. The query resolves your MX records without any fuss.
Keep your SPF TXT record parked directly on @ so outbound mail doesn’t fail DMARC. If you use Namecheap’s own email hosting, make sure you correctly set up Namecheap Private Email MX, SPF, and DKIM records right inside this table.
A clean Host Records table running both web traffic and mail looks like this:
ALIAS Record| Host:@| Value:target-host.examplecloud.com| TTL: AutomaticCNAME Record| Host:www| Value:target-host.examplecloud.com| TTL: AutomaticTXT Record| Host:@| Value:v=spf1 include:spf.eforward.namecheap.com ~all| TTL: Automatic
Verifying the Configuration with Dig and Curl
Don’t test this in a browser right away. Browsers cache DNS aggressively and hide resolution bugs behind SSL or redirect errors.
Jump straight into your terminal and query Namecheap’s nameservers directly with dig to skip your local resolver’s cache.
Query one of Namecheap’s authoritative nameservers for your domain:
dig @dns1.registrar-servers.com example.com A +noall +answerLook at the answer section: you should get clean A records, not an ALIAS or CNAME type. Here’s what it looks like when resolving through an ALIAS mapped to an AWS ALB:
; <> DiG 9.10.6 <> @dns1.registrar-servers.com example.com A +noall +answer
; (1 server found)
;; global options: +cmd
example.com. 60 IN A 52.22.145.89
example.com. 60 IN A 54.160.22.114Namecheap queried the ALB hostname upstream, grabbed the active IPs (here: 52.22.145.89 and 54.160.22.114), and served them up as standard A records. Next, verify your MX records to make sure mail isn’t broken:
dig @dns1.registrar-servers.com example.com MX +noall +answerIf your MX records show up with their priorities intact, email is safe. Now fire an HTTP request to make sure the target platform accepts the traffic:
curl -I https://example.comLook at the HTTP response code. If you see TLS or 404 errors, check that you actually added example.com to your hosting platform’s custom domain settings so its ingress router knows what to do with the Host header.
The Dynamic IP Gotcha: TTL Desync with Cloud Load Balancers
ALIAS records solve the CNAME apex limitation, but they introduce an edge case that bit me hard on production traffic: TTL Desync.
When you point an ALIAS record to an AWS ALB or a platform like Fly.io, the cloud provider frequently rotates underlying IP addresses during scaling events or node replacements. AWS uses a strict 60-second TTL on ALB hostnames.
Here is what happens during a desync:
- Namecheap resolves your ALB target to IPs
AandB, caching them in its internal resolver. - AWS spins down node
Band spins up nodeC. - If Namecheap serves the stale cached IP
Bto clients even a few minutes past its expiration, users hitting your apex domain get stuck with connection timeouts (ERR_CONNECTION_TIMED_OUT).
I ran into this on a busy staging cluster: www.example.com (which used a standard CNAME pointing straight to the ALB) resolved flawlessly, while example.com threw intermittent 504s for about 10 minutes until Namecheap refreshed its internal lookup pool.
If your target cycles IPs rapidly, keep the TTL set to 1 min or Automatic in Namecheap. If you run massive microservices needing sub-minute failovers, registrar DNS might not cut it, and you’ll eventually want a dedicated DNS provider like Route 53 or Cloudflare.
Alternative Setup: The WWW CNAME + 301 Apex Redirect Pattern
If you don’t want to worry about TTL desync on dynamic load balancers, the standard alternative is running your live app on the www subdomain and redirecting the apex.
The flow looks like this:
www.example.comuses a native CNAME record pointing to your cloud target. Resolvers query your cloud host directly, always getting fresh IPs.example.comruns an HTTP 301 redirect forwarding visitors tohttps://www.example.com.
In Namecheap, you set this up by swapping the ALIAS record for a URL Redirect Record:
Type: URL Redirect Record
Host: @
Value: https://www.example.com/
Unmasked / Permanent (301)And pair it with a CNAME for www:
Type: CNAME Record
Host: www
Value: myapp.fly.dev.
TTL: AutomaticThere’s a catch with Namecheap’s native URL Redirect: its internal redirect engine doesn’t handle Let’s Encrypt certificates very reliably for apex HTTPS traffic. If someone types https://example.com directly into their address bar, they might hit an SSL certificate warning before the redirect even triggers. An ALIAS record pointing to your cloud edge—where SSL terminates cleanly—avoids that headache entirely.
Troubleshooting Common Namecheap ALIAS Failures
If your ALIAS setup isn’t resolving after 10 or 15 minutes, check for these three traps.
1. Trailing Dot Formatting in the Value Field
In raw zone files, fully qualified domain names require a trailing period (like target.hosting.com.). If you leave it off, some systems accidentally append your own domain, creating something like target.hosting.com.example.com.
Namecheap’s dashboard UI usually handles trailing dots automatically, but pasting from clipboard can sometimes sneak one in. If resolution fails, check the Value field, strip off any trailing period, save, and test again with dig.
2. Overlapping A or AAAA Records
Namecheap won’t always warn you if you save overlapping records. If an old parking A record for @ is still sitting in the table alongside your new ALIAS record, Namecheap serves both the old parking IP and your cloud IPs in round-robin order.
Check for stray records:
dig example.com A +shortIf an unknown IP shows up in the response, track it down in your Namecheap records list and kill it.
3. The Host Field Contains the Full Domain Name
A classic Namecheap dashboard misstep: pasting your whole domain into the Host field instead of @. If your domain is domain.com and you put domain.com as the Host, Namecheap generates a record for domain.com.domain.com.
The root domain in Namecheap Advanced DNS should always be just @.
Namecheap Apex DNS FAQ
Does Namecheap charge extra for ALIAS records?
No. ALIAS records are completely free on both Namecheap BasicDNS and PremiumDNS.
Can I point an ALIAS record to an IP address?
No. If you have an IP address, use an A Record (for IPv4) or an AAAA Record (for IPv6). ALIAS records require a fully qualified domain name target.
Does an ALIAS record support wildcards?
You can technically put * in the Host field, but you shouldn’t. Wildcards are fully RFC-compliant on standard subdomains using native CNAMEs. If you need dynamic subdomains with SSL, follow our guide on configuring wildcard subdomains with Certbot DNS challenge.
Will using an ALIAS record slow down my website performance?
Not for your visitors. Their browsers query ordinary synthesized A records from Namecheap’s nameservers. The only lookup delay happens between Namecheap and your cloud target when Namecheap needs to refresh its cached IP set.
Next Steps
Once your apex ALIAS and www CNAME resolve to your provider, confirm your app correctly provisions and renews SSL certificates across both hostnames. If your platform sits behind an extra CDN or proxy layer, check your edge caching rules to ensure headers pass through cleanly.
