How to connect a custom domain to Vercel using DNS?

Sajjad
DNS
10 Oct, 2026

To connect a custom domain to Vercel, add the domain in your project under Settings > Domains, then create the DNS records Vercel shows you at your DNS provider: an A record for the apex domain (example.com) and a CNAME record for subdomains such as www. Alternatively, you can change your domain's nameservers to Vercel's, so Vercel hosts your DNS and configures the records itself. Once the records resolve, Vercel verifies the domain and issues a free TLS certificate automatically, usually within minutes.

The process is simple, but a few things regularly trip people up: picking the wrong record type for the apex, a CAA record that blocks certificate issuance, a Cloudflare proxy in front of Vercel, or a domain already claimed by another Vercel account. This guide covers both connection methods, how to choose between them, how to set up redirects between the apex and www, how to automate it with the CLI, API or Terraform, and how to troubleshoot with dig.

Two Ways to Connect a Domain

	External DNS (A and CNAME)	Vercel nameservers
Where DNS is hosted	Your current provider	Vercel
What you change	Add one or two records	Nameservers at your registrar
Other records (email etc.)	Stay where they are	Must be recreated in Vercel DNS
Wildcard domains	Not supported for automatic certificates	Supported
Best for	Most sites, especially with existing email	Wildcard subdomains, all-in-one setup

For most people, keeping DNS where it is and adding A and CNAME records is the least disruptive choice. Your email and other records don't move, and nothing outside the website changes.

Step 1: Add the Domain to Your Project

In the Vercel dashboard, open your project, go to Settings > Domains and enter your domain. Vercel will usually suggest adding both the apex domain and www, with one redirecting to the other.

Vercel then shows each domain with a status such as Invalid Configuration and the DNS records it expects. Leave this page open, because it updates once your records are correct.

You can do the same from the command line with the Vercel CLI, run from your project directory or with the project name:

npm i -g vercel
vercel login
vercel domains add example.com my-project
vercel domains add www.example.com my-project

Step 2: Create the DNS Records

The exact values to use are shown in the dashboard for your project, so copy them from there. For many years Vercel has used the following values, and they're what you'll see in most guides:

Host	Type	Value
`@` (apex)	A	`76.76.21.21`
`www`	CNAME	`cname.vercel-dns.com`

Vercel has since started showing newer values as part of an IP range expansion: an apex A record such as 216.198.79.1 and a project-specific CNAME target ending in a domain such as vercel-dns-017.com. The older values continue to work, but if the dashboard shows something different, use what the dashboard shows.

Why the Apex Uses an A Record

The DNS standards don't allow a CNAME at the apex of a zone, because the apex must also hold SOA and NS records, and a CNAME can't coexist with other records at the same name. That's why the apex gets an A record pointing at an IP address, while subdomains can use a CNAME.

If your DNS provider supports ALIAS, ANAME or CNAME flattening at the apex, you can point the apex at Vercel's CNAME target that way instead. Vercel's documentation and dashboard show the A record approach because it works everywhere.

Example: Zone File Records

In BIND zone file format, the records look like this:

@     3600  IN  A      76.76.21.21
www   3600  IN  CNAME  cname.vercel-dns.com.

Note the trailing dot on the CNAME target. In most DNS dashboards you don't type it, but in zone files it's required, otherwise the name is treated as relative to your domain.

Remove Conflicting Records

Before adding the new records, delete any old A, AAAA or CNAME records for the same names:

An old AAAA record on the apex is a common problem. IPv6 visitors would still be sent to your previous host. Remove it unless the dashboard tells you to add one.
A CNAME and an A record can't share a name. If www already has an A record, delete it before adding the CNAME.
Parking or forwarding records from your registrar should also go.

Leave MX, TXT and other unrelated records alone.

Example: Adding the Records via Cloudflare's API

If your DNS is at Cloudflare and you prefer the API:

curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"example.com","content":"76.76.21.21","ttl":1,"proxied":false}'

curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"CNAME","name":"www","content":"cname.vercel-dns.com","ttl":1,"proxied":false}'

