Vercel Custom Domain Setup for Your SaaS | Coding Capybaras

Photo by Growtika on Unsplash

To set up a custom domain on Vercel for your SaaS, you add the domain to your project under Settings → Domains, then point your DNS at Vercel — an A record (76.76.21.21) for an apex domain like example.com, or a CNAME (cname.vercel-dns-0.com) for a subdomain like www. Vercel verifies the records and automatically provisions an SSL certificate within a few minutes. The whole thing takes about ten minutes of clicking plus some waiting on DNS propagation. The part nobody tells you about — getting hello@yourdomain.com working — is a separate, free step you do with email routing. This guide covers both.

TL;DR

• Add your domain in Vercel under Settings → Domains, then configure DNS at your registrar.
• Apex domains use an A record (76.76.21.21); subdomains use a CNAME (cname.vercel-dns-0.com). Always run the inspect step to get your project's exact values.
• SSL is automatic — Vercel provisions the certificate after DNS verification succeeds.
• Add both example.com and www.example.com, then redirect one to the other.
• Email on your domain is separate from web hosting. Cloudflare Email Routing forwards you@yourdomain.com to your real inbox for free.

What you need before you start

A custom domain replaces the your-project.vercel.app URL Vercel gives every deployment with something that looks like a real business: codingcapybaras.com instead of a generated subdomain. It's the cheapest credibility upgrade you'll make, and it's a prerequisite for proper email and SEO.

Three things need to be true before you begin.

First, you own a domain. If you don't yet, you can register one through Vercel directly or any registrar — Namecheap, Cloudflare, Porkbow, Google's successor registrars. Where you bought it matters only because that's where you'll edit DNS.

Second, your SaaS is already deployed to Vercel and you can open its project in the dashboard. The custom domain attaches to a specific project, so the project has to exist first.

Third, you know where your domain's DNS is managed. Usually that's your registrar, unless you've already pointed your nameservers somewhere like Cloudflare. This determines where you add records, and it's the single most common source of confusion — people add the right record in the wrong place and then wonder why nothing resolves.

If you're still deciding whether Vercel is the right host at all, I compared it head-to-head in Vercel vs Netlify vs Railway. For most non-tech founders shipping a Next.js SaaS, Vercel's the path of least resistance — which is also why it pairs cleanly with the rest of the Next.js + Supabase + Stripe + Resend stack.

How do you add a custom domain on Vercel?

The dashboard flow is the one most founders should use — it's visual and it tells you exactly what records to create. Here's the sequence, drawn from Vercel's official guide.

Open your project in the Vercel dashboard, then go to Settings → Domains in the sidebar. Click Add Domain and type the domain you want — say example.com. When you add an apex domain, Vercel prompts you to add the www prefix too; accept that, because you want both.

Vercel then shows you the DNS configuration to apply. What it shows depends on the type of domain:

• For an apex domain (example.com), you add an A record pointing at Vercel's IP.
• For a subdomain (www.example.com or app.example.com), you add a CNAME record. Each project gets a unique CNAME value, something like d1d4fc829fe7bc7c.vercel-dns-017.com.
• Either type can instead be configured by delegating nameservers to Vercel.

Take those values to wherever your DNS lives and create the records. On most registrars that's a "DNS" or "Advanced DNS" tab, an "Add record" button, and a small form: type, name/host, value. For the apex A record, the host is usually @; for www, the host is www.

If your domain is already in use by another Vercel account, you'll be asked to verify access with a TXT record first. That doesn't move the domain — it just proves you control it so you can use it in your project.

A note from Vercel's docs that bites people: if you verify by switching nameservers to Vercel, you must re-add any DNS records you wanted to keep from your old provider — including email records. More on that below, because it's exactly how founders accidentally break their email.

Once the records are live and Vercel detects them, the domain's status in the dashboard flips to configured. That's the web side done.

Apex vs subdomain vs nameservers: which method?

There are three ways to connect a domain to Vercel, and the right one depends on your setup. Here's the comparison, with the tradeoffs that actually matter.

