What Is DNS CNAME Record?

Why It Matters

CNAME records are the backbone of how domain forwarding services work. When you set up Domain Forward (or any redirect service), you typically point your www subdomain to the service using a CNAME record. The service then handles the actual redirect logic.

Understanding CNAME records helps you avoid the most common DNS mistakes that cause forwarding to break — like trying to add a CNAME to your root/apex domain (which doesn’t work) or accidentally overwriting records that your email depends on (see: MX record).

Roughly 35% of support conversations at Domain Forward involve DNS confusion. Knowing how CNAME records work eliminates most of that friction.

How It Works

A CNAME record creates a chain of DNS lookups:

1. A visitor types www.example.com in their browser
2. The browser asks DNS to resolve www.example.com
3. DNS finds a CNAME record: www.example.com → redirect.domain-forward.com
4. DNS then resolves redirect.domain-forward.com to an IP address (via its A record)
5. The browser connects to that IP address
6. Domain Forward’s servers see the request for www.example.com and execute the configured redirect

The key detail: a CNAME record doesn’t redirect anything by itself. It only tells DNS “this domain is an alias for that domain.” The actual redirect (301/302 with a Location header) happens at the HTTP level, handled by the server at the other end.

CNAME vs A Record for Domain Forwarding

	CNAME Record	A Record
Points to	Another domain name	An IP address
Works on root domain	No (RFC restriction)	Yes
Works on subdomains	Yes	Yes
Handles IP changes	Automatically (follows target)	Requires manual update
Common use	www and subdomains	Root domain (@)

For domain forwarding, a typical setup uses both: an A record for the root domain (example.com) and a CNAME record for the www subdomain (www.example.com).

Common Mistakes

Adding a CNAME to the root domain. This is the #1 DNS mistake. It violates the DNS spec and most providers will either reject it silently or create conflicts with your MX records (breaking email). For root domains, use an A record pointing to Domain Forward’s IP or an ALIAS record if your provider supports it.

Confusing CNAME with redirect. A CNAME doesn’t redirect — it aliases. www.example.com CNAME redirect.domain-forward.com doesn’t send visitors to redirect.domain-forward.com. It makes www.example.com resolve to the same IP, and the server there handles the redirect. The visitor’s browser still shows the original domain until the HTTP redirect happens.

Setting TTL too high before making changes. If your CNAME has a 24-hour TTL and you change it, the old value is cached everywhere for up to 24 hours. Lower the TTL to 300 seconds (5 minutes) before making changes, wait for the old TTL to expire, then make the switch.

Forgetting that CNAME flattens everything. If you set shop.example.com as a CNAME, you can’t also add an MX record, TXT record, or any other record for shop.example.com. The CNAME “takes over” the entire name. This is fine for forwarding purposes but important to know.

How Domain Forward Handles CNAME Records

Domain Forward’s DNS setup is designed to be CNAME-friendly and mistake-proof:

• Auto-detection: We detect your registrar and show the exact CNAME record to add, with copy-paste values.
• Root domain handling: Since CNAME can’t be used on apex domains, we provide an A record for the apex and a CNAME for www — both explained step by step.
• Wildcard support: Add a single *.example.com CNAME record to forward all subdomains at once. Each gets its own SSL certificate automatically.
• Propagation monitoring: Our dashboard shows whether DNS has propagated, so you know exactly when your redirect is live.
• No conflict with email: We never touch MX records. Our guides explicitly show which records to add and which to leave alone.