This domain's own sibling lesson (in Domain Names, DNS & Subdomains) covers the general pattern every platform uses to solve the apex-domain problem. This lesson is the specific, concrete walkthrough of what that pattern actually looks like on Vercel, step by step.
3 min read
Apex domain (example.com): A record → 76.76.21.21
www subdomain (www.example.com): CNAME → cname.vercel-dns.com
Adding a custom domain in Vercel's dashboard produces exactly two instructions, depending on whether it's an apex domain or a subdomain: the apex gets a specific A record pointing at Vercel's own anycast IP (the same IP for every Vercel customer — Vercel's infrastructure figures out which actual deployment to serve based on the Host header in the incoming request, not the IP itself), and www (or any other subdomain) gets a CNAME pointing at cname.vercel-dns.com.
This is the exact same trick Domain Names & DNS's own lesson on the apex-CNAME problem describes in general terms — Vercel's edge servers receive every request to 76.76.21.21 and use the Host header (example.com vs. someone-elses-site.com) to route it to the correct customer's deployment internally. This is why adding the A record alone is never sufficient on its own without Vercel's dashboard also recognizing that domain as assigned to your specific project — the IP is shared infrastructure; the domain-to-project mapping lives in Vercel's own configuration, not in DNS.
Before Vercel serves traffic for a domain, it needs to confirm you actually control it — this is usually satisfied automatically once the A/CNAME records above are detected pointing correctly at Vercel, but for a domain already in use elsewhere (or one Vercel can't yet see DNS changes for), a TXT record verification step may be required instead: Vercel gives you a specific string to add as a TXT record, and once detected, ownership is confirmed without needing to wait for the A/CNAME change to fully propagate first.
Once Vercel detects the domain correctly pointing at its infrastructure, it automatically issues a TLS certificate (via Let's Encrypt, the same ACME-based automated issuance Networking Fundamentals' own HTTPS/TLS lesson referenced) — no separate certificate request, no manual renewal to remember, ever. This usually happens within minutes of DNS propagating correctly; if HTTPS doesn't activate promptly, the far more common cause is the DNS change itself not having propagated yet (Domain Names & DNS's own TTL/propagation lesson covers exactly this), not a certificate-issuance problem.
Vercel's dashboard lets you designate either the apex or www as the canonical URL, automatically redirecting the other to it — this is a deliberate choice with real SEO and consistency implications (search engines and shared links should consistently resolve to one canonical form), covered in depth from the general, platform-agnostic angle in Domain Names & DNS's own subdomain-strategy lesson.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why do all of Vercel's customers' apex domains point at the same shared A record IP address?
2. What's the most likely cause if HTTPS doesn't activate promptly after adding a custom domain?
3. When might Vercel require a TXT record for domain verification instead of relying on the A/CNAME records alone?
Vercel