| Method | What you set | Best for | Watch out for | | --- | --- | --- | --- | | A record (apex) | @ → 76.76.21.21 | Root domain example.com | Apex can't be a CNAME by spec; use the A record | | CNAME (subdomain) | www → cname.vercel-dns-0.com | www, app, docs subdomains | Use your project's exact CNAME from the inspect step | | Vercel nameservers | Point registrar NS to Vercel | Wildcards, all-in-one DNS at Vercel | You must migrate every existing record, including MX |

The values above are Vercel's general-purpose defaults. Your project may have specific ones, so always confirm. If you're comfortable in a terminal, vercel domains inspect example.com prints the exact records for your domain, per the CLI setup guide. If you're not, the dashboard shows the same values on the Domains page — no terminal required.

My recommendation for a typical founder: keep DNS at your registrar (or at Cloudflare if you're already there), and use the A-record-plus-CNAME approach rather than delegating nameservers to Vercel. It keeps your email and other records exactly where they are and changes only what needs to change. Nameserver delegation is cleaner if you want Vercel to manage everything and you need wildcard subdomains — note that wildcard domains require the nameserver method — but for most early SaaS it's more migration than you need.

One more decision baked in here: serve your site from www or the bare apex? Vercel will redirect between them either way, but you should still add both domains explicitly and configure a redirect from one to the other so you don't split SEO signals across two URLs. Pick one canonical host and stick to it. I get into why canonicalization matters for ranking in SEO for SaaS landing pages.

What happens after you add the records?

It helps to picture what's actually moving when someone types your domain into a browser. DNS is just a lookup layer that translates your human-friendly name into an address the browser can reach, and the records you just created are what make that lookup point at Vercel.

sequenceDiagram
    participant U as Visitor's browser
    participant D as DNS (your registrar)
    participant V as Vercel
    U->>D: Where is example.com?
    D-->>U: A record → 76.76.21.21
    U->>V: HTTPS request to example.com
    V->>V: Match domain to your project
    V->>V: Serve over auto-provisioned SSL
    V-->>U: Your SaaS, on your domain

Two things happen on Vercel's side once your DNS resolves correctly. Vercel verifies the domain, and then it automatically provisions an SSL certificate so your site loads over HTTPS — the padlock — with no action from you. Per Vercel's docs, the certificate typically issues within a few minutes of DNS verification.

The lag you'll feel is DNS propagation. New records usually resolve in minutes, but they can take longer depending on the TTL on the records and your provider. If the domain isn't verified immediately, that's normal — wait and re-check rather than tearing the records out and re-adding them, which only resets the clock. If you delegated nameservers instead of adding records, nameserver changes specifically can take up to 48 hours to fully propagate, though it's usually much faster.

If you've wired up error tracking, this is a good moment to confirm requests are flowing through your new domain cleanly — the Sentry setup I walked through will start tagging events with the production domain, which makes debugging post-launch issues much easier.

How do you add email on your custom domain?

Here's the gap that surprises every first-time founder: pointing your domain at Vercel handles your website. It does nothing for email. Vercel hosts web traffic, not mailboxes. So out of the box, hello@yourdomain.com goes nowhere.

The fix that costs nothing is email routing — you forward mail sent to your domain to an inbox you already own (your Gmail, say), and you can send from your custom address through that same inbox. Cloudflare Email Routing is the free option I use and recommend for early-stage founders.

The shape of the setup:

First, your domain's DNS needs to be on Cloudflare for this. If your nameservers point to Cloudflare, you're set; if not, you'd move them there (which means Cloudflare becomes where you manage your Vercel records too — that's fine, the A record and CNAME work identically at Cloudflare).

Second, in the Cloudflare dashboard, enable Email Routing and onboard your domain. Cloudflare automatically adds the DNS records that make forwarding work: MX records to route incoming mail to Cloudflare, plus SPF and DKIM TXT records for authentication so your forwarded mail doesn't land in spam.

Third, create a routing rule. Enter the local part — hello, or support — pick your domain, and choose the destination inbox. Cloudflare sends a verification email to that destination; click the link to confirm it.

That's it. Mail to hello@yourdomain.com now lands in your real inbox. You can create up to 200 rules, and a catch-all rule forwards anything sent to any address at your domain to one place — handy when you don't want to lose a message sent to a typo'd address.

