Vercel Custom Domain DNS Setup

This guide is for teams using Vercel for a frontend, docs site, or preview app that should live behind a stable hostname.

Vercel evaluates three separate states: the domain must be assigned to the intended project, DNS must use the value Vercel gives that domain, and account access may need TXT verification if another Vercel team already uses the name. Treating all three as “DNS propagation” hides the useful diagnosis.

Start from the project, not a remembered DNS value

Open the Vercel project and go to Settings → Domains. Add the exact apex domain or subdomain that should serve the production deployment.

Vercel’s current setup distinguishes these shapes:

• an apex such as example.com normally receives an A-record instruction
• a subdomain such as app.example.com normally receives a CNAME instruction
• a wildcard domain requires the nameserver-based verification path
• a domain already associated with another Vercel account can require a TXT ownership record

For a subdomain, use the project-specific value displayed in the domain settings:

Type: CNAME
Name: app
Value: <project-specific target shown by Vercel>

Do not paste a CNAME copied from another project or an older tutorial. Vercel documents both general-purpose DNS values and unique per-project values; vercel domains inspect or the project dashboard is the source of truth for the domain being connected.

vercel domains inspect app.example.com

If A records and CNAMEs are still easy to mix up, review A Records and CNAME Records: Choosing a DNS Target before changing production DNS.

Verify DNS without losing the configured target

Capture the value shown by Vercel before opening the DNS provider. After saving the record, query the CNAME explicitly:

dig app.example.com CNAME +short

For a normal, unflattened CNAME, the answer should exactly match the fully qualified target Vercel supplied. Some DNS providers flatten or proxy CNAMEs; in that case, use the provider’s documented A/AAAA behavior and check vercel domains inspect rather than assuming an absent public CNAME means the record is missing.

Compare more than one resolver only after the authoritative record is correct:

dig @1.1.1.1 app.example.com +short
dig @8.8.8.8 app.example.com +short

Resolver disagreement can be normal during cache expiry. DNS Propagation: TTLs, Caches, and Verification explains how to compare the authoritative answer with recursive caches before editing the record again.

Handle account ownership separately

If Vercel says the domain is already assigned to another account or team, changing the serving CNAME repeatedly will not prove ownership. Follow the TXT verification value shown by Vercel. Successful TXT verification permits the project to use the domain; it does not silently transfer the domain registration or remove its existing DNS records.

For multiple domains, complete one requested TXT verification at a time and re-check the project domain status after each change.

Illustrative verification record

Illustrative example using reserved example domains and IPs.

The target shown inside the illustration is a placeholder, not a current configuration value. Use the target displayed for your own Vercel project.

Confirm the production deployment and redirect owner

Once DNS is correct, test the public host:

curl -I https://app.example.com

A healthy Vercel response often includes headers such as:

HTTP/2 200
server: Vercel
x-vercel-id: ...

Header names can change, so do not rely on one header as the only proof. The more important checks are: HTTPS is valid, the content is the expected project, and redirects land on the intended canonical hostname.

If both apex and www should work, add both domains explicitly in Vercel and choose the redirect in project settings. A redirect that exists only at the previous provider can disappear during cutover.

Diagnose the Vercel status, not just the browser

• Invalid configuration: compare the exact A or CNAME requested by Vercel with the authoritative record, including the record name and any trailing dot shown for a fully qualified CNAME.
• Ownership verification requested: publish the Vercel-provided TXT record; do not replace the serving record with a guessed value.
• DNS is valid but the wrong application appears: inspect which project owns the domain and which deployment is marked production.
• The custom host works but www or apex does not: add the missing variant and define the redirect explicitly.
• HTTPS remains unavailable: confirm Vercel has validated DNS, then inspect certificate state rather than adding a second conflicting DNS record.

Launch checklist

Before calling the migration done, confirm:

• Vercel shows the domain as valid
• public DNS matches the value Vercel requested for this project
• any requested TXT ownership verification is complete
• HTTPS is valid for the exact hostname
• redirect preference is intentional
• Search Console, analytics, and internal links use the final host

A good Vercel DNS setup is quiet. It does not depend on someone remembering which dashboard was edited last; the project, DNS records, and verification commands all tell the same story.