"ttl": 1 means Automatic in Cloudflare, and "proxied": false makes the record DNS only, which matters for Vercel, as explained later.

Step 3: Verify the Records With dig

Check that the records resolve as expected:

dig example.com A +short
dig www.example.com CNAME +short

76.76.21.21
cname.vercel-dns.com.

If you get old values, your provider may not have saved the change yet, or resolvers are still caching the old record. Query your authoritative nameserver directly to see the live value without caching:

dig example.com NS +short
dig @ns1.your-dns-provider.example example.com A +short

Once Vercel sees the correct records, the domain's status in the dashboard changes to Valid Configuration and a certificate is issued. You can check from the CLI too:

vercel domains inspect example.com

And confirm the site is served with a valid certificate:

curl -sI https://example.com | head -n 5

HTTP/2 200
server: Vercel
content-type: text/html; charset=utf-8
...

Option 2: Use Vercel Nameservers

If you'd rather let Vercel host all of your DNS, change your domain's nameservers at your registrar to:

ns1.vercel-dns.com
ns2.vercel-dns.com

Vercel then creates the website records automatically, and you manage everything else in the Domains section of your Vercel account or team.

Before you switch, recreate every other record your domain needs in Vercel DNS, especially email records. Once the nameservers change, records at your old DNS provider are no longer used. With the CLI:

vercel dns add example.com @ MX mx1.mail.example.net 10
vercel dns add example.com @ TXT "v=spf1 include:_spf.mail.example.net -all"
vercel dns add example.com _dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
vercel dns ls example.com

Check that the delegation has updated by asking the TLD servers directly:

dig @a.gtld-servers.net example.com NS +norecurse +noall +authority

example.com.		172800	IN	NS	ns1.vercel-dns.com.
example.com.		172800	IN	NS	ns2.vercel-dns.com.

The 172,800-second TTL means some resolvers may keep using your old nameservers for up to two days, so leave your old DNS zone in place during that time.

When You Need Vercel Nameservers

The main reason to use Vercel nameservers is wildcard domains, such as *.example.com for multi-tenant apps where each customer gets their own subdomain. Vercel issues wildcard certificates using a DNS-01 challenge, which requires it to control the zone. With external DNS, add each subdomain individually instead.

Setting Up the Apex and www Redirect

You should serve your site on one hostname and redirect the other to it, so search engines see a single canonical version. In Settings > Domains, edit one of the domains and choose to redirect it to the other.

Vercel recommends using www as the primary domain and redirecting the apex to it. The reasoning is that www uses a CNAME, so Vercel can change the addresses behind it without you touching DNS, and it plays more nicely with cookies and CDNs. Either choice works fine for most sites.

Test the redirect:

curl -sI https://example.com | grep -iE '^(HTTP|location)'

HTTP/2 308
location: https://www.example.com/

Verifying Ownership With a TXT Record

If the domain, or its apex, is already in use by another Vercel account or team, Vercel asks you to prove ownership before adding it to your project. The dashboard shows a TXT record to create, at the name _vercel with a value starting vc-domain-verify=:

_vercel   3600  IN  TXT  "vc-domain-verify=www.example.com,1a2b3c4d5e6f7a8b9c0d"

The value above is only an example, so copy the real one from your dashboard. Check it's live:

dig _vercel.example.com TXT +short

Then click Verify in the dashboard. You can remove the TXT record after verification, though leaving it in place does no harm.

Common Problems and Fixes

CAA Records Blocking the Certificate

A CAA record lists which certificate authorities may issue certificates for your domain. If you have one that doesn't include the authority Vercel uses, the certificate can't be issued and the domain stays stuck without HTTPS.

dig example.com CAA +short

0 issue "digicert.com"

Vercel issues certificates through Let's Encrypt, so add it alongside your existing entries:

@   3600  IN  CAA  0 issue "letsencrypt.org"

If there's no CAA record at all, any authority can issue and you don't need to add one.

Cloudflare Proxy in Front of Vercel

If your DNS is at Cloudflare and the record is proxied (the orange cloud), visitors connect to Cloudflare rather than Vercel. That hides the real records from Vercel's checks, can interfere with certificate issuance, and adds a second CDN and cache layer on top of Vercel's own network. Vercel recommends setting the records to DNS only (the grey cloud).