Two things to keep straight. Email forwarding (receiving) is what Cloudflare Email Routing gives you for free; to send from your custom address you also configure your inbox's "send as" feature, or graduate to a real mailbox provider. And transactional email — password resets, receipts, your lifecycle sequences — is a different system entirely, handled by a provider like Resend. I compared those in Resend vs Postmark vs Mailgun; routing handles your human inbox, a transactional provider handles your app's automated sends.

The critical warning, repeated because it burns people: if you ever switch your nameservers to Vercel after setting up email, you'll strip the MX records and your email dies silently. Keep DNS in one place — for most founders running email, that place is Cloudflare, with Vercel records living alongside.

Common gotchas (and how to avoid them)

A few failure modes I've hit or watched others hit:

Records added in the wrong place. If your nameservers point to Cloudflare but you add the A record at your registrar, nothing happens — the registrar's DNS isn't authoritative anymore. Find where your nameservers actually point, and add records there.

Apex CNAME attempts. You can't CNAME a bare apex domain; the DNS spec forbids it. Use the A record for the root and CNAME only for subdomains. Some providers offer "CNAME flattening" or "ALIAS" records to work around this, but Vercel's A record is the simplest path.

Impatience with propagation. Pulling and re-adding records because the domain didn't verify in 30 seconds just restarts propagation. Add the record once, then wait and re-check.

Forgetting the www redirect. Add both apex and www, then redirect to your canonical choice. Otherwise you have two live URLs serving the same site, which is messy for SEO and confusing for users.

Breaking email with a nameserver switch. Covered above, but it's the one that costs you real messages, so it's worth saying twice.

Mixed content or stale caches after going live. Once your domain resolves and SSL provisions, an old browser tab or an aggressive CDN cache can still show the vercel.app version for a while. Hard-refresh, try an incognito window, and confirm in the Vercel dashboard that the domain reads as configured before you conclude something's wrong. Nine times out of ten the deploy is fine and you're looking at a cached page.

If you're keeping infrastructure costs near zero while you validate, the domain plus free email routing fits neatly into the free-tier SaaS stack — a domain registration is often the only line item you actually pay for pre-launch.

Frequently asked questions

Do I need to buy my domain from Vercel to use it on Vercel?

No. You can use a domain from any registrar. You just add the domain to your Vercel project and create the DNS records at wherever your DNS is managed. Buying through Vercel is convenient because the configuration is automatic, but it's not required.

Why isn't my custom domain working after I added the records?

Almost always it's one of two things: the records were added at the wrong DNS provider (check where your nameservers actually point), or DNS hasn't finished propagating yet. Re-run Vercel's domain inspection or check the dashboard status, and give it a few minutes before assuming something's broken.

Does Vercel give me HTTPS automatically?

Yes. Once your DNS verifies, Vercel automatically provisions and renews an SSL certificate, usually within a few minutes. You don't buy or configure a certificate yourself — HTTPS and the padlock are handled for you.

Can I get email on my custom domain for free?

Yes, for receiving. Cloudflare Email Routing forwards mail sent to addresses on your domain to an inbox you already own, at no cost, and supports up to 200 rules plus a catch-all. Sending from your custom address means also setting up "send as" in your inbox or using a paid mailbox provider.

Should I use a www or non-www domain for my SaaS?

Either works, and Vercel redirects between them. The important thing is to pick one as canonical, add both domains to the project, and redirect the other to it so you don't split traffic and SEO across two URLs.

What's the difference between email routing and a transactional email provider?

Email routing forwards your human-facing mail (someone emailing support@) to your inbox. A transactional provider like Resend sends your app's automated messages — password resets, receipts, lifecycle emails. They solve different problems, and most SaaS apps end up using both.

Conclusion: ten minutes plus a little patience

Connecting a custom domain to your SaaS on Vercel is genuinely a ten-minute job — add the domain, set an A record or CNAME, let SSL provision itself — wrapped in some waiting for DNS to propagate. The part that trips people up isn't the web setup; it's remembering that email is a separate system, and that switching nameservers can quietly break it. Keep your DNS in one place, add free email routing for your human inbox, and reach for a transactional provider for your app's automated sends.

If you're wiring up a Next.js SaaS and want the integrations that come after the domain — error tracking, analytics, email automation — handled with copy-paste AI prompts, the Coding Capybaras marketplace has the exact prompts to paste into Claude Code or Cursor, each tuned for a Next.js + Supabase + Stripe app.