An eight-step DNS walkthrough covering apex vs www, the A and CNAME records Vercel expects, the redirect direction, SSL provisioning, and the registrar-specific traps that send the “just point your domain at us” promise sideways.
Methodology. This tutorial synthesizes Vercel’s official documentation as of May 2026, including the domain-configuration pages at vercel.com/docs/projects/domains and the redirect reference at vercel.com/docs/edge-network/redirects. DNS provider screenshots may differ from your registrar; the underlying record types (A and CNAME) are the same everywhere. For the broader cost picture see Vercel pricing explained.
Adding a custom domain to a Vercel deployment is the moment your project stops being a preview URL and starts being a real product. The mechanics are simple: add the domain in Vercel, add two DNS records at your registrar, pick a canonical hostname, wait for SSL. The reason the average solo founder loses an afternoon on it is that DNS is unforgiving — one stale cache, one Cloudflare proxy toggle, one CAA record left over from a previous host, and the whole thing fails silently. This walkthrough covers the canonical pattern from Vercel’s docs adapted for the most common solo-SaaS setup, plus the eight or nine traps that account for almost every “why isn’t my domain working” ticket on the support forums.
Open your project in the Vercel dashboard, then go to Settings → Domains. Click Add, type your domain (the apex form, e.g. your-saas.com, without www. and without https://), and submit. Vercel will create entries for both the apex and the www subdomain by default and tell you which DNS records to add.
The screen you land on will show one of two states. If your domain already points at Vercel’s nameservers (because you bought the domain through Vercel itself), most of the configuration is automatic and you can skip ahead to step 5. If your domain is registered elsewhere — Namecheap, Google Domains’ successor, Porkbun, Cloudflare, GoDaddy — you’ll see explicit DNS instructions you have to apply at the registrar. The vast majority of solo founders are in the second camp, because nobody wants to migrate their entire domain portfolio to a hosting provider just for one project.
Vercel’s domain panel will show a status indicator next to each hostname: Invalid configuration, Valid configuration, or Pending. You’re aiming for two green “Valid” statuses — one for apex, one for www. Until both go green, your domain isn’t live.
Before you touch DNS, decide which version of your domain is canonical. You have two real choices:
your-saas.com is the primary, www.your-saas.com redirects to it. This is the modern default and what most consumer brands ship.www.your-saas.com is the primary, your-saas.com redirects to it. This is what we use on this site (www.promptstoproduct.com) and what Vercel itself recommends in their docs for any non-trivial deployment.Vercel’s recommendation skews toward www-canonical for a technical reason: apex domains can’t use CNAME records (per the original DNS spec), which means apex hosts don’t play nicely with CDN-style flexibility. Pointing a CNAME at cname.vercel-dns.com from www means Vercel can rotate underlying IPs without your DNS breaking. Pointing an A record at 76.76.21.21 from apex works, but if Vercel ever changes that anycast address (rare, but possible), apex users feel it. The www-canonical setup is more resilient.
The SEO implication is one you decide once and live with: Google treats your-saas.com and www.your-saas.com as separate URLs unless you redirect one to the other and consolidate the canonical signal. Whichever you pick, do it consistently — canonical tags, sitemap entries, internal links, OG tags, and the redirect direction must all line up. Mixing them causes split link equity and duplicate-content quirks in Search Console.
For a brand-new SaaS without existing inbound links, either choice is defensible. For this tutorial, we’ll proceed with www-canonical, because that’s the configuration Vercel itself documents and what most agency-built Next.js SaaS apps end up shipping in 2026.
For www-canonical, you’re adding exactly two records at your registrar. Vercel’s domain panel shows you these in plain English; the record values are stable across projects because Vercel uses anycast.
Record 1 (apex) Type: A Host: @ (or your-saas.com) Value: 76.76.21.21 TTL: 3600 (or Auto) Record 2 (www subdomain) Type: CNAME Host: www Value: cname.vercel-dns.com TTL: 3600 (or Auto)
The 76.76.21.21 address is Vercel’s anycast endpoint — a single IP that resolves to the nearest Vercel edge location regardless of where the user is. The cname.vercel-dns.com CNAME does the same thing one DNS layer up; it lets Vercel re-point traffic without needing every customer to update an A record.
If you’ve picked apex-canonical instead, the records are identical — you still need both. The only thing that changes is the redirect direction (covered in step 5), not the DNS itself.
One thing not to add: an A record for www. Vercel’s recommendation is CNAME for the subdomain. Some registrars try to be helpful and auto-create an A record for www when you add an apex A record — delete the auto-created one and replace it with the CNAME. Two competing records on the same hostname is a recipe for intermittent failures.
The exact UI varies by registrar, but the flow is the same: find the DNS or zone-editor section, add the two records above, save. A few registrar-specific notes that catch people:
If your domain’s nameservers are Cloudflare’s (because you proxy traffic through Cloudflare for caching, WAF, or DDoS protection), you have an extra step. After adding the A and CNAME records, turn off the orange-cloud proxy for both. Set the proxy status to “DNS only” (gray cloud). With proxy on, Cloudflare terminates SSL itself and Vercel can’t provision Let’s Encrypt certs — the verification handshake fails because Cloudflare intercepts it. The symptom is your domain panel showing “Invalid configuration” or SSL stuck pending forever. Gray-cloud the records and wait five minutes; Vercel completes verification, issues the cert, and you’re live.
These two are the simplest path. Add the records exactly as shown; their UI matches the field names Vercel uses. TTL of “Automatic” is fine.
GoDaddy’s DNS UI is quirky — the apex record is entered with host @, and the existing “Parked” A record GoDaddy auto-creates needs to be deleted before your new one will resolve. Check for any leftover records pointing to GoDaddy’s parking IPs (76.223.105.230 or similar) and delete them.
If you bought the domain through a platform that also wants to host it, you may have to actively detach the domain from their hosting layer before Vercel can serve it. Check for any “Connect this domain to” toggles in the platform settings and clear them.
After saving the records, DNS takes anywhere from 30 seconds to 48 hours to propagate. In practice, with a TTL of 3600 (one hour), you usually see propagation inside 5–15 minutes for most DNS resolvers globally. The Vercel panel polls in real time and updates the status indicators when records resolve.
You now have both your-saas.com and www.your-saas.com resolving at Vercel. By default, Vercel will serve the same project on both — which is exactly what you don’t want. Pick one as canonical (we picked www in step 2) and configure the redirect.
The easiest way is the Vercel UI: in Settings → Domains, click the apex domain (your-saas.com), and find the “Redirect to” option. Set it to redirect to www.your-saas.com with a 308 (permanent). Save. That’s it — Vercel handles the redirect at the edge.
If you want to keep the configuration in code (recommended; it survives project rebuilds and works for preview deployments), use vercel.json at the repo root:
{
"redirects": [
{
"source": "/:path*",
"has": [
{
"type": "host",
"value": "your-saas.com"
}
],
"destination": "https://www.your-saas.com/:path*",
"permanent": true
}
]
}
This redirects every path on the apex to the same path on www, with a 301/308 status. The permanent: true flag tells search engines to treat the destination as the canonical URL going forward.
For apex-canonical setups, swap the host check and destination. The pattern is identical — just reversed.
Once DNS resolves, Vercel automatically requests a Let’s Encrypt certificate for both hostnames. This is usually done in 5–30 minutes. The domain panel shows a small lock icon next to each hostname when SSL is live.
If SSL is stuck pending for more than an hour, you have a problem. The most common causes:
dig CAA your-saas.com — if you see a record listing only one CA and it isn’t Let’s Encrypt, delete the record or add an explicit allow for letsencrypt.org.Once SSL is provisioned, you don’t have to touch it again. Let’s Encrypt certs auto-renew via Vercel’s ACME automation; the rotation is invisible to you and your users.
Before you tell the world, verify everything resolves correctly. The three tools that matter:
dig your-saas.com +short # expect: 76.76.21.21 dig www.your-saas.com +short # expect a CNAME chain ending at a Vercel edge IP whois your-saas.com | grep -i "name server" # confirms which registrar's nameservers are authoritative curl -I https://www.your-saas.com # expect: HTTP/2 200 with a valid certificate curl -I https://your-saas.com # expect: HTTP/2 308 with a Location header pointing at www
The real-browser test is non-negotiable. Open an incognito window (no cached redirects, no cached DNS, no service workers from a previous deployment). Visit both https://your-saas.com and https://www.your-saas.com. Confirm:
your-saas.com/pricing and confirm it lands on www.your-saas.com/pricing with a 308If everything looks good in incognito but broken in your normal browser, that’s a stale cache — clear it or wait. If everything looks good in your browser but broken on a phone or for a friend, that’s DNS still propagating — check whatsmydns.net for a global view.
Your laptop, your router, your ISP, and your browser all cache DNS independently. After changing records, what you see in your own browser is often the most-stale version. Use dig against an external resolver (dig @8.8.8.8 your-saas.com) or check whatsmydns.net to see what the rest of the internet is actually getting.
If you previously hosted on a provider that added IPv6 AAAA records, those records may still exist alongside your new A record. IPv6-capable resolvers prefer AAAA, which means a chunk of your traffic will hit the old host. Run dig AAAA your-saas.com — if anything comes back, delete those records or update them.
This trap is the most under-documented. Some registrars or previous hosts add a CAA record that explicitly names a CA (e.g., 0 issue "digicert.com"). With that record present, Let’s Encrypt is forbidden from issuing certs, and Vercel’s SSL provisioning silently fails. Delete the CAA record or add a permissive one for Let’s Encrypt.
Brand-new domains sometimes ship with a registrar parking page on a hidden A record you can’t see in the standard zone editor. The symptom is intermittent results: sometimes you hit Vercel, sometimes you hit a parking page. Contact registrar support and ask them to fully clear all default records.
You set up www-canonical at the DNS layer but your app/layout.tsx still has a canonical URL pointing at the apex. Search engines see the conflict and pick one arbitrarily. Audit your canonical tags, OG URLs, sitemap entries, and internal links for consistency. The Next.js deployment guide covers the metadata side of this.
If you also use the apex domain for email (e.g., MX records pointing at Google Workspace or Fastmail), check that adding the A record at 76.76.21.21 doesn’t conflict with anything email-related. The A record is for HTTP traffic; MX records handle email separately and don’t conflict in principle — but some registrar UIs auto-modify MX records when you change apex DNS, which silently breaks email.
Pointing a custom domain at Vercel is two DNS records, one redirect rule, and a 30-minute wait for SSL. Most of the failure modes are upstream traps — Cloudflare proxy, CAA records, stale AAAA, registrar parking pages — rather than anything Vercel-specific. Do the eight steps in order, verify with dig and incognito, and ship.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.