With a proxied record, dig returns Cloudflare's addresses rather than Vercel's, which is an easy way to spot it:

dig example.com A +short

104.21.48.12
172.67.150.33

Wrong Record at the Apex

Some DNS dashboards silently refuse or convert a CNAME at the apex. Make sure the apex has an A record, or an ALIAS or flattened record, and that it returns Vercel's IP address.

Old Records Still Cached

If you previously had a long TTL on the apex or www, resolvers may hold the old values for hours. Querying your authoritative nameserver directly tells you whether the problem is your configuration or just caching.

Automating Domain Setup

With the Vercel REST API

You can add a domain to a project with an API call, which is useful when creating many projects or customer domains:

curl -s -X POST "https://api.vercel.com/v10/projects/my-project/domains" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"name": "www.example.com"}'

For a project owned by a team, add ?teamId=your-team-id to the URL. The response includes a verified field and, if verification is needed, the TXT record to create.

With Terraform

The official Vercel Terraform provider has a vercel_project_domain resource. Combined with your DNS provider's resource, you can manage both sides together:

resource "vercel_project_domain" "www" {
  project_id = vercel_project.site.id
  domain     = "www.example.com"
}

resource "vercel_project_domain" "apex" {
  project_id           = vercel_project.site.id
  domain               = "example.com"
  redirect             = vercel_project_domain.www.domain
  redirect_status_code = 308
}

resource "cloudflare_dns_record" "www" {
  zone_id = var.cloudflare_zone_id
  name    = "www"
  type    = "CNAME"
  content = "cname.vercel-dns.com"
  ttl     = 1
  proxied = false
}

This example assumes a vercel_project.site resource and version 5 of the Cloudflare provider, which uses cloudflare_dns_record. Earlier versions call it cloudflare_record.

A Quick Checklist

Add the apex and www in Settings > Domains.
Create the A record for the apex and the CNAME for www, using the values in the dashboard.
Remove old A, AAAA and CNAME records for those names.
Make sure the records are DNS only if you use Cloudflare.
Allow Let's Encrypt in any CAA record.
Add the _vercel TXT record if the dashboard asks for it.
Choose your primary hostname and set the redirect.
Check with dig and curl, and wait for Valid Configuration.

FAQ: Connecting a Domain to Vercel

Usually an A record for the apex domain and a CNAME record for www or other subdomains. Use the exact values shown in your project's Domains settings, as Vercel may show project-specific values.

Not a standard CNAME, because DNS doesn't allow one at the apex. Use the A record Vercel provides, or an ALIAS, ANAME or flattened CNAME if your DNS provider supports it.

No. Most sites keep their existing DNS provider and add A and CNAME records. Vercel nameservers are mainly needed for wildcard domains.

The records Vercel expects aren't resolving yet. Check with dig that the apex returns Vercel's IP and www returns the CNAME, remove conflicting records, and wait for any cached old values to expire.

The most common causes are a CAA record that doesn't allow Let's Encrypt, a Cloudflare proxy in front of Vercel, or DNS records that don't point at Vercel yet. Fix those and the certificate is usually issued within minutes.

Not if you keep your existing DNS provider and only change the website records. If you switch to Vercel nameservers, recreate your MX, SPF, DKIM and DMARC records in Vercel DNS before changing them.

Vercel recommends www as the primary domain with the apex redirecting to it, because the CNAME gives more flexibility. Both work, so pick one and redirect the other.

Conclusion

Connecting a custom domain to Vercel takes a few minutes: add the domain to your project, create an A record for the apex and a CNAME for www at your DNS provider, and wait for Vercel to verify the records and issue a certificate. If you need wildcard subdomains or want everything in one place, switch to Vercel's nameservers instead, after recreating your other records there.

When something doesn't work, the cause is almost always visible with dig: an old AAAA record, a proxied Cloudflare record, a restrictive CAA record or a cached value from before the change. Fix the record, check it against your authoritative nameserver, and Vercel will pick it up automatically.